Slashdot Mirror
Intel CPU Privilege Escalation Exploit
Eukariote writes "A paper and exploit code detailing a privilege escalation attack on Intel CPUs has just been published. The vulnerability, uncovered by security researchers Joanna Rutkowska (of Blue Pill fame), Rafal Wojtczuk, and, independently, Loic Duflot, makes use of Intel's System Management Mode (SMM). Quote: "The attack allows for privilege escalation from Ring 0 to the SMM on many recent motherboards with Intel CPUs. Rafal implemented a working exploit with code execution in SMM." The implications of this exploit are severe."
You're assuming that the rootkit isn't loaded before the bios tries booting off the CD.
From the PDF:
If they can do that, your box is rooted already. The only difference seems to be that in this way it can hide in a place where the OS can't get at it. But IMO, if you're compromised you can't count on the compromised OS being able to remove everything malicious anyway.
While you succeed at being snarky, you fail at being correct. Assuming the article is credible and accurate, it explains why booting from a CD won't save you:
Now with that said judging by the authors language at networkworld he likely doesn't fully understand whats going on - he uses words like "powned" and "the PC is living in the matrix", whatever the fuck that means! I'll reserve my judgement on this until I read more from someone that owns a clue.
Overclockers
Hopefully this guy is playing for the good guys:
http://blogs.zdnet.com/security/?p=2934
Nerd rage is the funniest rage.
I'm an idiot. That was supposed to be a reply....
The exploit allows access from Ring to SMM? Summary is confusing but I think we're talking about an exploit that can write to bios even with flashing disabled at the bios level.
"The Adobe Updater must update itself before it can check for updates. Would you like to update the Adobe Updater now?"
Several EE students found a similar exploit for the Motorola 68010, way back when (early 80s). Bumped the user into supervisor mode with a little register manipulation. At least Motorola sent us updated models after they fixed their undocumented stack issue.
Invenio via vel creo
Of course I didn't read TFA, but it doesn't sound like this exploit has shown up in any malware yet. At this point the potential for attack has just been demonstrated.
A cording to some other commenters, the exploit code must run in ring 0, so you already have to be rooted for it to work. In a nutshell, this vulnerability can't be used to infect your OS in the first place, but it can potentially make detection and removal near impossible.
The obvious implication of this exploit, if SMM is truly more privileged than the hypervisor, is to escalate from root on one vm to root on other vms on the same box. That could be pretty devastating, both for hosting providers and security researchers.
On another note, I know nobody RTFA around here, but ya gotta love this quote:
Intel feels that it has a solution in SMM transfer monitor (STM). The premise is that STM places SMM in a sandbox as Intel explains further:
Lock-based synchronization has known pitfalls: using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory is proposed to simplify parallel programming by supporting âoeatomicâ and âoeisolatedâ execution of user-specified tasks.
Gotta love acronym confusion! (That second paragraph is describing Software Transactional Memory, which is totally unrelated to the proposed SMM Transfer Monitor.)
I hereby place the above post in the public domain.
My understanding is that "SMM space" refers to an area of memory even the OS kernel can't access, but doesn't mean it's anything that persists across reboots.
If I got it correctly, an userspace app can't write to kernel memory, and the kernel can't write to SMM memory, but it's RAM all the same, and located on the RAM modules plugged into the motherboard and not any particularly special place.
I think this bypasses bios write protection unless you still have a motherboard that uses a jumper for this. None of mine do.
Could be used as a force for good, true.
"The Adobe Updater must update itself before it can check for updates. Would you like to update the Adobe Updater now?"
Actually, as I recall, the hypervisors run in ring 0 and generally push the kernel up to ring 1.
Anyway, jumping to the hypervisor level is Blue Pill, by the same people. That was a few years ago. This is actually jumping to a lower level (below that of the hypervisor).
If you're playing the rootkit versus rootkit detection / prevention game, attacking a lower level than your opponent is powerful. A rootkit detector in the hypervisor has an enormous advantage over a rootkit in a VM, and vice versa. A rootkit at the SMM level has an enormous advantage over rootkit detectors at the kernel or hypervisor levels -- which is the lowest easily-accessible level.
Note that these guys did propose a solution in the same talk they presenting this problem.
How you going to make that work? I'm not talking in theory, I mean in practice. Reprogramming the BIOS is not a simple feat. There's all kind of problem you face that you don't with a program that runs on the OS:
1) Extremely limited space. BIOSes are small. You don't have gigabytes of space, you don't have many megabytes. Sometimes, you don't even have a megabyte. So whatever code is in there, it is going to be rather limited. More so because you can't simply displace the BIOS. The BIOS is necessary to the system's operation (and of course if the BIOS was gone and replaced with something new, people could know your malware was installed). So you have to preserve the BIOS's function AND add in what you want to do in a very small space.
2) Highly system specific. BIOSes are not general. You can't take one from a given board and load it on another board. Even within the same manufacturer and general product line BIOSes are not cross compatible. Flash the wrong BIOS on a system, and it isn't booting. So that means that your malware is going to have to be either extremely targeted, as in work on only one specific type of system, or carry around a massive pack of different versions to load the one with the correct BIOS.
3) Not made to run other programs. The BIOS isn't designed with the idea that you run other software with it. It is designed to set up the system and then load the bootloader. So this means that you don't just write a program and load it on, you have to actually redo the BIOS. Ok, but you don't have the source code for that. Motherboard makers don't open source their BIOSes.
4) Getting it on systems. Some boards, Intel notably, allow you to update the BIOS from an OS. Their updater actually preps the update to a section for that, and the update is then done on next reboot. However many boards don't have that feature. To update the BIOS, you need to boot to a DOS floppy/CD/flash drive and do it from there. Ya, not so easy to arrange as malware.
So while a BIOS malware that does things pre boot is a theoretical possibility, it is extremely unlikely in reality.
AFAIK, it can do that from Ring 0, too. About all SM mode does is allow you to temporarily inject yourself under the kernel in an undetectable way for a single boot; if you don't delete yourself from disk, you can still be detected by virus scanners and deleted, at which point your code would go away on the next boot... unless you start sniffing disk block writes and try to hide your files from the virus scanner. Either way, AFAICT, a cold boot from a recovery disk can clean up anything you could do in SM mode that you couldn't do from ring 0.
These attacks have been around for a while. Here's an article about an attack that obtains SMM access (from user space code in that case) from way back in 2006. The only thing that's new is that this is a new/different way to get into SM mode.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Not many BIOSes actually protect BIOS write access through an SMI trap. There are a few more bios protection mechanisms though, like WP GPIO lines to the flash chip that can only be reset on a power cycle. So you'd need physical access for an attack.
It seems there is a lot of confusion about what this actually does. We're talking about RAM, albeit an area not normally accessible outside the BIOS, so it's not more resilient than anything else hiding in RAM. The BIOS writes code into the SMRAM at reboot, so even if the RAM isn't cleared, it's overwritten.
This is unrelated to flashing the BIOS, unless there is some special protection that allows this only to happen in SMM, and normal exploits that manage to flash the BIOS would leave you pretty screwed, SMRAM-exploit or not.
Also, it needs to trigger a SMI to execute the code, so it would need to insert a vector somewhere at a lower level if the exploit code were ever to get executed. I don't see the big deal.
What does surprise me though is that Intel has made such an obvious mistake in their design. It compares to allowing a user mode app to poison the cache on some kernel memory address. The difference is, of course, that user mode is under MMU and access protection, while ring 0 (from where this attack would normally be launched) is not.
At any rate, at least root access (on Linux; more on Windows) is needed, at which point, as several people have pointed out, you're screwed to begin with. Only the ability to hide a bit better in memory (but not on disk) seems to be an advantage.
That was back when the term was coined. These days we have IOMMUs.
It's stunning how many people commenting on this story haven't the slightest idea what they are talking about, yet feel compelled to chime in anyways. Even by slashdot standards it's hard to read.
Some guy before you tried to claim that the hypervisor runs as ring 0 and "pushes" the kernel to ring 1. Nearly all just run all code in ring 3 and employ a combination of interrupt/exception catching and inline code scanning/patching. The ones using hardware virt just run in ring -1 as god intended.
Another armchair bios writer tried to argue about how no mere mortal could comprehend the bios well enough to inject malicious code into it. That gave me a good chuckle.
Don't get me wrong, my intent is not to berate you specifically, but I had to reply to one post in this thread, and I got as far as yours before I gave up on reading any more.
As for your claim, the need to virtualize all hardware known to man was quite funny. Yes all VMware vm's see an amd pcnet32 card. VMware is not virtualization. It only performs one type of virtualization. Hell, many would argue it's not even the best approach.
A tiny hypervisor can be written with the only purpose of its existence being to simply exist. It can only run a single OS (virtualization does not demand the ability to run multiple operating systems), and it can happily look the other way as that OS accesses all of the hardware on the system natively. The only reason vmware has to give a shit is because it wants to run multiple OSs and give them all a network card. This theoretical hypervisor doesn't need to fullfill any purpose or perform any function. It can be a dumb piece of software that just allows the single guest OS to execute without ever interrupting it or getting in the way.
Despite the hypervisor being dumb, it has complete control. It can potentially do whatever it pleases with impunity.