Friday, May 13, 2011

Following the White Rabbit: Software Attacks Against Intel VT-d

Today we publish a new paper which is a result of our several month long in-depth evaluation of Intel VT-d technology. To quote the abstract:
We discuss three software attacks that might allow for escaping from a VT-d-protected driver domain in a virtualization system. We then focus on one of those attacks, and demonstrate practical and reliable code execution exploit against a Xen system. Finally, we discuss how new hardware from Intel offers a potential for protection against our attacks in the form of Interrupt Remapping (for client systems available only on the very latest Sandy Bridge processors). But we also discuss how this protection could be circumvented on a Xen system under certain circumstances...

I think the attack is likely the most complex and surprising out of all the things we have presented so far. Parts of it are even funny (if you share our weird sense of humor), such as the use of ICMP ping to generate MSIs. The paper also covers the vendors' response. You can download the paper here.

9 comments:

csaba_s said...

Excellent research indeed! It's scary to see that security issues I believed to be issues of software developers go that deep into the hardware architecture... I mean hardware having legacy security issues? Come on!

I also loved this: "each of the attacks seemed somehow mitigated by various, often accidental circumstances". Forget security through obscurity, we have security through accidental circumstances! :) Brilliant!

Danny Fullerton said...

Joanna, would you agree to say the x86 arch is getting too complicated and that even Intel itself can't seem to figure it out? You managed to do some tricks (e.g. SIPI using MPI) which by no means were supposed to work.

I'm no expert on CPU architecture but from what I seen, others like POWERPC were extremely simple and lean (easier to get right) if I compare with the x86.

I guess we'll have a new player the day Microsoft with bring ARM to the big table. Maybe this will force Intel and, particularly, AMD to put an end to the historically *adapted* (not to say *frankensteined*) x86.

Congrats to you Joanna and Rafal!

Anonymous said...

Intel has been warning about interrupt remapping since at least 2006.

http://www.intel.com/technology/itj/2006/v10i3/2-io/5-platform-hardware-support.htm

Anonymous said...

It's interesting that your paper outlines that x86 doesn't differentiate between exceptions and interrupts and yet you were blocked by the APIC's treatment of interrupts requiring an EOI ;) PowerPC and ARM treats exceptions and interrupts the same way so which other architectures did you have in mind that didn't do this?

joanna said...

@Anonymous: So, where exactly does it say that without IR your VMM can be 0wned? And why has Intel been selling client VT-d-enabled systems without IR for over 3 years if they were so aware of those attacks?

Regarding your next post: if you read the paper carefully you would notice The Exploit were not blocked by EOI...

BTW, why do you post as anonymous? Of course we know who you are anyway, but why be ashamed of your identity?

Anonymous said...

I have no association with Intel or AMD, but I have good knowledge of IOMMU. The main issue here is that device assignment to untrusted VM is unsafe unless IOMMU has interrupt remapping support. This is a bug in XEN that allows device assignment to untrusted VM without IR.

The interesting bit here is that while AMD supported interrupt remapping from day one, Intel only started supporting IR in VT-d2 which means VT-d only system should not be used for protection against device attacks but only for things like DMA verification etc.

All that said, the overall tone of your message does not sit well. In the past I used to respect you for your research but lately it has started to come off too egotistical and a marketing tone. Yes, the attack you created is novel but everyone who understands how IOMMU works knows that without IR it is easy to, at least, carry out a DOS attack by generating SMI and other interrupts.

joanna said...

@Anonymous, the whole point of the paper was to show that IR is required not only as an anti-DoS protection, but also as an anti-0wning protection.

For some people the difference between a DoS attack vs. a code execution in the hypervisor is dramatics

And the paper actually makes this point very clear. So, either write something more interesting next time, or just go away.

(Ah, that was egoistical, wasn't it? Or even arrogant! Tsk, tsk, our PR department is gonna kill me. Hush!)

Anonymous said...

(different anon)

I am still trying to understand the paper... couple of questions

If I understand right, SIPI requires a init interrupt which is something you can send with MSI too ?

There seem to be just a bunch of broken things on the part of Intel... the interrupt remapping was an accidental security. But in the fix, it seems Intel can also; disable MSIs that use 110b, disable writes to 0xfee.....H using scatter gather: doing these two things wouldn't break anything right?

joanna said...

@Different Anon:

1) Yes, it should be fairly simple for Intel to modify LAPCI to not interpret incoming MSI messages with delivery set to 110b as SIPI, and just discard them. As we wrote in the paper, there should be no reason for allowing devices to deliver INIT/SIPI to processors.

2) No, you cannot block writes to 0xfeeXXXXX, because this would break legitimate MSI delivery from devices and would break lots of things.

As we wrote in the paper, we think it was a mistake to use an in-band mechanism for MSI signalling -- why not use a separate PCIe packet type for this? Smells of bad design of PCI Express. Too late to change that now, though.

3) I wouldn't call Interrupt Remapping an "accidental" security mechanism. No question that many people at Intel realized problems of allowing devices to deliver MSIs. Just that perhaps few people (if any) realized that: 1) This could be achieved via tricks such as scatter-gather, not requiring even an MSI-capable device, and not requiring permissions to write to devices' MSI config registers, 2) that such MSI delivery could result in practical hypervisor 0wning, rather than just a simple DoS.