Forgot your password?
typodupeerror
Security Bug Intel IT

Intel CPU Privilege Escalation Exploit 242

Posted by timothy
from the they-never-offer-the-purple-pill dept.
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."
This discussion has been archived. No new comments can be posted.

Intel CPU Privilege Escalation Exploit

Comments Filter:
  • by downix (84795) on Thursday March 19, 2009 @12:22PM (#27258243) Homepage

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

  • Ouch (Score:5, Funny)

    by Big Hairy Ian (1155547) on Thursday March 19, 2009 @12:22PM (#27258245)
    This could make the apple bricking patch look like a kindergarten party
  • CD Boot (Score:5, Funny)

    by Baldrson (78598) * on Thursday March 19, 2009 @12:23PM (#27258277) Homepage Journal
    TFA: The malware code takes over a PC with little or no recourse to remove it.

    Haven't these guys ever booted from a CD?

    • Re:CD Boot (Score:5, Informative)

      by adonoman (624929) on Thursday March 19, 2009 @12:28PM (#27258353)

      You're assuming that the rootkit isn't loaded before the bios tries booting off the CD.

      • Ummm, about that (Score:5, Informative)

        by Sycraft-fu (314770) on Thursday March 19, 2009 @01:46PM (#27259595)

        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.

        • Re:Ummm, about that (Score:5, Informative)

          by FrankSchwab (675585) on Thursday March 19, 2009 @02:02PM (#27259841) Journal

          As a firmware engineer who patches ROM code in embedded systems daily, I'll give a bit of insight.

          The BIOS as a whole is specific to the board that it is running on. However, that doesn't mean that additions can't be made to the BIOS in a generic fashion. Imagine you searched the BIOS Flash for unused space (all of them will have it), and relocated code into that space (relocating a DOS .exe file is trivial). Writing a FLASH is not a difficult operation, though different motherboard manufacturers probably write protect it in different ways. Your code is now in the BIOS ROM.

          You then modify the code in the flash that handles e.g. INT 14 (Serial communications, pretty much a dead function on modern PCs). This is nothing more than overwriting the first couple of bytes of the address pointed to by the INT14 vector in the flash - you store them in your patch area, and JMP to your routine. Once again, it's a Flash write.

          Now, certainly, at some point in time (BIOS, probably) someone will attempt to enumerate/initialize the serial ports. Your code is now running - the world is your oyster. With this exploit, you can now probably hoist the BIOS code into a VM PRIOR to loading Windows. And you're still there.

          There are different families of BIOS that you would have to support - Phoenix, AMI (do they still exist?), HP, Intel, etc. There are different schemes for protecting Flash, etc. These differences are probably smaller than they sound.

          • Re: (Score:3, Insightful)

            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.

        • Re:Ummm, about that (Score:4, Interesting)

          by wiredlogic (135348) on Thursday March 19, 2009 @02:27PM (#27260251)

          In PC land most modern BIOSes are designed to be modular and the tools to manpulate them are readily available for free. They usually have enough left over space in flash for a malicious extension to be added. A malicious extension doesn't have to be a complete exploit. It just has to provide the hooks for a compromised OS to call into and execute a small bit of code that would otherwise be impossible to execute.

          I wouldn't be surprised if Macs had similar BIOS vulnerabilities. They're potentially even more vulnerable since, because of the Apple monoculture, all Intel Macs likely have similar BIOS code and a single exploit could easily attack the entire population. This is a growing threat with Apple's increasing market share. The days when nobody bothered to write viruses for Macs are long gone.

      • by jd (1658)

        If someone has finally produced a rootkit that sits in the BIOS (and why not?), then yes, this would indeed be possible. All you need to do is upload into the Flash memory a stage loader where the first stage is the malware and the second stage is the "proper" BIOS.

    • Re:CD Boot (Score:5, Funny)

      by CannonballHead (842625) on Thursday March 19, 2009 @12:31PM (#27258403)
      No, really. It takes it over! You can't even come within 5 feet of the case, the malware pushes you back!
    • Re:CD Boot (Score:5, Informative)

      by I.M.O.G. (811163) <spamisyummy@gmail.com> on Thursday March 19, 2009 @12:37PM (#27258481) Homepage

      Haven't these guys ever booted from a CD?

      While you succeed at being snarky, you fail at being correct. Assuming the article is credible and accurate, it explains why booting from a CD won't save you:

      By design, the operating system cannot override or disable System Management Interupt (SMI) calls. In practice, the only way for you to know what is running in SMM space is to physically disassemble the firmware of your computer. So, given that an SMI takes precedence over any OS call, the OS cannot control or read SMM, and the only way to read SMM is to disassemble the system makes an SMM rootkit incredibly stealthy!

      Now with that said judging by the authors language at networkworld he likely doesn't fully understand whats going on - he uses words like "powned" and "the PC is living in the matrix", whatever the fuck that means! I'll reserve my judgement on this until I read more from someone that owns a clue.

      • Ring of Fire (Score:5, Interesting)

        by goombah99 (560566) on Thursday March 19, 2009 @12:43PM (#27258585)

        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.

        • Re: (Score:3, Funny)

          by geckipede (1261408)
          if you're on vulnerable hardware, once some malware that uses this trick has gained root, nothing short of physically setting fire to the motherboard will clean it. Reinstalling from scratch can't help you.
      • Re:CD Boot (Score:5, Interesting)

        by vadim_t (324782) on Thursday March 19, 2009 @12:48PM (#27258681) Homepage

        And you fail at understanding.

        The exploit talks about modifying SMRAM. It's done with root level access on the computer. And in my understanding, the effect is not permanent, since you're changing RAM. Reboot, and it'll be gone.

        Now, once it's there, the OS can't have an antivirus scan that memory area. But that's it. If this thing persists across reboots, something has to put it back into the SMRAM, and you could find that something by booting a scanner from a CD, or reformatting the computer.

        I don't see this as a particularly scary thing. Yes, it's nasty. But a virus could also disable antiviruses and patch the kernel to hide its presence for the same effect.

        This is the same scaremongering as with the virtualization virus. Yes, it's a new way a virus can use to hide. But it's absolutely nothing new. Under DOS, viruses would trap DOS calls, and remove themselves from opened files, so that an antivirus trying to scan the file would see an uninfected one. Boot from a floppy, and none of that trickery will be active.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Actually, this IS new in that it's using a low-level exploit that previously wasn't known.

          Also, the virus could use a commonly available BIOS utility to flash malware into the cmos.
          Much, much more insidious than a traditional file-based root. Then it's there on every boot.

          How exactly would you even KNOW you were infected by a BIOS-based kit? That's the question.

          I take particular (if momentary) satisfaction in owning ONLY AMD based platforms.

          I'm sure there will be some exploit or another for them someday,

          • Re:CD Boot (Score:5, Informative)

            by dgatwood (11270) on Thursday March 19, 2009 @01:55PM (#27259735) Journal

            Also, the virus could use a commonly available BIOS utility to flash malware into the cmos. Much, much more insidious than a traditional file-based root. Then it's there on every boot.

            AFAIK, it can do that from Ring 0, too. About all SM mode does is allow you to temporarily inject yourself under the kernel in an undetectable way for a single boot; if you don't delete yourself from disk, you can still be detected by virus scanners and deleted, at which point your code would go away on the next boot... unless you start sniffing disk block writes and try to hide your files from the virus scanner. Either way, AFAICT, a cold boot from a recovery disk can clean up anything you could do in SM mode that you couldn't do from ring 0.

            These attacks have been around for a while. Here's an article [securityfocus.com] about an attack that obtains SMM access (from user space code in that case) from way back in 2006. The only thing that's new is that this is a new/different way to get into SM mode.

            • Re: (Score:3, Interesting)

              by The_Wilschon (782534)
              There must be something I'm not understanding here. GP says "Bug can put itself into BIOS, so it's there every time you boot (and before your rescue disk would even get read)". You say "Yeah, but that's nothing new. What's new is that once this thing has run itself, it can slip under the OS and make itself undetectable by the OS".

              Looks to me as though this would in fact mean that a recovery disk would not help you. A recovery disk would merely boot an OS, just like booting from your hard disk boots a
        • by I.M.O.G. (811163)

          If you go thru the trouble of performing an SMM exploit you are already tailoring your attack to specific hardware. At that point, it would be silly not to also write your code to firmware so that its persistent.

          So while theoretically you could find the bug by using a bootable CD and a scanning utility, that wouldn't be a likely situation in practice.

        • by Sycraft-fu (314770) on Thursday March 19, 2009 @01:57PM (#27259765)

          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.

          • Re: (Score:3, Insightful)

            by ultranova (717540)

            You want to fool me, you have to virtualize my GTX 280.

            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.

            • Re: (Score:3, Insightful)

              by Sycraft-fu (314770)

              You let hardware use DMA, all your hopes of invisibility are gone. DMA means just that: Direct Memory Access.

              • Re: (Score:3, Informative)

                by marcansoft (727665)

                That was back when the term was coined. These days we have IOMMUs [wikipedia.org].

                • Re: (Score:3, Insightful)

                  by Sycraft-fu (314770)

                  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.

      • Re:CD Boot (Score:5, Insightful)

        by antifoidulus (807088) on Thursday March 19, 2009 @01:13PM (#27259107) Homepage Journal
        While you succeed at being snarky, you fail at being correct.

        Dude, I think you came up with a new motto for slashdot!
      • Re: (Score:2, Funny)

        by l3ert (231568)

        I'll reserve my judgement on this until I read more from someone that owns a clue.

        I assume you meant "powns a clue".

        • Fixed that for you (Score:3, Interesting)

          by Tetsujin (103070)

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

      • Re: (Score:2, Interesting)

        by kheldan (1460303)
        There are two things that aren't clear from the article:
        1. Does this include ALL x86 chips (i.e., AMD chips) or just pure Intel chips?
        2. If the SMM firmware is in the BIOS Flash ROM, does/can malware actually overwrite your BIOS, thus making itself more-or-less permanent (save for physically removing/replacing the BIOS ROM chip)?

        BTW if #2 is true, then it really is a huge threat -- and we'd all be better off going back to EPROMs and ditching the ISP flash ROMs, or at least having some sort of hardware read-only

      • by Baldrson (78598) *
        Its interesting that the hardware would be designed so that the firmware has no real control over itself. Where do they get these guys?
  • by Anonymous Coward on Thursday March 19, 2009 @12:25PM (#27258301)
    ... Joanna Rutkowska is hot [zdnet.com]!
  • by Anonymous Coward on Thursday March 19, 2009 @12:25PM (#27258305)

    Run all code on a 286 or below.

  • Wait, what? (Score:4, Insightful)

    by girlintraining (1395911) on Thursday March 19, 2009 @12:28PM (#27258357)

    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: (Score:3, Insightful)

      by Darth Liberus (874275)
      Yeah, this reminds me of the "Windows XP's Raw Sockets will destroy the Internet!" hype.
    • Re:Wait, what? (Score:4, Informative)

      by Molochi (555357) on Thursday March 19, 2009 @12:43PM (#27258589)

      The exploit allows access from Ring to SMM? Summary is confusing but I think we're talking about an exploit that can write to bios even with flashing disabled at the bios level.

      • by Molochi (555357)

        Yeah, it looks like access to SSM gives elevated privilages over kernal (ring 0).

        http://www.rcollins.org/ddj/Jan97/Jan97.html [rcollins.org]

      • by anss123 (985305)

        The exploit allows access from Ring to SMM? Summary is confusing but I think we're talking about an exploit that can write to bios even with flashing disabled at the bios level.

        Not really. SMM is a mode that's normally the BIOS's playground. There may be SMM code that prevents BIOS flashing which this exploit could be used to circumvent, but this exploit does not flash the BIOS.

    • by blueg3 (192743)

      Overriding SMM functions (which appears to be what they're doing here) is not actually a function that's intended to be accessible from ring zero.

      So no, you get your code running in ring zero and then you can do something that you shouldn't be able to do with ring zero access.

  • by vadim_t (324782) on Thursday March 19, 2009 @12:30PM (#27258383) Homepage

    From the PDF:

    Below we describe how to exploit cache poisoning to get access to the SMRAM memory. We assume that the attacker has access to certain platform MSR registers. In practice this is equivalent to the attacker having administrator privileges on the target system, and on some systems, like e.g. Windows, also the ability to load and execute arbitrary kernel code.

    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.

    • Re: (Score:3, Insightful)

      by anss123 (985305)

      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.

    • by sjames (1099) on Thursday March 19, 2009 @12:50PM (#27258719) Homepage

      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.

      • by vadim_t (324782)

        Well, and why would the firmware allow a rewrite?

        My motherboard seems to be on the right track -- it's possible to flash the BIOS from the BIOS. So there's no need to allow write access at any other moment.

        Motherboards seem to come configured to forbid flashing by default, too.

        • by sjames (1099) on Thursday March 19, 2009 @02:03PM (#27259859) Homepage

          Well, and why would the firmware allow a rewrite?

          My motherboard seems to be on the right track -- it's possible to flash the BIOS from the BIOS. So there's no need to allow write access at any other moment.

          Motherboards seem to come configured to forbid flashing by default, too.

          In many cases, the BIOS manages that trick because trying to set the write enable bit in the chipset triggers an SMI. If the exploit has replaced the code that the SMI calls...

          In other cases, it's just that an undocumented GPIO line is anded with the write line on the flash. The flasher program knows which line to set or the SMI routine sets the line in response to a write to a fake register location. Often, that trick can be brute forced using the CFI ID command to the flash to determine when you've found it.

          The one and only real way to protect the flash is to have a jumper that actually disconnects the write enable line in hardware. Practically no motherboards seem to take that approach.

          Keep in mind that some network cards and disk interface cards (especially SCSI adapters) also have a flash in them. They have a boot signature so that the BIOS executes their POST routines before even considering loading a bootloader. Most of those can be re-flashed while running as well if you frob their config registers the right way.

      • Re: (Score:3, Insightful)

        by anss123 (985305)

        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.

        • by sjames (1099)

          The first part is, but not the second.

          • by anss123 (985305)

            The first part is, but not the second.

            Wrong. Even without this exploit a BIOS virus can make use of VT-x (or borrow code from Virtualbox for CPUs without VT-x). SMM may be harder to detect though.

  • 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?
    • Re: (Score:3, Informative)

      by wolf12886 (1206182)

      Of course I didn't read TFA, but it doesn't sound like this exploit has shown up in any malware yet. At this point the potential for attack has just been demonstrated.

      A cording to some other commenters, the exploit code must run in ring 0, so you already have to be rooted for it to work. In a nutshell, this vulnerability can't be used to infect your OS in the first place, but it can potentially make detection and removal near impossible.

  • Hyperbole? (Score:3, Insightful)

    by anss123 (985305) on Thursday March 19, 2009 @12:39PM (#27258521)
    Mod this guy up.

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

    • Re: (Score:2, Informative)

      by anss123 (985305)
      I'm an idiot. That was supposed to be a reply....
    • by blueg3 (192743)

      The fact that you're running in a hypervisor is only detectable by a timing attack.

      They get into SMM from kernel mode, but they modify the SMM functions, which is not something you generally can do from kernel mode.

  • Guess we need to start booting from CD every time we scan for viruses?
  • by FurtiveGlancer (1274746) <AdHocTechGuy@NOSpAm.aol.com> on Thursday March 19, 2009 @12:44PM (#27258605) Journal
    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.
    • Re: (Score:3, Informative)

      by anss123 (985305)

      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.

      Going from usermode to supervisor mode is a far more serious exploit than going from supervisor to "hypervisor" mode.

  • Wonder if this will spawn a run on Mac G5's.
  • Inexcusable (Score:5, Interesting)

    by sjames (1099) on Thursday March 19, 2009 @12:48PM (#27258693) Homepage

    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.

    • by anss123 (985305)
      It's not worse than drivers that polls interrupts and spinlocks. Don't like it, don't buy it.
    • Re:Inexcusable (Score:5, Interesting)

      by Animats (122034) on Thursday March 19, 2009 @01:54PM (#27259715) Homepage

      Often enough, the "big secret" is that the hardware is crippled and the CPU is doing the real work.

      Yes. And board manufacturers get really angry when someone detects that.

      In the QNX community, where "real time" really means something, there's a common test of the operating system's real-time response. The tester wires up a square wave generator to an input that will cause an interrupt, programs the computer to wait for the interrupt and start a real-time user process, and has the user process turn on an output. You run some program in the background to keep the CPU busy. On a serious real-time OS, this shouldn't hurt real time response, and on QNX, it doesn't. There are no long interrupt lockouts in the QNX microkernel. Drivers are interruptable user processes.

      Input and output lines are then wired up to a storage oscilloscope, to display the interrupt response. On most machines, the scope shows a nice, boring, consistent interrupt response time of a few microseconds. But on some CPU boards, there's a spike way out there from the expected delay period. This shows clearly the occasional huge delay (by real time standards) of hundreds of microseconds, maybe even more than a millisecond. That's because something is going on in System Management Mode. QNX programmers have found USB serial emulation, flash disk IDE emulation, and other crap running at SMM level.

      When a vendor gets caught doing this, word gets around in the real-time community that their board is unacceptable for real-time use. Vendors selling embedded system boards have been caught this way.

      Hard real time is a world in which stuff is expected to actually work every time.

      • Re: (Score:3, Funny)

        by anss123 (985305)

        Hard real time is a world in which stuff is expected to actually work every time.

        So instead of "real time kernel" it should be called "every time kernel" :-)

  • by YesIAmAScript (886271) on Thursday March 19, 2009 @12:49PM (#27258699)

    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.

    • by Molochi (555357)

      I think it's true that most systems would allow a flash to bios from ring 0 anyways, as every system I've recently built came from the factory with it enabled by default as a bios setting. I don't think most people (even geeks) look.

      There are tons of bios/firmware/driver installers on TPB that promise improved performance and enhanced features and any of them could be doing what this exploit is capable of. Each would be run, voluntarily, on the hardware it exploits.

    • by jvkjvk (102057) on Thursday March 19, 2009 @02:37PM (#27260381)

      So, never run any VMs, then? Or only allow "trusted users" to run VMs?

      Because if I'm a malicious user, I can gain root in my VM hosted on your box through a local privilege escalation attack. Then, I not only gain access to your hypervisor, but to every other VM instance on that machine.

      Sweet.

      Good thing that no one would ever use a VM, isn't it?

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

  • Yet another good reason to use an AMD cpu!

    • by geekoid (135745)

      You might want to look into "Blue Pill" before going on about how they will save us from this.

  • Wow (Score:5, Insightful)

    by quo_vadis (889902) on Thursday March 19, 2009 @01:22PM (#27259247) Journal
    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.
    • Re:Wow (Score:4, Interesting)

      by 1s44c (552956) on Thursday March 19, 2009 @03:18PM (#27260963)

      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.

      Are you sure that's what it means? It looks like it needs ring 0 not kernel. Kernel mode would be less than ring 0 where a hypervisor was used. Or does KVM run all kernels at ring 0?

  • by sysstemlord (1262162) on Thursday March 19, 2009 @01:50PM (#27259655)
    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?
  • by nicuramar (869169) on Thursday March 19, 2009 @02:28PM (#27260269)
    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.
  • by JerryLove (1158461) on Thursday March 19, 2009 @02:43PM (#27260473)

    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?

Moneyliness is next to Godliness. -- Andries van Dam

Working...