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."
The dance between malware writers and the security experts seeking to thwart them continues ever on.
Karma Whoring for Fun and Profit.
This could make the apple bricking patch look like a kindergarten party
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Haven't these guys ever booted from a CD?
Seastead this.
... Joanna Rutkowska is hot!
Run all code on a 286 or below.
Wait... You have to get your code running in ring 0 and then you can do anything you could do with ring 0 access? Wow. Quite an exploit. -_- And a reboot removes the code.
#fuckbeta #iamslashdot #dicemustdie
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.
So it says you can promote from ring0 to SMM. So I take it that's a lower level of hell?
If you are running in ring zero doesn't that mean by definition you are completely trusted anyhow?
Or is the vision something like you enter your root password to install the cheeze-whiz app and the mal ware not only installs the code but escalates itself above the operating system.
I think I'm not getting it.
Some drink at the fountain of knowledge. Others just gargle.
Considering that SMM exists solely to help proprietary vendors hide the "secret sauce", this is inexcusable. Every legitimate use of SMM could be accomplished by telling the OS that the memory area is reserved without hiding it away.
The most frequent use is to have a proprietary chipset device emulate a standard one without revealing the details of its operation.
Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work. Kinda like those onboard "RAID controllers" that are just a plain old IDE interface and a poorly implemented softraid in the proprietary driver. The next step from that is to hide the softraid in SMM and have an SMI trigger whenever the OS writes to the fake registers in the PCI space.
These people (I refuse to type their names) employ hype incredibly effectively.
The implications of these exploit are incredibly minimal. They might help a rootkit hide a little better, but they don't make it any easier to install one.
If you have malicious code running in ring 0, you're already so boned, you really need to dust off and nuke the machine from orbit anyway. And if you have malicious code that modified your BIOS (as some people list as a nightmare scenario), you again already have problems so large a little bit of SMM trouble means little additional pain.
http://lkml.org/lkml/2005/8/20/95
Very interesting loophole. For those too lazy to read TFA, basically this attack allows someone running as root (or in some cases as a local user) to run code at a level that even hypervisors cant deal with. To put this into perspective, if you are running some big iron hardware with a dozen virtualized servers. With a local privilege escalation exploit on one VM, an attacker could use this attack to take over the whole system, even the secured VMs. Worst problem is that it would be undetectable. No VM, and no hypervisor would be able to see it. Any AV call can be intercepted as the SMM has the highest priority in the system.
The solution on the other hand seems pretty simple. Make the chipset block writes to the TSEG for the SMRAM in hardware (by disabling those lines) and use some extra hardware to prevent those lines from being loaded into cache. Finally, make every bios SMRAM update contain a parity and create tools that allow SMRAM parity check.
Legally obligatory sig : My opinions are my own... etc etc
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.
TFA: >>"No software you can run on your operating system would be able to detect this type of exploit once you are powned"
Ok this might be a stupid suggestion, but if it's possible for the malware to use this vulnerability to elevate, why wouldn't the "software", say Antivirus, use the same vulnerability to detect it, or remove it?
Strikes me as "Neat in theory, doesn't work in practice." I mean after all the talk about blue pill, you'll notice that attacks of that type are not, in fact, happening all over the place. Why? Well while it is easy to say "Oh you just hide as a hyper visor," it is much harder, I'd say impossible, to actually make a program to do that and not be noticed.
For example one thing you have to do is properly virtualize ALL hardware. I'm not talking about doing a network card or a graphics card, I'm talking all of them. If you want to be undetectable, it has to look just like the stuff in the system. You can't be having a system with a real Intel Pro 1000 showing up as an AMD PCNet adapter (this is what happens in VMWare, all net cards are AMD PCNet). This includes things like 3D cards. You want to fool me, you have to virtualize my GTX 280. It has to run at speeds consummate with the real thing, and with the same features. If not, I'm going to notice something is wrong and go looking for the reason.
Rutkowska strikes me as an "ivory tower academic" in that she seems to be real good at coming up with theoretical stuff, with no consideration of how it applies to the real world. Now that's fine, nothing wrong with investigating theoritical means of attack, however she's also a scare monger/over seller. These things are getting promoted as The Next Big Thing(tm) even though there's no consideration for how realistic they are to implement.
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.
To put this into perspective, if you are running some big iron hardware with a dozen virtualized servers. With a local privilege escalation exploit on one VM, an attacker could use this attack to take over the whole system, even the secured VMs.
Are you sure that's what it means? It looks like it needs ring 0 not kernel. Kernel mode would be less than ring 0 where a hypervisor was used. Or does KVM run all kernels at ring 0?
I for one would like to welcome our new flaming devil overlords