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

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.

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.

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.