Intel CPU Privilege Escalation Exploit 242
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."
Re:Ouch (Score:5, Interesting)
Just consider a malware that replaces the PC BIOS with it's own code. Sure it may brick a few, but it may also be a new interesting level of malware.
Write-protect your BIOS:es and you can be a bit safer.
Another interesting thing is that this may be a way around the TPM chip and other copy-protection techniques too.
And beware of special bioses from manufacturers that allows your employer to run keylogging!
Ring of Fire (Score:5, Interesting)
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.
Re:CD Boot (Score:5, Interesting)
And you fail at understanding.
The exploit talks about modifying SMRAM. It's done with root level access on the computer. And in my understanding, the effect is not permanent, since you're changing RAM. Reboot, and it'll be gone.
Now, once it's there, the OS can't have an antivirus scan that memory area. But that's it. If this thing persists across reboots, something has to put it back into the SMRAM, and you could find that something by booting a scanner from a CD, or reformatting the computer.
I don't see this as a particularly scary thing. Yes, it's nasty. But a virus could also disable antiviruses and patch the kernel to hide its presence for the same effect.
This is the same scaremongering as with the virtualization virus. Yes, it's a new way a virus can use to hide. But it's absolutely nothing new. Under DOS, viruses would trap DOS calls, and remove themselves from opened files, so that an antivirus trying to scan the file would see an uninfected one. Boot from a floppy, and none of that trickery will be active.
Inexcusable (Score:5, Interesting)
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.
Re:CD Boot (Score:2, Interesting)
BTW if #2 is true, then it really is a huge threat -- and we'd all be better off going back to EPROMs and ditching the ISP flash ROMs, or at least having some sort of hardware read-only switch or jumper on motherboards limiting access to overwriting flash ROMs.
Re:CD Boot (Score:2, Interesting)
Actually, this IS new in that it's using a low-level exploit that previously wasn't known.
Also, the virus could use a commonly available BIOS utility to flash malware into the cmos.
Much, much more insidious than a traditional file-based root. Then it's there on every boot.
How exactly would you even KNOW you were infected by a BIOS-based kit? That's the question.
I take particular (if momentary) satisfaction in owning ONLY AMD based platforms.
I'm sure there will be some exploit or another for them someday, but for now... it's fanboy gravy.
Fight it with the same weapon? (Score:3, Interesting)
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?
Re:Inexcusable (Score:5, Interesting)
Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work.
Yes. And board manufacturers get really angry when someone detects that.
In the QNX community, where "real time" really means something, there's a common test of the operating system's real-time response. The tester wires up a square wave generator to an input that will cause an interrupt, programs the computer to wait for the interrupt and start a real-time user process, and has the user process turn on an output. You run some program in the background to keep the CPU busy. On a serious real-time OS, this shouldn't hurt real time response, and on QNX, it doesn't. There are no long interrupt lockouts in the QNX microkernel. Drivers are interruptable user processes.
Input and output lines are then wired up to a storage oscilloscope, to display the interrupt response. On most machines, the scope shows a nice, boring, consistent interrupt response time of a few microseconds. But on some CPU boards, there's a spike way out there from the expected delay period. This shows clearly the occasional huge delay (by real time standards) of hundreds of microseconds, maybe even more than a millisecond. That's because something is going on in System Management Mode. QNX programmers have found USB serial emulation, flash disk IDE emulation, and other crap running at SMM level.
When a vendor gets caught doing this, word gets around in the real-time community that their board is unacceptable for real-time use. Vendors selling embedded system boards have been caught this way.
Hard real time is a world in which stuff is expected to actually work every time.
Also, like the virtualization scare (Score:4, Interesting)
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.
Re:Ummm, about that (Score:4, Interesting)
In PC land most modern BIOSes are designed to be modular and the tools to manpulate them are readily available for free. They usually have enough left over space in flash for a malicious extension to be added. A malicious extension doesn't have to be a complete exploit. It just has to provide the hooks for a compromised OS to call into and execute a small bit of code that would otherwise be impossible to execute.
I wouldn't be surprised if Macs had similar BIOS vulnerabilities. They're potentially even more vulnerable since, because of the Apple monoculture, all Intel Macs likely have similar BIOS code and a single exploit could easily attack the entire population. This is a growing threat with Apple's increasing market share. The days when nobody bothered to write viruses for Macs are long gone.
Re:more nonsense from the same people (Score:5, Interesting)
So, never run any VMs, then? Or only allow "trusted users" to run VMs?
Because if I'm a malicious user, I can gain root in my VM hosted on your box through a local privilege escalation attack. Then, I not only gain access to your hypervisor, but to every other VM instance on that machine.
Sweet.
Good thing that no one would ever use a VM, isn't it?
I'm a little confused. (Score:3, Interesting)
SMM is volitile, so anything trying to load itself there would have to have a presence on the HDD, where it could be found by an anti-virus (even if it had to be one from a clean boot-disk).
If SIMM is inaccessable, then how does the root-kit access it. If the root-kit can access it, then how is it inaccessable?
Last I checked, the CPU SMM doesn't directly connect with other computers. That requires using the network card, which is attached over the bus to a controller (south-bridge?), all of which is potentially monitorable. Then it has to interface with that card (does the exploit include deice drivers for PCI, PCI-E, the network card, etc?) which in turn has a TCP/IP stack (does the SMM package contain that too? Otherwise it seems it's interfacing with the OS and that interface could be monitored) using an IP address that the router will accept (again an action outside the SMM), and sending packets (again monitorable).
Or am I just clueless here?
Re:CD Boot (Score:1, Interesting)
1. Neither. It applies to "recent" intel cpu and hipset combos. No idea which or how recent. i7 is most recent but core2 based systems running on intel chipsets would be most likely targeted.
Fixed that for you (Score:3, Interesting)
I'll reserve my judgement on this until I read more from someone that owns a clue.
I assume you meant "powns a clue".
There's no "o" in "pwn"...
Of course, I seriously question the taste of anyone who would use "pwn" in their discussions...
Re:CD Boot (Score:1, Interesting)
2. It doesn't do this. Though if you've ever run a bios/firmware flash in windows and did not afterwards disable this capability in bios your system is already exposed to any old installer you run.
Re:Wow (Score:4, Interesting)
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?
Re:CD Boot (Score:3, Interesting)
Looks to me as though this would in fact mean that a recovery disk would not help you. A recovery disk would merely boot an OS, just like booting from your hard disk boots an OS. If the SMM escalation code is in your BIOS, and gets executed before any OS gets booted, and once executed is undetectable by any OS, how exactly is a recovery disk going to help you?
In short, you quote GP: "Then it's there on every boot". Then you say "Yeah. But it's only there on a single boot". Which one is it?
Re:Ummm, about that (Score:3, Interesting)
On several boards I've been unfortunate enough to mis-flash, the fix was to find another board of the exact same model, pull the BIOS, install into the busted board, boot, remove the BIOS after it has booted (still powered on,) plug in the old BIOS, reflash.
I don't know if this approach works any longer. The last time I did this was about 7 years ago.
Re:And thus does the dance continue... (Score:2, Interesting)
The dance between malware writers and the security experts seeking to thwart them continues ever on.
Yeah, except this exploit method allows the defenders to pretty easily slam the dance partner to the floor.
Simple defeat method:
BIOS coders write in a checksum routine that runs at system initialization time. The routine checks the board maker's original (i.e. known good) BIOS file size on the flash device against the current used spaced on the device upon every boot. If the checksum routine finds that the used space on the flash device has changed, set off bright red alarms and noises. Obviously this is a *per rev* size, so each new BIOS update offered by the board maker will include the proper size check and checksum code. Thus, flashing your mobo with an update having a different file size won't set off the alarms, but unauthorized changes to the used space on the flash chip will set off the alarms.
To defeat this countermeasure, the exploit coder is actually going to have to rewrite part of the original BIOS to defeat the checksum process along with burning their own extra code in the empty space.
This seems like pretty simple stuff. The problem would be non-l337 mobo owners who ignore the alarm for a myriad of stupid reasons, as with many lusers who ignore problems on their PC until it's 'too late'. For the rest of us, this should be a sufficient countermeasure.