Slashdot Mirror
Researcher Exploits 18-Year-Old Design Flaw To Compromise X86 Chips
jfruh writes: Security researcher Christopher Domas has demonstrated a method of installing a rootkit in a PC's firmware that exploits a feature built into every x86 chip manufactured since 1997. The rootkit infects the processor's System Management Mode, and could be used to wipe the UEFI or even to re-infect the OS after a clean install. Protection features like Secure Boot wouldnt help, because they too rely on the SMM to be secure.
I use Alpha 21264 you insensitive clod!
Only the State obtains its revenue by coercion. - Murray Rothbard
everybody knows who originally requested it.
Bush? Obama?
It is unwise to ascribe motive
http://www.infoworld.com/article/2653209/security/hackers-find-a-new-place-to-hide-rootkits.html
We already knew this kind of thing was possible, so I guess this is just the first practical implementation? The article is short on details.
Obama is Bush - he is just wearing a mask
SSB1c2UgYSA2NCBiYXNlIHByb2Nlc3NvciwgeW91IGluc2Vuc2l0aXZlIGNsb2QgIQ==
AMD really it was about tightening up communication's between the C.P.U. and ram by having the Memory controller on die (L2 Cache level of the 2nd core of the am2 athlon x2 processor but it must have been there before that because of the single core processors before dull core became a thing.) so it could effect amd computers back to 2005 ish. does that even sound right?
Or maybe Bush was the mask. Did you consider that?
The article is very vague.
They remap the LAPIC to overlap the SMM memory region which makes data loads of the SMM code fetch values from the LAPIC registers instead of from memory.
Here you can find the slides and the whitepaper of the Black Hat conference talk.
System Management Mode is a feature. It's meant to render separate processors unnecessary for tasks like temperature management and system specific keyboard shortcuts. These functions need to work even if an unsupported or no operating system is running. Consequently SMM behaves almost like a separate processor. That's not a flaw, that's necessarily so.
The problem isn't SMM per se. It's that there is no way to be sure what code is executing in SMM, because there is no way to guarantee which firmware the system is running. Basic firmware should be in ROM (not flash. Read Only Memory.) And it should only do one thing: Load the actual firmware from a removable medium, like a micro SD card. With all writable storage in the system accessible to external inspection, there would at least be a chance to find and reliably remove infections.
Hmm 18 years. That would be Clinton. But then math was never my strong point I am a republican after all.
The article is (as expected) light on details since this is newly disclosed. I've had machines where the BIOS would require confirmation from a connected PS/2 keyboard before certain changes were written. Added a need for physical access in order to write anything to SMM. All the terms have changed but it seems the same principle here. If I can update the firmware, I can keep a machine compromised forever.
That's what I get for scrolling through the headlines too fast--I see "One Night in the Hotel Room of the Future, Researcher Exploits 18-Year-Old"...
Nothing posted to
everybody knows who originally requested it.
Bush? Obama?
Clinton was President from 1993 to 2001. It might have been her husband.
Because it's too complicated. There are too many possible failure modes and many of them can't be seen without a large effort to see them. About the only thing that might eliminate the holes is formal proofs, but that requires not only a complete revamp of how we code but makes coding itself immensely more difficult.
ARM processors are just as broke as everything else. There's just fewer people looking to uncover the holes.
Why is all the stuff broke? Why does all the stuff have holes in it? Why isn't there any stuff that isn't broke? ARM processors from now on. All this stuff is broke.
To a computer there is no difference between "good instructions" and "bad instructions". Any ability to update or improve existing code is also a vector for getting infected by malicious code. You can either allow updates and risk infection, or you can hard code the firmware and disallow updates, but then you're stuck with whatever the firmware is at the outset.
It's not broke. It's just upgradable. Unless you have solid protocols to control who can upgrade and what upgrades are applied, you are at risk of getting a malicious "upgrade". Even with good protocols, an attacker can mimic the appearance of an authorized upgrader and fake the certification of the upgrade to get a malicious payload installed.
Nature is riddled with this kind of phenomenon. Undesirable mate X tries to present itself as desirable mate Y to inject its dna into the replicator.
> so it could effect amd computers back to 2005 ish. does that even sound right?
No, you misspelled affect
Er... you just re-invented SMM.
To act as a mouse visible to DOS, it has to interact with the system interrupt tables. Remember the TSR days of old? You're putting stuff into main memory to have it executed whenever a certain interrupt happens. Which memory? Well, you need at least the USB Host Controller areas, plus something in low memory if you want it available to the BIOS.
Controlling fans, monitoring temperature, issuing safe shutdown commands etc.? Again all happens by talking to the main processor. This is exactly what the SMM was designed for, does, is doing, and needs in order to do that.
Sure, there's a bug that needs to be patched, but what you're suggesting is EXACTLY what the SMM is supposed to be doing already.
In the talk he said it was Sandy Bridge and older. Ivy Bridge/Haswell/Broadwell/Sky Lake are not affected. Ivy Bridge was apparently released in 2012 - https://en.wikipedia.org/wiki/... But 1997-2012 is still a decent window of time. In the talk he also said that it's un-patchable (it's not, the SMI handler can check whether the APIC overlaps the SMM range and change it) He also said SMM controls every instruction from the boot. It doesn't. Maybe on the crappy Acer netbooks that he said he was using for tests. But on enterprise grade systems from Dell, Lenovo, or HP, they use "protected range registers" to stop SMM from being able to write to the code in the firmware. It's a good find, but he's got a lot to learn about firmware still.
... but it must have been there before that because of the single core processors before dull core became a thing.
Why would you even bother to infect dull core processors? It's not like you could do anything interesting with them.
Design flaw my ass. I bet it was there deliberately and everybody knows who originally requested it. I just love the good ol US of A.
From the article linked:
"To exploit the vulnerability and install the rootkit, attackers would need to already have kernel or system privileges on a computer. That means the flaw cant be used by itself to compromise a system, but could make an existing malware infection highly persistent and completely invisible."
This doesn't let an outsider break into the system; it is a flaw that only is useful if you have already compromised the machine.
http://www.geoffreylandis.com
I'm fairly certain that AWS runs on VMs that get shuffled around. That's a whole new layer that probably prevents this kind of exploit unless you target a highly specific and insecure implementation.
This doesn't let an outsider break into the system; it is a flaw that only is useful if you have already compromised the machine.
For a Windows machine, that's not a very high bar, especially in 1997 and all the way until... well, it's a little harder today, but not that much harder...
The problem is persistence. If you get root, you can get firmware and nothing short of throwing the motherboard away would fix it. That's scary.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Really? All the articles I see say that the problem was a faulty lookup table. No one says the lookup table was subjected to a formal proof of correctness.
Simple way to avoid the problem on Macs... don't load BootCamp, and you won't have SMM on the systems you load under bootcamp.
Mac OS X itself doesn't use SMM. Instead, it uses a PE (Platform Expert) module that loaded as part of the OS, which knows in detail about the hardware platform it's going to be running on. Without bootcamp, there's not even ACPI support, since power management is implemented in a much more discrete level of steps than the 4 which ACPI provides.
Because that core would STILL NEED to interface with main memory just the same. It would still need to access the same hardware as the main processor does. It would still need to operate at the level it requires to do those operations such that they are visible to the main processor - and that's what SMM does!
All you've done is replace an in-die kind of SMM with an external chip that needs more complicated routing, all kinds of interactions with main memory (at DMA speed, no less) and peripheral buses, etc. etc. etc. You've not solved the security problem, but you've added a shed-load of costs and external hardware problems that didn't exist before!