Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Security Intel Hardware

Researcher Exploits 18-Year-Old Design Flaw To Compromise X86 Chips 128

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.
This discussion has been archived. No new comments can be posted.

Researcher Exploits 18-Year-Old Design Flaw To Compromise X86 Chips

Comments Filter:
  • Right (Score:1, Interesting)

    by Anonymous Coward

    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.

    • Re:Right (Score:5, Funny)

      by beschra ( 1424727 ) on Friday August 07, 2015 @09:05AM (#50268459)

      everybody knows who originally requested it.

      Bush? Obama?

      • by Anonymous Coward

        Bushama, the man who dares where no man has dared before.

      • Re: (Score:3, Informative)

        by t8z5h3 ( 1241142 )
        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?
        • Re:Right (Score:4, Funny)

          by Anonymous Coward on Friday August 07, 2015 @10:08AM (#50268813)

          > so it could effect amd computers back to 2005 ish. does that even sound right?
          No, you misspelled affect

        • ... 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.

      • Re: (Score:3, Funny)

        by Anonymous Coward

        Hmm 18 years. That would be Clinton. But then math was never my strong point I am a republican after all.

      • Re: (Score:3, Funny)

        by Anonymous Coward

        everybody knows who originally requested it.

        Bush? Obama?

        Clinton was President from 1993 to 2001. It might have been her husband.

      • by doccus ( 2020662 )

        everybody knows who originally requested it.

        Bush? Obama?

        Hardly.. It would be somebody with real power in the administration...

      • by doccus ( 2020662 )

        everybody knows who originally requested it.

        Bush? Obama?

        Actually, I *think* he was referring to Reagan...

    • by Geoffrey.landis ( 926948 ) on Friday August 07, 2015 @10:51AM (#50269115) Homepage

      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.

      • by steelfood ( 895457 ) on Friday August 07, 2015 @12:02PM (#50269677)

        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.

        • by Burz ( 138833 )

          Like Windows, Linux is a complex rambling Swiss cheese and privilege escalations are pretty common.

          Lean security protocols need to come first, which is why Qubes OS [qubes-os.org] is based on a Type 1 hypervisor (Xen). An attacker can try to use an exploit (like in OP) all they want in an untrusted domain, but they aren't going to get access to the hardware (or the other VMs, unless the user has done something to specifically expose those VMs to the attack).

          • Lean security protocols need to come first, which is why Qubes OS [qubes-os.org] is based on a Type 1 hypervisor (Xen). An attacker can try to use an exploit (like in OP) all they want in an untrusted domain, but they aren't going to get access to the hardware (or the other VMs, unless the user has done something to specifically expose those VMs to the attack).

            This assumes there is a security layer that is free of exploitable bugs and that there is no way to influence the lower security layers in a way that can exploit bugs in those layers.

            That's a very big assumption unless the security layer you are talking about AND all lower security layers are all so simple that the code can be proven bug-free by inspection.

    • SMM, a.k.a. Ring -1, has been present for a long time, and does what the name says, it allows for things like emergency power-shutdown handling ("you have 50ms to sync system state before we can't guarantee power quality any more"). Yes, it's Ring -1, and you have to be careful how you misuse it, but the fact that it works as documented is hardly a new security flaw, this was documented as a security concern at least 15 years ago.
      • Just read the WP, it points out an ancient APIC compatibility hack that allows you to escalate from Ring 0 to Ring -1 (SMM). So in other words if you're already running at Ring 0 to start with, you can get into SMM. Sounds like an example of what Raymond Chen [msdn.com] calls an "other side of the airtight hatchway" attack, you already have to have complete system privs in order to carry out a privileged attack.

  • HA! (Score:5, Funny)

    by ArchieBunker ( 132337 ) on Friday August 07, 2015 @09:04AM (#50268445)

    I use Alpha 21264 you insensitive clod!

    • Re:HA! (Score:5, Informative)

      by Anonymous Coward on Friday August 07, 2015 @09:16AM (#50268515)

      Doesn't matter. Any processor from Intel after 2011 no longer has the flaw...

      Old bug; Intel knew about it in 2010; they fixed in 2011, now its on the frontpage of Slashdot in 2015..

    • HA HA ! (Score:2, Funny)

      by Anonymous Coward

      SSB1c2UgYSA2NCBiYXNlIHByb2Nlc3NvciwgeW91IGluc2Vuc2l0aXZlIGNsb2QgIQ==

  • by Anonymous Coward on Friday August 07, 2015 @09:09AM (#50268485)

    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.

  • by Anonymous Coward

    My understanding is that SMM is used, before all the TCG stuff about Secure Boot, etc., basically to control fans and shut down the system if the temperature is too high. And also to make USB keyboards appear as PS/2 hardware to DOS.

    Are those functions really so expensive that they couldn't be offloaded to hardware on a chipset instead of trying to have the main CPU in your system act like it's own hardware watchdog?

    • by ledow ( 319597 )

      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 processo

      • But a simple core (think of an embedded Arm core) could do all this, using in chip Ram, and hardly bothering the main Cpu. Why does Smm code even need the main Cpu to run?
        • by 0123456 ( 636235 )

          But a simple core (think of an embedded Arm core) could do all this, using in chip Ram, and hardly bothering the main Cpu. Why does Smm code even need the main Cpu to run?

          'Cause it saves $0.25 per system shipped?

        • by ledow ( 319597 )

          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, et

    • My understanding is that SMM is used, before all the TCG stuff about Secure Boot, etc., basically to control fans and shut down the system if the temperature is too high. And also to make USB keyboards appear as PS/2 hardware to DOS.

      Intel uses the chip of the keyboard to fix an issue with memory managment, don't want to mess with the keyboards.

      • My understanding is that SMM is used, before all the TCG stuff about Secure Boot, etc., basically to control fans and shut down the system if the temperature is too high. And also to make USB keyboards appear as PS/2 hardware to DOS.

        Intel uses the chip of the keyboard to fix an issue with memory managment, don't want to mess with the keyboards.

        Just read what was posted and the reply, it's more so important in a DOS environment as it's a gap in the first meg of accessible memory that's the issue.

  • Details (Score:5, Informative)

    by Anonymous Coward on Friday August 07, 2015 @09:23AM (#50268553)

    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 [blackhat.com] you can find the slides and the whitepaper of the Black Hat conference talk.

  • It's a feature (Score:5, Interesting)

    by Anonymous Coward on Friday August 07, 2015 @09:28AM (#50268581)

    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.

    • by tlhIngan ( 30335 )

      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.

      Well, the purpose of SMM mode is way back in ancient history, when PCs used DOS.

      Back then "Power Management" was actually done by the system firmware - it to

      • It's all part of the bizarre non-design of the PC. The bootloader was always given far too much responsibility, compare to real computers that actual designers and you never see a boot system so bloated as the PC. There should never be a "need to work even if an unsupported or no operating system is running" feature.

        It reemphasizes the overreliance on a monoculture that we have.

  • A reason to back to Sparc
  • "To exploit the vulnerability and install the rootkit, attackers would need to already have kernel or system privileges on a computer."

    You know, even without this particular SMM attack vendor, a hacker who already has system level privileges on your PC renders your PC totally insecure, besides he also can ... rewrite BIOS or various firmware components of your PC to allow his code to survive an HDD wipe.

  • by Ed Tice ( 3732157 ) on Friday August 07, 2015 @09:35AM (#50268615)
    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.
  • 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.
    • Re:Stuff (Score:5, Insightful)

      by Chris Mattern ( 191822 ) on Friday August 07, 2015 @09:58AM (#50268751)

      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?

      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 from now on. All this stuff is broke.

      ARM processors are just as broke as everything else. There's just fewer people looking to uncover the holes.

      • ARM processors from now on. All this stuff is broke.

        ARM processors are just as broke as everything else. There's just fewer people looking to uncover the holes.

        Fewer yes, but some are looking [blogspot.fr].
        The bug in SnapDragon TrustZone implementation described in the previous link has been fixed BTW. Now what percentage of SnapDragon based smartphones in the field include the fix is anyone guess.

      • Formal proofs were used to justify the change in the floating point unit that led to the Pentium FDIV bug.

        • 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.

          • Robert P. Colwell _The Pentium Chronicles_, p159-160:
            "For most of the Pentium design project, the floating point divider was exactly the same as the 486's. But late in the Pentium project, upper management requested that the entire project search for ways to make the die smaller. ...the engineers working on the floating point divider did... an idea to save some space in a lookup table and one of them performed an analytical proof... That proof turned out to be flawed, but the insidious side effect of having

      • by lgw ( 121541 )

        About the only thing that might eliminate the holes is formal proofs

        Formal proofs (of correctness, I assume) can't eliminate bugs or security flaws, though they are a cost-inefficient way to reduce bugs. A formal proof is only solving the same problem in two different languages (one the language of the formal proof), and diffing the result. It's not better or worse than any other static analysis tool, per se. It certainly won't help at all when the component is insecure by design, which is so often the problem. (Why does a document format need a way to execute arbitrary

        • by Uecker ( 1842596 )

          You haven't understood the point.The formal proof abstracts away implementation details which are irrelevant for correctness. For this reason, It is much simper to understand than the actual implementation. And it does not solve the same problem.

          • by lgw ( 121541 )

            Yeah, it's those pesky mplementation details where most security flaws are found, and most corner-case bugs that escape testing. Design reviews happen already at most companies.

            • by Uecker ( 1842596 )

              The proof may show that the implementation performs a certain function according to a certain specification. Knowing this rules out a lot of bugs in the implementation. E.g. a sorting function can be shown to return a correctly sorted list. Once you have a formal proof of this property you do not need to worry about any pesky implementation details of this sorting function anymore. The actual implementation could really complicated because it is highly optimized and has many special cases which may make it

              • by lgw ( 121541 )

                If it can spot a buffer overrun during the sort (even though the correct result is achieved), then at least some value is added - but there are several static analysis tools.

                Otherwise, you're just writing the same code in 2 different languages - one high level and one low level, and proving they are functionally equivalent. (In which case, why not just switch to the high level language for production). The whole idea just seems like a high-level language someone was too lazy to write a compiler for, so al

      • by Burz ( 138833 )

        Qubes OS uses a Type 1 hypervisor to simplify and harden system security against such vulnerabilities. The privileged parts of the system are kept relatively small and aren't used for any user applications. All apps and even some drivers (like NICs) are assigned to VMs, which the user can give different trust/risk designations and color codes.

        Because isolating hardware is considered part of the solution, Qubes systems need IOMMU hardware to operate securely. But this high degree of isolation is what elimina

    • 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 ri

      • by PPH ( 736903 )

        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 you had to make an analogy that, for Slashdotters, is a purely theoretical event.

    • "ARM processors from now on" BWAHAHAHAHAHAHAHA. Good one. ARM is a joke compared to Intel. No company spends more on chip research and design than intel. Further ARM is supported by a ton of REALLY REALLY insecure operating systems. iOS and Android are both far more leaky by default than this exploit.
  • by flopsquad ( 3518045 ) on Friday August 07, 2015 @09:36AM (#50268627)
    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"...
    • by Anonymous Coward

      Academic freedom to experiment is a time-honored tradition in the university world.

    • by zlives ( 2009072 )

      its not an exploit, fut a designed feature... o wait

  • Three questions: 1) Is it possible to fix this with a downloadable firmware patch? 2) Will such a patch be forthcoming from Intel and/or AMD? 3) Until then, is there any way to protect my x86 machines, other than the obvious "avoid suspicious files" approach?
  • Not every chip (Score:5, Interesting)

    by BIOS4breakfast ( 3007409 ) on Friday August 07, 2015 @10:27AM (#50268947)
    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/... [wikipedia.org] 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.
    • by Khyber ( 864651 )

      "the SMI handler can check whether the APIC overlaps the SMM range and change it"

      Not if the SMB drivers aren't installed for the OS, no.

      Which does not bode well for those who deliberately put an older OS on newer hardware, given SMB drivers for a lot of newer stuff doesn't even have an XP version.

      Not like it affects performance, just affects security.

      • by The Finn ( 1547 )
        what are these SMB drivers? how do they affect existing SMM code which is provided in BIOS?
  • So, if I understand correctly, if you get a rootkit in your SMM you have to throw out your computer?

  • All this recent news makes me want to fire-up my PowerPC-based G5 Tower again. Then I can simply worry about unpatched SSL vulnerabilities in OS X 10.5 Leopard.

    But at least no one will be writing exploits that can easily run on my computer.
  • Oh, the fools! If only they'd built it with two layers of bootkit protection! When will they learn?!?

  • Are there computers out there that are locked into Windows due to UEFI that could be freed through this hack?

  • SMM was a "nice" idea in more timid times. It let unscrupulous vendors emulate missing hardware features with (usually poorly written) firmware. I had quite enough head-banging when trying to implement realtime audio I/O on systems that turned out to emulate sound blaster and other industry standards.

  • by tlambert ( 566799 ) on Friday August 07, 2015 @02:14PM (#50270659)

    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.

    • by The Finn ( 1547 )
      OS X may not generate SMIs, but are you also asserting that SMM handlers are never run on Apple hardware running OS X?
  • Which design flaw in the 18-year-old did they exploit? The one where they're impossible to get out of bed? How does this help them compromise x86 chips?
  • I've been saying for years that computers should have a hardware reset button or (for chips) a pin that restores them to a known factory state. If the button is pressed or the pin is set during initial power-on from a cold boot, the factory reset occurs. Any "infected" code will never get a chance to take control before the reset is finished.

    Obviously now I'm going to have to extend that recommendation to any system or subsystem - including the CPU - which can be reprogrammed or save state in a way that su

  • 18 years ago was 1997?

    Fuck, I feel old now.

And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. -- David Jones

Working...