Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Virtualization Bug Security

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

Posted by EditorDavid from the exploit-XSA-182 dept.
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?"
This discussion has been archived. No new comments can be posted.

Xen Vulnerability Allows Hackers To Escape Qubes OS VM And Own the Host More

Xen Vulnerability Allows Hackers To Escape Qubes OS VM And Own the Host

Comments Filter:

  • well, shitlord... (Score:4, Insightful)

    by Anonymous Coward on Saturday July 30, 2016 @01:44PM (#52613083)

    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?"

    Well, "Qubes security researcher", which platform did you choose for your project, and did you audit it fully before making your releases? No?

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

    • Re:well, shitlord... (Score:5, Informative)

      by martyros ( 588782 ) on Saturday July 30, 2016 @06:10PM (#52614233)

      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.

    • First off, I'm not quite sure what to make of you calling Joanna a "shitlord". Has that epithet recently undergone a dramatic shift in meaning?

      Now, do you actually expect the leader of a relatively small distro to personally audit everything upstream before every single release? Or were you just being rhetorical and you think that harsh criticism is always unwarranted? I do not have the time or expertise to vet anything personally, but Joanna's white papers and her philosophy for Qubes have almost always

  • Has Xen been written by competent developers?

    Strictly speaking the answer is no, but they are definitely as good as the VMWare guys, who've had plenty of vulns.

  • And I can't help but wonder if much of it is because security was an afterthought for so long and if we would have been better off and designed for it from the get-go, even though it would have meant rewriting or scrapping decades of code.
    The counterargument i was hearing back in the late 80s was that too much would have to be redone - and that was before the explosive growth that's seen a billion people walking around with more computing power in their pockets than most companies had available back then.

    • It's time to face the truth. Real computer security is impossible.

      • Real computer security is impossible.

        We can do much, much, much better than we are doing now.
        There is no reason that our lower-level systems (at least) can't be secure. You write them once (in the djb style), then don't change them, because they don't need to change.

        The problem now is that there is very little motivation for programmers to even care about security. You can't see it, and no manager ever asks at a sprint, "is the code you wrote secure?"

        • Sorry, it's "cat and mouse" all the way down. The treadmill is infinite. Two things are required to break the circle, Respect, and trust. Without both, all bets are off. Just call it a day and put down a cold one (or six) and chase the old lady around the house. Dwelling on it will only give you a heart attack.

          • Sorry, it's "cat and mouse" all the way down. The treadmill is infinite.

            No it's not, you can prove that your code is correct.

            • Even I can assure you there is always a way in. Nothing is invincible. If it were it would be all over the papers, and we would have world peace.

              • Even I can assure you there is always a way in.

                Unplug the computer.

              • Re: (Score:2)

                by gweihir ( 88907 )

                Bullshit. Spoken like a true incompetent. Code vulnerabilities are caused by coders. They can be reduced and potentially eliminated by a) using better coders and b) spending more effort. In todays world where coders are often as cheap and incompetent so they just get the job still done (and management bonuses are not threatened), most code is vulnerable, but that is not fate.

                • Please... Put your best system out in the wild with a big fat bounty and see how long it holds up.

                  • Re: (Score:2)

                    by gweihir ( 88907 )

                    It would last forever. As nobody is paying _me_ a large sum of money for doing so, I have zero interest in doing this though.

                    The argument you present is one of the more transparent fallacies used by the typical techno-skeptic moron.

                    • As nobody is paying _me_ a large sum of money for doing so, I have zero interest in doing this though.

                      Whoa! Like, did you even read? You put a fat reward on it, and somebody will have greater than zero interest, and will eventually succeed, within a reasonable amount of time. I thought that was spelled out in the post. Oh well, That's what I get for thinkin'..

                      Thank you for your participation... It was most enlightening.

                      I must be talking to the owner of the Titanic, or was it the Towering Inferno?

            • Sure, you keep harping on this, but you can only prove your code is correct. Not the operating system, not the additional libraries you use, not the output of the optimising compiler with your code as input.

              Software complexity rises with a O(^N) speed with N different connections between modules or conditionals. Proving every code path correct is a gargantuan task.

              That doesn't mean you shouldn't write your code to be secure and mathematically provable when possible. It means you shouldn't fall into the fals

            • Re: (Score:3)

              by Dog-Cow ( 21281 )

              You can prove code is logically correct, but you can't prove the logic is correct. If you don't understand the difference, don't be a security researcher.

    • Security is always an afterthought. People want to get their products used and published, and want to make money. They need to release their stuff before the competitors do it. Only very rarely security is implemented from day one.

  • So patch your OS. If it's not a zero-day it's not a problem. Why is this news?

    • If it's not a zero-day it's not a problem.

      You don't know about zero-days. They haven't hit the news yet: but they're being used by hackers.

    • So that everyone finds out about it and maybe patches it?

      • Anybody who casually neglects security updates unless he sees a news headline probably shouldn't be using anything that requires manual updates.
    • The vulnerability seems to assume paravirtualization, which can be switched off. Problem solved.
      Geez, you people almost got me scared about my qubes...

  • WTF is Qubes? (Score:3)

    by kwerle ( 39371 ) <kurt@CircleW.org> on Saturday July 30, 2016 @03:00PM (#52613473) Homepage Journal

    https://www.qubes-os.org/ [qubes-os.org] claims (tongue in cheek) to be "Reasonably secure." Really it loos like they are all about the security, so this is kind of a big deal for them.

    https://www.qubes-os.org/tour/... [qubes-os.org]
    What is Qubes OS?
    Qubes is a security-oriented operating system (OS). The OS is the software which runs all the other programs on a computer. Some examples of popular OSes are Microsoft Windows, Mac OS X, Android, and iOS. Qubes is free and open-source software (FOSS). This means that everyone is free to use, copy, and change the software in any way. It also means that the source code is openly available so others can contribute to and audit it.

    • Re:WTF is Qubes? (Score:4, Informative)

      by Burz ( 138833 ) on Saturday July 30, 2016 @06:32PM (#52614331) Homepage Journal

      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. [github.com]

      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.

    • Re: (Score:3)

      by fnj ( 64210 )

      https://www.qubes-os.org/ [qubes-os.org] claims (tongue in cheek) to be "Reasonably secure." Really it loo[k]s like they are all about the security, so this is kind of a big deal for them.

      "All about security", so they insert "user ALL=(ALL) NOPASSWD: ALL" in sudoers, right? And a PolicyKit rule for anybody to do anything? And DOM0 is set up with no-password root access? I gotta tell ya, those are real head-scratchers. They have some great ideas, but I'm not sure they are living in the same world I am [qubes-os.org].

      • As the assumption is that VMs can not access each other's contents, and the owner of the computer is assumed to have protected his access to the host by using a password, individual passwords for individual VMs are not necessary anymore and the user can have sudo access, as there is only one user.
        Qubes OS is not multi-user.

  • ... How much did the qubes researcher, or anyone, pay for this software?

    I think it's the same as with the OpenSSL library: sure, it may be buggy and unsafe. But would you rather do without? And those complaining don't *have* to use Xen, or OpenSSL: they can always use commercial software. And I have to say that the trackrecord of the Xen solution vs. the commercial solutions is pretty good.

    Dissing developers who put in time and effort to help others is insulting to the entire OS community. Point out mistake

  • First link describes XSA-148, not XSA-182 (Score:3)

    by martyros ( 588782 ) on Saturday July 30, 2016 @06:12PM (#52614241)

    The first link is a description of XSA-148 [xen.org], which was published last October, not XSA-182.

  • Oh so... is this why the tor people always say it's better to have the whonix workstation in a qubes VM but still have to go through the whonix gateway VM on a completely separate machine? Which just leads me to another question: Is there a smaller attack vector in physical separation or is it just a different one? Or is the idea that you have to get through a physical machine to get to the workstation machine but then still get through the VM to dox fully? It would seem like just getting to the gateway pc

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close