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.
This could make the apple bricking patch look like a kindergarten party
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Haven't these guys ever booted from a CD?
Seastead this.
This is *not* good.
... Joanna Rutkowska is hot!
Run all code on a 286 or below.
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 the PDF:
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.
I don't know anything about SMM, but it sounds from TFAs that the OS can't interact with SMM. If I am understanding this correctly, then what steps must occur for me to be infected? How does the exploit load itself into my machine?
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?
This could make the apple bricking patch look like a kindergarten party
A kindergarten party in a holodeck where all the attendees turn out to be old men.
Intel is extremely secretive about this kind of documentation on their processors. You barely get the bare minimum documentation when you have their Orange books.
This is probably why it took so long to discover the problem.
Intel has a number of really nasty micro-architecture bugs related to SMM as well... I wish they'd be more forthcoming about them so we can workaround them better.
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.
Some drink at the fountain of knowledge. Others just gargle.
Several EE students found a similar exploit for the Motorola 68010, way back when (early 80s). Bumped the user into supervisor mode with a little register manipulation. At least Motorola sent us updated models after they fixed their undocumented stack issue.
Invenio via vel creo
I'm about to flip out and kill somebody, namely the writer of that last article. First off, if you are a journalist, "powned" shouldn't be in your vocabulary. Secondly, its "pwned."
all your cpu's are belong to us. She totally walks the walk at ITL of everyone doesnt already know
I will not disclose a 0 day again I will not disclose a 0 day again I will not disclose a 0 day again I will not disc
Wonder if this will spawn a run on Mac G5's.
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.
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
I for one would love to torch the pile to BURN the evil these devils are!
Geez! What's this world coming to? These malacious programmers have found a way to create a trojan that gets into the small amount of SMM memory inside the processor and execute?? That's insane! So, now viruses can tell the KERNEL what to do!
Anyone in the know I'm sure wouldn't trust many, if any, anti-virus/malware companies from utilizing a tool like this... but imagine how it could potentially help the anti-virus companies. Rootkits, worms, etc wouldn't be able to disable the anti-virus software, as it wouldn't be able to detect it's even running, let alone try to shut down the anti-virus software. Plus, it would make hiding malware, worms, etc from the anti-virus software themselves!
Does this mean Apples are vulnerable?
The obvious implication of this exploit, if SMM is truly more privileged than the hypervisor, is to escalate from root on one vm to root on other vms on the same box. That could be pretty devastating, both for hosting providers and security researchers.
On another note, I know nobody RTFA around here, but ya gotta love this quote:
Intel feels that it has a solution in SMM transfer monitor (STM). The premise is that STM places SMM in a sandbox as Intel explains further:
Lock-based synchronization has known pitfalls: using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory is proposed to simplify parallel programming by supporting âoeatomicâ and âoeisolatedâ execution of user-specified tasks.
Gotta love acronym confusion! (That second paragraph is describing Software Transactional Memory, which is totally unrelated to the proposed SMM Transfer Monitor.)
I hereby place the above post in the public domain.
Darn,I was just considering upgrading my G4 Mac to an intel based Mac... Guess I'll wait a bit longer.
By the captcha is appropriate for this post... "trapped"
There should be some space in the processor to run "very trusted" software. This software could be self-updating anti-virus software (assuming the anti-virus company's website doesn't get hacked LOL imagine what would happen to all of our comptuers).. ok, nevermind what I just said...assume you can trust the files coming from the anti-virus site, our computers would be totally protected. Not even the operating system could touch or even detect this code. It could execute every so often (on start up?) and make sure there are no threats on ANY hard drive, USB drive, etc. It will fix any threats or warn you about threats that it couldn't take care of on its own (non-rewritable CD-ROM or DVD-ROM containing a boot sector virus)... Disk ejects on its own, system tells you never to insert it again!...THEN o/s boots!
hmmm cool idea!
Would you look at the brain on that chick...WOW.
If you do what you always did, you get what you always got.
This sounds way to similar to the exploit used in the book P1 -- over thirty years ago.
sigh.
I don't see anything about this in the article or on Wikipedia:
Does SMRAM get cleared when a system is rebooted? It seems like the stuff is stored in chip cache or, worst case, battery-backed bios. Cutting the power and removing the backup battery should be able to clear it, no? It's not much of a rootkit if you can remove it by unplugging your machine.
So is there any way to exploit this on a mac? It doesn't look like they've actually released information on how the attack gets the foot in the door yet.
Also, things get a lot more difficult when you are running on such a low level, not interacting with the OS or even the hypervisor. (it's like the difference between coding in VB versus assembly) They talk about it phoning home and downloading nasties, but really, even being able to use the NIC card could be quite an undertaking if you're doing it "by hand" instead of using drivers and OS calls. (so you're going to code a TCP/IP stack in the SMM are you? have fun with that...) Even if they do demo a howto, actually coding something useful may take an equal level of skill as the actual exploit itself required to create. This would at least limit its application.
Imagine the poor thing getting itself all moved into the SMM and then finding out it's on a mac. Um... what now?
I work for the Department of Redundancy Department.
Yet another good reason to use an AMD cpu!
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
For those who've no time or inclination to read the article:
1) The attacker should first modify system MTRR
register(s) in order to mark the region of system
memory where the SMRAM is located as
cacheable with type Write-Back (WB).
2) Attacker now generates write accesses to
physical addresses corresponding to locations
where the SMRAM is located.
3) Finally attacker needs to trigger an SMI, which
will transfer execution to the SMM code. The CPU
will start executing the SMM code, but will be
fetching the instructions from the cache first.
How you going to make that work? I'm not talking in theory, I mean in practice. Reprogramming the BIOS is not a simple feat. There's all kind of problem you face that you don't with a program that runs on the OS:
1) Extremely limited space. BIOSes are small. You don't have gigabytes of space, you don't have many megabytes. Sometimes, you don't even have a megabyte. So whatever code is in there, it is going to be rather limited. More so because you can't simply displace the BIOS. The BIOS is necessary to the system's operation (and of course if the BIOS was gone and replaced with something new, people could know your malware was installed). So you have to preserve the BIOS's function AND add in what you want to do in a very small space.
2) Highly system specific. BIOSes are not general. You can't take one from a given board and load it on another board. Even within the same manufacturer and general product line BIOSes are not cross compatible. Flash the wrong BIOS on a system, and it isn't booting. So that means that your malware is going to have to be either extremely targeted, as in work on only one specific type of system, or carry around a massive pack of different versions to load the one with the correct BIOS.
3) Not made to run other programs. The BIOS isn't designed with the idea that you run other software with it. It is designed to set up the system and then load the bootloader. So this means that you don't just write a program and load it on, you have to actually redo the BIOS. Ok, but you don't have the source code for that. Motherboard makers don't open source their BIOSes.
4) Getting it on systems. Some boards, Intel notably, allow you to update the BIOS from an OS. Their updater actually preps the update to a section for that, and the update is then done on next reboot. However many boards don't have that feature. To update the BIOS, you need to boot to a DOS floppy/CD/flash drive and do it from there. Ya, not so easy to arrange as malware.
So while a BIOS malware that does things pre boot is a theoretical possibility, it is extremely unlikely in reality.
TFA: >>"No software you can run on your operating system would be able to detect this type of exploit once you are powned"
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?
you remember the headlines here, when it was discovered that RAM doesn't disappear all its data instantly on poweroff?
That it's possible to make an attack stick across cold-boots?
( unless the BIOS scrubs the RAM, which only an idiot, like me, would enable for a default... )
If it can get into SMRAM, and SMRAM isn't scrubbed on boot, then maybe it bloody well CAN be there next boot.
I don't know the likelyhood, but I consider it *possible*.
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.
NSA, CIA, Total Information Awareness, etc:
a simple place to store a backdoor,
so evidence can be got/placed on ANYONE, anywhere, anytime,
and they can't get any "civil rights" BS going about it,
because they are prevented from knowing about the backdoor by hardware!
HEA-VEN, from Authority's perspective!
( anyone else remember how an attack was got into a network through a *printer* back in the Gulf War?
this is much more convenient )
That is how I read it. In fact, that's what the blog says:
The potential consequence of attacks on SMM
might include SMM rootkits [9], hypervisor
compromises [8], or OS kernel protection
bypassing [2].
If you get root on any VM on the system, you can take control of the system, not just the VM.
Not many BIOSes actually protect BIOS write access through an SMI trap. There are a few more bios protection mechanisms though, like WP GPIO lines to the flash chip that can only be reset on a power cycle. So you'd need physical access for an attack.
There's an open source alternative to the BIOS implementations from the usual oligopoly: coreboot. See http://www.coreboot.org/ It's noteworthy to say that coreboot is not subject to the SMM exploits we've seen lately, for several reasons: - coreboot is not using SMM if there is not a significant reason to do it. - coreboot is doing the SMM entry on the non-poisonable ASEG rather than via TSEG or HSEG. Oh, and of course you don't have to break into the code to see what it does, because we don't feel that we have to hide coreboot's weaknesses.
It seems there is a lot of confusion about what this actually does. We're talking about RAM, albeit an area not normally accessible outside the BIOS, so it's not more resilient than anything else hiding in RAM. The BIOS writes code into the SMRAM at reboot, so even if the RAM isn't cleared, it's overwritten.
This is unrelated to flashing the BIOS, unless there is some special protection that allows this only to happen in SMM, and normal exploits that manage to flash the BIOS would leave you pretty screwed, SMRAM-exploit or not.
Also, it needs to trigger a SMI to execute the code, so it would need to insert a vector somewhere at a lower level if the exploit code were ever to get executed. I don't see the big deal.
What does surprise me though is that Intel has made such an obvious mistake in their design. It compares to allowing a user mode app to poison the cache on some kernel memory address. The difference is, of course, that user mode is under MMU and access protection, while ring 0 (from where this attack would normally be launched) is not.
At any rate, at least root access (on Linux; more on Windows) is needed, at which point, as several people have pointed out, you're screwed to begin with. Only the ability to hide a bit better in memory (but not on disk) seems to be an advantage.
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?
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...
Bow-ties are cool.
Not that I've read the article or anything but it appears you need to insert Ring 0 code, that's kernel level code to exploit this. If you are in a position to insert kernel code you either are root or are capable of becoming root.
This is just another way to insert a blue pill to hide your presence but it's not really that much better than a well thought out root kit.
Posting AC becuase I really am a coward but MS Rutkowska is just ridiculously hot - brains, beauty, bitch-slap my loser arse...
Very convincing indeed, I think from this point on, we can now all agree, Anonymous Coward is gay! ... [looks up] oh wait a moment
If this is true with this exploit (as I assume it is), this is a big deal.
VMWare is currently of the opinion that it is an OK practice to collapse security zones (eg DMZ/App/DB servers) onto the same physical host.
Even their documents on PCI compliance with virtualization doesn't say this is a bad idea.
People in the real world are using VMs as a substitute for more traditional physical security boundaries. If an exploit like this can allow you to VM hop (even if difficult), targeted attacks against PCI compliant institutions are not unlikely.
Anyone really want another Hearland?
Was this not paraphrased in mid-2007 by Theo of OpenBSD fame?
I have a free online book here: http://www.subspacefield.org/security/security_concepts.html It covers this attack and some other hardware attacks in this section: http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc8
>What does surprise me though is that Intel has made such an obvious
>mistake in their design.
The funny part is that they patent the exploit and fix some years ago : http://www.freepatentsonline.com/y2008/0209578.html
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.
As if that weren't a contradiction in terms.
This points to the underlying problem though:
SOMEHOW the hardware must support protection of the bios code or you are screwed -- no matter what security architecture you layer on top of it. What is strange is not that there would exist exploits like this, but that hardware manufacturers would be, after all these decades of manufacturing PCs, still be making systems that don't have hardware protection of their bios boot code.
Seastead this.
Scary eh? How accurate is Dilbert really when it comes to managers? Or err ... do we need to break out the tinfoil hats?
Wouldn't you just use the exploit to run some software to detect if the rootkit exists? I mean, the OS can't detect the rootkit in the SMM, but other software that's been esc'd can no?
You remember ... when it was discovered that RAM doesn't disappear all its data instantly on poweroff?
[Does that enable] an attack [that] sticks across cold-boots?
The RAM content may persist. But you know darn well it won't be executed until it's been overwritten. If it were the machine would have been executing random code on every boot and typically flaking out as a result.
So, no, I don't think persistence in powered-down RAM is a significant threat.
(I could imagine it being exploited, though, by a small amount of code that got burned into flash which checked a larger block in RAM to see if it had survived and, if it had, executed it.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
No, seriously..
---- Booth was a patriot ----
Breaking out of a VM is like an alchemist transmuting lead to gold. It's a lot harder than it seems, and most of the claims to success are pretenders. I'm sure it will eventually be possible - but the researcher behind this paper is not clever enough to realize when she has failed. (VMware and KVM experts challenged her to write this "undetectable hypervisor" she keeps using as a payload for these "exploits"; she stated that such a thing was trivial academic exercise, yet the world's virtualization experts uniformly believe such a thing is all but impossible. Take anything Johanna Rutkowska says with a very large grain of salt.)
A witty [sig] proves nothing. --Voltaire