Thursday, March 19, 2009

Attacking SMM Memory via Intel® CPU Cache Poisoning

As promised, the paper and the proof of concept code has just been posted on the ITL website here.

A quote from the paper:
In this paper we have described practical exploitation of the CPU cache poisoning in order to read or write into (otherwise protected) SMRAM memory. We have implemented two working exploits: one for dumping the content of SMRAM and the other one for arbitrary code execution in SMRAM. This is the third attack on SMM memory our team has found within the last 10 months, affecting Intel-based systems. It seems that current state of firmware security, even in case of such reputable vendors as Intel, is quite unsatisfying.

The potential consequence of attacks on SMM might include SMM rootkits [9], hypervisor compromises [8], or OS kernel protection bypassing [2].
Don't worry, the shellcode we use in the exploit is totally harmless (have really no idea how some people concluded we were going to release an SMM rootkit today?) — it only increases an internal counter on every SMI and jumps back to the original handler. If you want something more fancy, AKA SMM rootkits, you might want to re-read Sherri's and Shawn's last year's Black Hat paper and try writing something they describe there.

The attack presented in the paper has been fixed on some systems according to Intel. We have however found out that even the relatively new boards, like e.g. Intel DQ35 are still vulnerable (the very recent Intel DQ45 doesn't seem to be vulnerable though). The exploit attached is for DQ35 board — the offsets would have to be changed to work on other boards (please do not ask how to do this).

Keep in mind this is a different SMM attack than the one we mentioned during our last month's Black Hat presentation on TXT bypassing (the VU#127284). We are planning to present that other attack at the upcoming Black Hat Vegas. Hopefully this will not be the only one thing that ITL will entertain you with in Vegas — Alex and Rafal are already working now on something even cooler (and even lower level) for the show, so cross your fingers!

And good luck to Loic with his presentation that is about to start just now...

22 comments:

rémy said...

well thanks for it, gonna read for sure. Looks really interresting

Michael Evanchik said...

wow, stuned

Anonymous said...

Any thoughts on how mitigate the issue? Any work arounds? Can this be adapted to AMD processors?

Travis H. said...

Hi, I wanted to point your readers to my "Security Concepts" book, which has a chapter on hardware security, including a link to this blog:

http://www.subspacefield.org/security/security_concepts.html

Anonymous said...

Good stuff! Was looking forward to this.
Cheers,

Anonymous said...

Any thoughts on a way to test a motherboard/processor for this vulnerability as most BIOS vendors don't include much detail in their BIOS updates eg. CPU Microcode updated is usually what MSI says.

joanna said...

Any thoughts on a way to test a motherboard/processor for this vulnerability[...]?

How about running the cache-snooper?

David Hoelzer said...

Great work, as always! I know you deal with people arguing whether or not there is relevance to some findings (VM escapes on certain hardware) but they miss the point that any flaw is a potential security issue.

Keep up the great work.

Puppet Master said...

Have you also tried to attack PowerPC processors? If, yes...are there more difficult?

Awesome blog.

-tony

Othman said...

Does Intel IOMMU use caching? How about IOMMU cache poisoning? lol...

Othman said...

Joanna, Why should we allow the OS kernel to mark the SMM region as cachable WB in the first place since the SMM is handled by the system firmware? What about de-privileging the SMM (reduce its memory addressability)?
What about the cache size? Any limitations to the attack?

Instructions accessing MTRRs and probably all MSRs are considered privileged and should require kernel privileges (e.g, WRMSR) anyway.

Can we rely on BIOS vendors to secure this security gap?

Anonymous said...

This exploit requires that the supervisory OS (hypervisor or kernel) allow modifying memory mappings, if you have attained that level of control over the system, you can get away with essentially anything. I don't see how this is somehow novel. Furthermore, the paper mentions, to paraphrase "escalation from usermode to SMM", and then they use IOPL in their usermode code. IOPL is privileged and if you're allowing non privileged users to do that, then your entire system security is compromised. What exactly is new here? All of this can be guarded against at the supervisory OS level.

joanna said...

@anonymous:

1) It is *trivial* to get into kernel of pretty much any general purpose OS, like e.g. Windows or Linux. We (Alex, Rafal, me) have demonstrated this many times for various OSes.

2) The whole point of the attack is that normally, even if you're the kernel ("Supervisory OS level" as you call it), you don't have normally access to the SMRAM, because it is locked by the BIOS.

gat3way said...

Hate to say that, but Linux completely sucks on that aspect. The iopl() syscall should have never been implemented (like in most BSD flavors). The idea that the superuser (ring3) can escalate its i/o privilege level to 3 and then access ioports and disable interrupts is totally flawed. A privileged process do NOT need to have access to I/O ports since virtually everything can be managed via ioctls.

Anonymous said...

My understanding is for this attack to work attacker needs write access to various Programmed I/O registers, which requires superuser privilege (Unless one is running Xserver). But if you already a superuser what more do you want? Damage the hardware?

What makes this attack different then any other attack? If one for example was able to escalate privilege to superuser.

Thank you for the great research, I read it once but I'm going to read it one more time. (or maybe two :))

joanna said...

@anonymous: You haven't read the paper carefully:
The potential consequence of attacks on SMM might include SMM rootkits [9], hypervisor compromises [8], or OS kernel protection bypassing [2].

Anonymous said...

Thank you Joanna! I read them, but I related them to user root which was a mistake on my part. Things don't stop on having user root. :)

gat3way said...

What do you mean by "hypervisor compromise"? I doubt this will work from a xen domU or dom0 context because 1) AFAIK you don't have access to MTRR registers from there 2) their kernels are running in ring1 not ring0.

Moreover, you will need some reliable way to trigger the SMM mode e.g by issuing a SMI.

In a particular case where the kernel is patched so that iopl() always returns -EPERM or -ENOSYS, loading LKMs is disabled as well as write access to /dev/(k)mem, is this attack still possible?

joanna said...

@gat3way: You might have noticed I wrote "of attacks on SMM", not "of the attack".

The current caching attack (probably) doesn't allow for Dom0->Xen escalation, but our previous attack (the remapping bug on Q35) did allow for that. Instead, the caching attack allows for TXT bypassing and also SMM rootkits installation.

gat3way said...

Uh-oh, sorry. I admit I still haven't read your previous work on those issues.

Anonymous said...

Congrats Joanna, nice job.

joanna said...

Don't forget about Rafal!