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

And thus does the dance continue...

[downix]

The dance between malware writers and the security experts seeking to thwart them continues ever on.

Wait, what?

[girlintraining]

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.

Re:Wait, what?

[girlintraining]

It might be more accurate to say the OS does not manage or provide services for the SMM. Any code executing in the OS with sufficient access rights can make "unsafe" calls to trigger SMM events, or to any other hardware device in the system. The OS only recognizes the SMM to the point of saying "If you don't finish what you're doing within N clock ticks, I'll crash", and then it syncs with the clock upon the SMM releasing control back to the OSS. If it exceeded that timeframe, the OS simply throws its hands in the air and says "Frack you." Anything loaded into the SMM would have to be very compact, and would be incidentally detectable much the same way software can detect when it is running in a VM -- by looking for delays.

more nonsense from the same people

[YesIAmAScript]

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.

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!

Wow

[quo_vadis]

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.