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.

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!

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.

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.

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.

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.

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 :))

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?

@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.