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 potential consequence of attacks on SMM might include SMM rootkits [9], hypervisor compromises [8], or OS kernel protection bypassing [2].
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...
20 comments:
well thanks for it, gonna read for sure. Looks really interresting
wow, stuned
Any thoughts on how mitigate the issue? Any work arounds? Can this be adapted to AMD processors?
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
Good stuff! Was looking forward to this.
Cheers,
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.
Any thoughts on a way to test a motherboard/processor for this vulnerability[...]?
How about running the cache-snooper?
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.
Have you also tried to attack PowerPC processors? If, yes...are there more difficult?
Awesome blog.
-tony
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.
@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.
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 :))
@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].
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. :)
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.
Uh-oh, sorry. I admit I still haven't read your previous work on those issues.
Congrats Joanna, nice job.
Don't forget about Rafal!
Post a Comment