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.
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 Wikipedia:
Joanna Rutkowska claims that, since any detection program could be fooled by the hypervisor, such a system would be "100% undetectable".
Articles about this exploit are referring to this "Blue Pill" ordeal (a Matrix reference I'm guessing) which was a rootkit using AMD-V/VT-x. Hypervisors, as they're currently exists, are not 100% undetectable and that rootkits could use AMD-V was not unexpected.
This new SMM exploit could is just an upgrade to that Blue Pill thing. Unless they manage to get into SMM from usermode I'm leaning towards "sensationalism".
Guess we need to start booting from CD every time we scan for viruses?
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.
IOW it's like the Blue Pill rootkit except possibly harder to get rid off/detect if you get infected and no need for AMD-V/VT-x support in the CPU.
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
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.
Where does it say that? I read the PDF, it talks about modifying RAM. RAM is cleared after a reboot.
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.
This is true even without the SMM exploit.
While you succeed at being snarky, you fail at being correct.
Dude, I think you came up with a new motto for slashdot!
Monstar L
I think some of you people haven't been outside in so long that you've degenerated into finding ANY woman attractive.
Hole and a heartbeat. It's never failed me.
It is dangerous to be right when the government is wrong.
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
If the bios is compromised, then this won't help.
It is the bios that loads the boot sector.
This is worrisome...
Why? VMWare needs to virtualize the hardware because it can't give the VM exclusive access to real hardware; but an SMM rootkit can. You can let the OS access the hardware directly to its heart's content, you're simply interested in controlling some memory locations - say, listening to keyboard and occasionally sending some network packets, or perhaps starting a process in the OS.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
You let hardware use DMA, all your hopes of invisibility are gone. DMA means just that: Direct Memory Access.
NSA, CIA, Total Information Awareness, etc:
a simple place to store a backdoor...
How many of us physically secure *all* of our hardware when we're done using it? Hell, how many of us do this when we leave the house? Not many, I'd wager.
There are *far* easier ways to inject malicious devices into our systems than this.
Not on your desktop you don't. Your hardware still works via DMA. Remember the recent firewire problem related to that? It is heading that way but DMA is still heavily used in current systems.
My roommate and I both got hit with "Gnats' Ass" virus back in the mid 90's. It was nasty, embedded itself in executables, MBR, any CDs we burned... My roommate had it stuck in his BIOS even *ouch*. A virus written in assembler doesn't have to be huge, or hit all motherboards, just enough of the right ones to propagate.
When you want something built, come see me. If you want correct grammar and spelling, get a F*ing liberal arts student.
you modify BIOS, store a loader in there, load your code back in SMM space before the floppy/disc drives are accessed.