Xen exploitation part 2: XSA-148, from guest to host | Hacker News Reader

Xen exploitation part 2: XSA-148, from guest to host

blog.quarkslab.com

87 pointsadamnemecek13 comments

"This vulnerability is probably the worst ever seen affecting Xen and it was introduced 7 years before its discovery. As demonstrated in this blogpost, it is exploitable and a code execution within dom0 is not so difficult."

Xen-like paravirtualisation has always seemed to me as more of a convenient way to run multiple well-behaved guests on the same hardware than any sort of real security/isolation barrier, because of the cooperation that has to occur between the guest and the host. It's sort of a leaky abstraction. I think full virtualisation or even emulation can provide stronger security/isolation, although the tradeoff is performance.

So this basically throws the whole premise of QubesOS out the window, it seems.

Virtualization is hard.

Wouldn't the fact that this particular vulnerability has been fixed mean that we have to throw the whole premise of QubesOS back in the window?

I'm not really seeing any sort of sandboxing tech on Linux that is significantly tougher than Qubes.

It's a little bit easier if you care a lot less about performance.

No this is a security exploit for one hypervisor. Qubes would still protect you for the most common exploits from your web browser or database . No security system is 100%

Security on bare metal OS is a hard problem.

Square or cube that to get an idea of security in virtualization.

IMO, the premise that hypervisors can have a smaller (thus more assurance-friendly) attack surface relative to a monolithic or microkernel-based operating system is not challenged by any attack against xen. Xen has a very feature-rich interface as far as hypervisors go (hello grant tables!). The interface to the hypervisor on x86_64 can be small while still being performant and functional (EPT and posted interrupts are very nice).

That said, I work for a company that sells a hypervisor built on the idea that hypervisors need not be complex to solve real problems. We look at hypercalls that include data structures (even ones as simple as C strings) with great skepticism.

You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

Theo de Raadt

So because 95% of worldwide software developers write PHP web servers full of security holes, it is not possible for a different group of developer to create a secure interface? None of these web developers ever cared one bit about the security of their app. You can't compare that with someone intending to develop a secure interface. Security doesn't happen by mistake.

The value proposition of Xen is that it's a well-defined interface. The host OS kernel takes care of hardware initialization, and Xen becomes an interface on top of this kernel, through which untrusted client applications access hardware resources. So the innovation of Xen is not that it's supposedly bug-free. It's that it separates concerns: not mixing together hardware initialization (Linux) and resource access/isolation for user space code. That alone leaves less room for bugs.

The value of Linux is its drivers, not the actual kernel. So let's use Linux for its drivers, rather than as a standard library. The only reason people use, for example, the Linux CPU scheduler, is that it's inextricably tied to the Linux drivers, because no interface exists (all code runs in one huge blob). This is what Xen wants to fix. If the Linux folks concentrated on creating secure driver interfaces, rather than implementing CPU schedulers and memory managers themselves, it would mean that all the other developers of the world could write CPU schedulers, rather than only the select few people who think they know the Linux code base (who still end up producing bugs). An interface is worth so much more than just an implementation of one, because it not only makes access easy for the client, but also makes the creation of new server implementations easy (by having a well-defined protocol/interface to which they must conform).

I don't read it like that.

From my point of view it's like saying if you sell virtualization as a way to isolate different OSes + applications for security reasons (compared to cost savings and all associated from using this kind of technology), clearly you better think twice about that.

And really, it's pretty much always a selling point when you talk to a marketing rep or your PHB or her/his PHBs.

> Security doesn't happen by mistake.

My hypothesis is that we do not fully understand what "security" means yet in this reality, which would imply that security does happen by accident. We (software developers of all skills) go around talking about security in terms of lines of code written by humans (with suffering), teams of humans (with competition) and companies (with objectives of profit) as if it is something obtainable with the right intent and tongue set just so in cheek.

It isn't, and until we realize we're running counter to that intent, we're just shooting in the dark.

I started identity mapping everything using 2 Meg as much as possible. Since VGA A0000 BFFFF must be uncached, I had to map the lowest 2 Meg with 4K.

Then, I made an alias for the VGA.

Recently, I switched to 1 Gig pages. You probably did not know that there is a bit in the CPUID that tells if 1 Gig pages are supported.

I have an alias for the first 4 Gig up toward top of my space. FEE00000 the local apic and IOAPic and HPET must be uncached, so I access them in my 4Gig alias up in high space.

Reply on news.ycombinator.com