Xen Vulnerability Allows Hackers To Escape Qubes OS VM And Own the Host (itnews.com.au)

Slashdot reader Noryungi writes: Qubes OS certainly has an intriguing approach to security, but a newly discovered Xen vulnerability allows a hacker to escape a VM and own the host. If you are running Qubes, make sure you update the dom0 operating system to the latest version.
"A malicious, paravirtualized guest administrator can raise their system privileges to that of the host on unpatched installations," according to an article in IT News, which quotes Xen as saying "The bits considered safe were too broad, and not actually safe." IT News is also reporting that Qubes will move to full hardware memory virtualization in its next 4.0 release. Xen's hypervisor "is used by cloud giants Amazon Web Services, IBM and Rackspace," according to the article, which quotes a Qubes security researcher who asks the age-old question. "Has Xen been written by competent developers? How many more bugs of this caliber are we going to witness in the future?"

Comments

Re:Really?

[phantomfive]

Show me this type of vulnerability in VMware, any version

Here's one example.

Here's a story showing that VMWare tries to hide their vulnerabilities.

Re:well, shitlord...

[martyros]

Which raises the age-old question: Has Qubes been written by competent developers?

What's really rich about that question is that if you read their advisory, the Qubes developers couldn't figure out how to exploit the vulnerability when handed a patch that changes the problematic behavior. If not spotting the issue without having it handed to them makes the Xen developers incompetent, what does that say about the Qubes developers?

The fact is, though, that the vulnerability is actually quite hard to spot. It's not surprising at all that experienced security researchers would fail to spot it even when given a pretty big clue; much less that the initial developers would fail to spot it.

Re:WTF is Qubes?

[Burz]

You can think of Qubes as a desktop OS that demotes monolithic kernels (hopelessly insecure) to the role of providing features/drivers within unprivileged VMs. This is similar to the microkernel philosophy, but also recognizes that monolithic kernels are still where all the drivers and apps are to be found.

Qubes also employs IOMMU hardware to contain network and USB controllers within unprivileged VMs to protect against DMA attacks. The admin VM that runs the desktop environment has no direct access to networking, and the user can assign other PCI devices to VMs as they see fit.

The last piece of the Qubes picture is that it departs from how most hypervisors handle graphics, keyboards and inter-VM copying. Each is properly virtualized using a very simple protocol that is highly resistant to attack, so that VMs cannot sniff your clipboard contents or keystrokes, or take screenshots, etc. Copying between Qubes VMs is also probably much safer than copying between air-gapped machines using discs or flash drives because the former is far simpler.

The Qubes Security Bulletin for this Xen vulnerability can be viewed here.

Most Xen vulns either do not apply to Qubes or are DOS, and the Qubes project is skeptical that this one can be realistically used against Qubes. Still, the bulletin also describes how this vuln belongs to a class of memory management bugs that the Xen project has not done a good job in rectifying. This appears to be Xen's "weak spot" that could be a perennial source of vulns. As a result, Qubes will be moving away from PVMs (which use the questionable memory mapping code) to HVMs which employ on-silicon SLAT for VMs.