Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.

Qubes Kicks Xen While It's Down After Finding 'Fatal, Reliably Exploitable' Bug

posted by on Monday May 08 2017, @02:27AM   Printer-friendly
from the hypervisor-beat-down dept.

Arthur T Knackerbracket has found the following story:

Qubes is once again regretting how long it's taken to abandon Xen's PV hypervisor, disclosing another three bugs including host escape vulnerabilities.

The most serious bugs are in PV (paravirtualization) memory handling, XSA-213 and XSA-214.

"An attacker who exploits either of these bugs can break Qubes-provided isolation. This means that if an attacker has already exploited another vulnerability, e.g. in a Web browser or networking or USB stack, then the attacker would be able to compromise a whole Qubes system" Qubes says in this note.

The bug in XSA-213 only affects 64 bit x86 systems and relates to how root and user mode page tables are handled by 64-bit PV guests. The IRET hypercall, which stands in for identically-named CPU instructions, transfers control from user mode to kernel mode.

"If such an IRET hypercall is placed in the middle of a multicall batch, subsequent operations invoked by the same multicall batch may wrongly assume the guest to still be in kernel mode", Xen explains, with the result that the guest could get writable access to the wrong root page table.

This means a buggy or malicious PV guest "may be able to access all of system memory, allowing for all of privilege escalation, host crashes, and information leaks."

-- submitted from IRC

Original Submission

 
This discussion has been archived. No new comments can be posted.
Qubes Kicks Xen While It's Down After Finding 'Fatal, Reliably Exploitable' Bug | Log In/Create an Account | Top | 6 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 0) by Anonymous Coward on Monday May 08 2017, @03:51PM (2 children)

    by Anonymous Coward on Monday May 08 2017, @03:51PM (#506399)

    The solution isn't to expect AMT or IPMI to be free of backdoors - because even if you assume only one bug per 100 lines of code, that's still tens, or hundreds, or even thousands of bugs.
    The solution is to ensure that they're run on seperate management VLANs with proper firewalling to ensure that other people can't get on them without 802.1x access.

  • (Score: 2) by kaszz on Monday May 08 2017, @06:14PM

    by kaszz (4211) on Monday May 08 2017, @06:14PM (#506481) Journal

    The solution is partly to not run code on my machines that I didn't sanction. Ie the Intel Management engine can't really be deselected. There will always be at least one network card with world access and then there's a CPU with hidden spheres that can mess around without the owner being able to remove it thoroughly. The VLAN solution is kind of shaky.

  • (Score: 0) by Anonymous Coward on Tuesday May 09 2017, @12:33AM

    by Anonymous Coward on Tuesday May 09 2017, @12:33AM (#506678)

    x ≠ 1