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

Comments

Ouch

[Big Hairy Ian]

This could make the apple bricking patch look like a kindergarten party

Re:Ouch

[machine321]

I was on the apple bricking patch for a while, it really helped me quit apple bricking.

But more importantly...

[Anonymous Coward]

... Joanna Rutkowska is hot!

Re:But more importantly...

[Anonymous Coward]

This is an even better picture. But it's not Joanna.

Easy workaround

[Anonymous Coward]

Run all code on a 286 or below.

Re:CD Boot

[CannonballHead]

No, really. It takes it over! You can't even come within 5 feet of the case, the malware pushes you back!

Re:CD Boot

[I.M.O.G.]

Haven't these guys ever booted from a CD?

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:

By design, the operating system cannot override or disable System Management Interupt (SMI) calls. In practice, the only way for you to know what is running in SMM space is to physically disassemble the firmware of your computer. So, given that an SMI takes precedence over any OS call, the OS cannot control or read SMM, and the only way to read SMM is to disassemble the system makes an SMM rootkit incredibly stealthy!

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.

Ring of Fire

[goombah99]

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:Ring of Fire

[blueg3]

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.

Inexcusable

[sjames]

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

[Animats]

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.

Re:Doesn't seem that scary

[sjames]

It's much worse, when combined with a firmware re-write, it will survive a complete re-install and cannot be detected by a security scan booted from CDROM.

Re:CD Boot

[antifoidulus]

While you succeed at being snarky, you fail at being correct.

Dude, I think you came up with a new motto for slashdot!

Re:Ummm, about that

[FrankSchwab]

As a firmware engineer who patches ROM code in embedded systems daily, I'll give a bit of insight.

The BIOS as a whole is specific to the board that it is running on. However, that doesn't mean that additions can't be made to the BIOS in a generic fashion. Imagine you searched the BIOS Flash for unused space (all of them will have it), and relocated code into that space (relocating a DOS .exe file is trivial). Writing a FLASH is not a difficult operation, though different motherboard manufacturers probably write protect it in different ways. Your code is now in the BIOS ROM.

You then modify the code in the flash that handles e.g. INT 14 (Serial communications, pretty much a dead function on modern PCs). This is nothing more than overwriting the first couple of bytes of the address pointed to by the INT14 vector in the flash - you store them in your patch area, and JMP to your routine. Once again, it's a Flash write.

Now, certainly, at some point in time (BIOS, probably) someone will attempt to enumerate/initialize the serial ports. Your code is now running - the world is your oyster. With this exploit, you can now probably hoist the BIOS code into a VM PRIOR to loading Windows. And you're still there.

There are different families of BIOS that you would have to support - Phoenix, AMI (do they still exist?), HP, Intel, etc. There are different schemes for protecting Flash, etc. These differences are probably smaller than they sound.