Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security Intel Software Hardware Linux

Intel Cache Poisoning Is Dangerously Easy On Linux 393

Julie188 writes "A researcher recently released proof-of-concept code for an exploit that allows a hacker to overrun an Intel CPU cache and plant a rootkit. A second, independent researcher has examined the exploit and noted that it is so simple and so stealthy that it is likely out in the wild now, unbeknownst to its victims. The attack works best on a Linux system with an Intel DQ35 motherboard with 2GB of memory. It turns out that Linux allows the root user to access MTR registers incredibly easily. With Windows this exploit can be used, but requires much more work and skill and so while the Linux exploit code is readily available now, no Windows exploit code has, so far, been released or seen. This attack is hardware specific, but unfortunately, it is specific to Intel's popular DQ35 motherboards."
This discussion has been archived. No new comments can be posted.

Intel Cache Poisoning Is Dangerously Easy On Linux

Comments Filter:
  • Linux (Score:5, Funny)

    by the_one(2) ( 1117139 ) on Wednesday April 22, 2009 @03:32PM (#27677915)

    They make it sound like a bad thing that it's easier to use your hardware on Linux =)

    • Re:Linux (Score:5, Insightful)

      by Anonymous Coward on Wednesday April 22, 2009 @03:39PM (#27677981)

      This attack still requires root access, so all this says is that if you have an Intel DQ35 motherboard, are running linux and you've already been rooted, then someone could probably install a really sneaky rootkit.

      Not a nonissue, but also not the end of the world.

      • Re:Linux (Score:5, Insightful)

        by dtolman ( 688781 ) <dtolman@yahoo.com> on Wednesday April 22, 2009 @04:54PM (#27679025) Homepage
        Why is this insightful? This is a problem that can be exploited through a hosted VM! If you've rooted one VM on a system, now you can jump to the host server and all the other hosted VM's. And oh yeah - theres no way to detect it at all!!!
        • Re:Linux (Score:5, Interesting)

          by AVee ( 557523 ) <slashdotNO@SPAMavee.org> on Wednesday April 22, 2009 @05:18PM (#27679385) Homepage
          Indeed, the potential this has to cross-infect VM is the biggest issue here. It's more then just another way to hide a rootkit, it totally breaks all that added security you where supposed to get through virtualization. Oh, and it makes running a honeypot on a DQ35 system an extremly bad^H^H^Hinteresting idea ;)
          • Who ever claimed that VM gives or is supposed to give additional security? As far as I know and understand, the purpose of VM is to provide easier management of disparate systems and better overall utilization of expensive hardware.
            • Re: (Score:3, Insightful)

              by dbIII ( 701233 )

              Who ever claimed that VM gives or is supposed to give additional security?

              The same people that say the same thing about NAT - in other words people that mistake obscurity for security.

      • Re: (Score:3, Interesting)

        by Bert64 ( 520050 )

        Well, if you're running any other os and someone has root equivalent access, they could easily upload a minimal linux distro, configure your bootloader to silently start it at the next boot and then install the rootkit, followed by rebooting into whatever normal os you have...
        In short, if someone has root level access to your machine, you are screwed whatever os you run.

    • Yep, all it said is that it is easer to program things in Linux.

  • Since you need root on the box first, how is this anything new?

    If you have root you can plant a root kit in any number of ways, heck just replace the kernel if you want.

    • by Lord Ender ( 156273 ) on Wednesday April 22, 2009 @03:44PM (#27678037) Homepage

      It's a whole new class of vulnerabilities. In addition to remote code execution and privilege escalation vulnerabilities, we now have privilege equalization vulnerabilities. Scary stuff.

    • by victim ( 30647 ) on Wednesday April 22, 2009 @03:44PM (#27678039)

      The significance of SMM buried rootkits is that you can remove and shred the hard drive of your compromised machine, replace it with a new one, do a fresh install, and still be compromised.

    • by blueg3 ( 192743 ) on Wednesday April 22, 2009 @03:54PM (#27678175)

      If you have root you can plant a root kit in any number of ways, heck just replace the kernel if you want.

      Replacing the kernel tends to trigger systems designed to catch intrusions, as it's painfully obvious. Running your malware persistently without being detected by the system is the point of a rootkit.

    • by LoRdTAW ( 99712 ) on Wednesday April 22, 2009 @03:56PM (#27678217)

      I read the PDF of the exploit and from what it states the code injected into the SMRAM is effectively being executed in a region where no OS or hyper visor can touch. So from what I understand a system running virtualization software only needs one of the guest operating systems to become compromised in order for the attacker to gain control of the entire system. From there the other guest/host OS's or possibly the hyper visor can be attacked. So yes for a single OS system it is redundant to attack the SMRAM because if you already have root then whats the point?

      But even with the ability to attack other software on a virtualized DQ35 system, their numbers I am sure are close to none. The DQ35 board is a uATX desktop board. If it were specific to Intel server boards or Intel based server boards then I would worry.

      I wonder if this exploit is truly only limited to the DQ35. How many different Intel systems have they tested this on. And what about AMD systems, are they vulnerable to similar attacks?

      • Yes, but if your virtualization system doesn't virtualize SMM (and the BIOS by extension both ways), you already have problems. If it allows direct BIOS calls at all, you have an escape.
      • Re: (Score:3, Interesting)

        by dave562 ( 969951 )
        So what you're saying is that if I lease space from a hosting company that has my VM on a system with a DQ35 board, I can jump from my VM into any other VMs that happen to be on the same box?
        • Re: (Score:3, Informative)

          by LoRdTAW ( 99712 )

          Not that you can jump into another VM but possibly inject code into them which in turn allows you to gain access to them. Or gives you access to the hypervisor which could lead to similar results. I am no security expert but from what I heave read in the paper it does appear to be possible. I highly doubt the DQ35 is going to be found in a data center serving VM's though. Systems serving VM's are most likely dual/quad CPU systems with multicore CPU's.

  • by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Wednesday April 22, 2009 @03:33PM (#27677925)

    I would recommend that you don't give out root access to script kiddies on systems where you don't want them to install root kits.

    • Re: (Score:2, Interesting)

      by piojo ( 995934 )

      I would recommend that you don't give out root access to script kiddies on systems where you don't want them to install root kits.

      Is it so hard to write a daemon that essentially does "do sudo install_rootkit; sleep 5; while [ $? -ne 0 ]". The syntax may be wrong, but it just tries running sudo until it works. In most systems, sudo permissions are system-wide--once a user uses sudo to install some software, the daemon will succeed in its attempt to get root. Is there a reason this won't work on most linux desktop systems? (Obviously it won't work if the affected account doesn't have sudo.)

  • you got root (Score:2, Insightful)

    by Dionysus ( 12737 )

    If you got root, aren't there easier way to install a rootkit? Just load a rootkit module into the kernel.

  • by Nicolas Roard ( 96016 ) on Wednesday April 22, 2009 @03:39PM (#27677979) Homepage
    Right, so the 2nd article states "I should note that this particular exploit requires that the attacker already have admin or root privileges on the box" -- and "The exploit code was only written for Intelâ(TM)s DQ35 motherboards. The DQ35 is one of their modern boards. According to Joannaâ(TM)s paper, Intel reported that their newest motherboards (DQ45â(TM)s for example) are not vulnerable to this attack.". In short, it's an interesting proof of concept, but at first glance it's not exactly the scare of the century....
  • One popular chipset is still far better than all chipsets. Besides, as several other have mentioned, needing to be root to plant a rootkit is a pretty circular security risk.

    It's probably a good thing Intel got bit by this publicly. Maybe they'll be more careful in the future.

  • The point? (Score:5, Informative)

    by srealm ( 157581 ) <prez@@@goth...net> on Wednesday April 22, 2009 @03:48PM (#27678077) Homepage

    "On Linux, if you have root access, you can override the MTR buffers and install a root kit."

    If you already have root access, WTF is the point, just install the root kit. The idea of exploits is to *GET* root access to be able to install these root kits.

    Now while this might be moderately interesting if you can somehow manage to get a service running as root to run said code, but then, if you can get the service running as root to execute arbitrary code like this, then why not get it to install the root kit for you.

    Stupidest exploit scare ever.

    • Re:The point? (Score:5, Informative)

      by Deanalator ( 806515 ) <pierce403@gmail.com> on Wednesday April 22, 2009 @04:18PM (#27678513) Homepage

      Um, wrong?

      The idea of a ROOTKIT is that once you get root access, you want to be able to keep it for later, even if the hole that got you root in the first place gets patched.

      For example, the kids are going in a spree with this new udev vuln that came out recently. They are upgrading all their user shells that they got from mass web exploitation to root shells, and dropping rootkits to make sure that they still have access next month when the boxes are sure to be patched.

      With root it is much easier to do things like sniff outgoing and incoming ssh passwords, and mitm other boxes in a colo, so you can take the whole local network.

  • Finally! (Score:5, Funny)

    by Cornwallis ( 1188489 ) * on Wednesday April 22, 2009 @03:49PM (#27678099)
    2009 will be the Year of the Windows Desktop!
  • by rs232 ( 849320 ) on Wednesday April 22, 2009 @03:51PM (#27678143)
    On Linux systems it is trivial for the root user to modify system MTRRs7 via the /proc/mtrr [invisiblethingslab.com] pseudo-file. Assuming your system is an Intel DQ35 board with 2GB of RAM, it is likely that the "caching map" of your memory looks like this, e.g:


    We see here the first entry (reg00) is marking the whole memory as Write-Back cacheable8. Next we see a bunch of "exceptions" -- regions of memory each marked as uncacheable. One of those regions, (reg03) corresponds to the memory where the SMM's TSEG9 segment is located. We can now simply remove this MTRR entry for TSEG, with the following shell command:

    echo "disable=3" >| /proc/mtrr


    Of course on different systems than Linux, e.g. Windows, one doesn't have such a convenient access to /proc/mtrr pseudo-file. This is however only a minor technicality, as one can very well modify the MTRRs mapping using the standard WRMSR instructions.

    Once the TSEG's memory is marked as WB cacheable, one can do something as simple as:

    *(ptr) = evil_data;
    outb 0x00, 0xb2 // generate SMI
  • So, after getting the root access on Linux, you use this goofy script to install some software.

    Why bother with this crap, when having root access allows you to install the same software without needing the goofy scripts? What additional access does this give you that you don't have by being root?

    Why are kits like this that require root access considered as deadly as Windows viruses that can be easily installed on any Windows system without any user action or password needed?

    • To answer your question, some uber-script-kiddie wants to have uber-root privileges. ;)

      I ain't no Linux guru - but, this really does seem to be a circular logic thing. I gotta be root to install a root kit - but, WHY?!?!?! I'm already root, I already have access to all of root's p0rn (not to mention all the users on the system), WHAT MORE IS THERE?!?!?!!!!

      Maybe I'll change my handle to UberRoot now. I've always wanted to be a master script kiddie.

  • by Bazer ( 760541 ) on Wednesday April 22, 2009 @03:55PM (#27678211)

    Thi story is probably a dupe [slashdot.org]. The original not only has the same blog post, but also has links to far more relevant information. Please tag it.

  • Hell has frozen over (Score:2, Interesting)

    by theorem4 ( 1101729 )
    Could it be that Windows is actually safer?
    • Windows has been safer for a while. If Desktop Linux had the market share that Windows boxes did, hackers would make swiss cheese of it.
  • by ashmodai9 ( 644800 ) <{moc.iadomhsa} {ta} {partmaps}> on Wednesday April 22, 2009 @04:10PM (#27678425) Homepage

    As many have pointed out, there's no real point to "exploiting" a machine that you already have full (root) access to - with one exception: virtual servers.

    The whole 'danger' of this exploit is that it enables a virtual server's "privileged" "root" user to gain hypervisor access, which is equivalent to taking over the entire physical machine and any/all other virtual servers hosted on said machine.

    If you don't run a virtual server farm, this exploit means absolutely nothing to you. If you do, it's a very easy, scary way whereby any of your "clients" can take over your physical machines and access all of the other virtual servers hosted on the same piece of hardware.

  • by viking80 ( 697716 ) on Wednesday April 22, 2009 @04:11PM (#27678433) Journal

    Copied from TFA:
    Here's how the attack works in layman's terms, and Notice the simplicity of this exploit:

    1) Attacker modifies system MTR registers to change the SMM memory space from uncacheable to cacheable with type Write-back. (...) It uses a set of programmable model-specific registers (MSRs). Any type Write-back writes to the CPU's cache are marked dirty. This will force their contents to be written to memory later.

    2) The attacker now can write code into the memory space that is normally reserved only for SMM functions. The attackers accesses to this memory space are now written to the CPU cache because of the changes made in step one. Normally SMM space is marked uncacheable and the chipset will discard any attempts at access except from system BIOS.

    3) Now the attacker code is in the CPU cache memory normally reserved only for SMM. To execute the code the attacker issues an SMI. This triggers a CPU preempt that transfers execution control over to SMM code. The CPU will execute the SMM code but it will fetch it from the cache before DRAM. The attackers data is in cache (step 2) so it is executed. The code now runs with full SMM privileges. Remember that SMM is the most privileged on the box, more so than the operating system or any hypervisors.

  • Meh (Score:2, Insightful)

    by bcat24 ( 914105 )

    So, basically the entire paper boils down to "OMG! Hardware works as advertised, and Linux lets root actually use said hardware." Color me unimpressed (and unconcerned).

  • If the attackers have root access to your linux box, they could use this vulnerability to get root access.

    Now we must get a time machine and a paradox solving engine, and the vulnerability will turn to be pretty scary.
    • Re: (Score:3, Informative)

      by dtolman ( 688781 )
      You missed the point. The description for dummies is: Get root access to one linux VM. Congratulations, you now have undetectable root access to the host server and all the other VMs.
    • Re: (Score:3, Informative)

      Attackers get root and then modify the bios to ensure that whatever you do with the box including install fresh hard drives and reinstall from scratch they still have root.

      This is not a trivial 'oh they need root to install a rootkit' joke.

  • Why the hell would anyone go through the trouble of pulling a motherboard-specific cache exploit, if the program is already running with root privs ?

    How about "cp hax0red-vmlinz /boot" and have a nice day...

  • by damn_registrars ( 1103043 ) <damn.registrars@gmail.com> on Wednesday April 22, 2009 @04:34PM (#27678735) Homepage Journal
    All the hardware I currently use is considered "obsolete" by hardware vendors, software vendors, OS groups, and any kind of support personell you can imagine. However, by being that dated it is also considered to not be worthwhile for virus writers or others who work on compromising peoples' systems en masse.

    Long live my P4, bitches. It might not be perfect, it might not be able to play Quake 7 or any other bleeding edge games, but with each passing month we see more security threats that fall under the category of "unapplicable" to my system.

    Don't even ask me what video card I use, what kind of hard drive I have, what kind of optical drive I use, or what operating systems I boot. I'll likely get carted away to a nice padded room if I try to tell people that those are still useful.
  • Here's what I see (Score:3, Interesting)

    by erroneus ( 253617 ) on Wednesday April 22, 2009 @04:57PM (#27679071) Homepage

    Like so many others, this is an Intel problem.

    I just finished reading up on what SMM is and that it can potentially be used to trash a BIOS, or worse, rewrite a BIOS so that it includes something along the lines of a hypervisor that can then run all kinds of things while at the same time allowing the regular OS to run.

    The comment about Linux making it easier than Windows to exploit this? Kudos for Linux!! Okay, root is required to get to run the exploit code, but after that it is "easy." That's exactly what it should be. We don't need the OS getting in our way when we want to do things with our machines. If Windows makes it harder, that's just sad... but probably necessary. There are few things in Linux that run as root unnecessarily, so running anything as root is usually no accident and isn't usually the result of a process running as root being exploited. (This is typically not the case with Windows... too often processes must run as Administrator and those processes are routinely attacked and exploited.) The threat is fairly minimal... unless someone intentionally weakened their systems for convenience. Sad for those people.

    But this is ultimately limited by the hardware all of this is running on. Older hardware is not affected. Newer hardware will not likely be affected either... and you can probably expect some sort of fix from Intel as well.

    It is an important story and it keeps people thinking in the right ways. The idea that this is a Linux vulnerability is a pathetic assertion. I am all for disclosing and eliminating problems with Linux. The quicker we know about it, the quicker it is fixed. But this is a rather limited scope and when all factors are combined, it makes this a very VERY limited problem.

    • Re: (Score:3, Insightful)

      by blueg3 ( 192743 )

      They don't actually claim that it's a Linux vulnerability. It's a chipset vulnerability that happens to be incredibly easy to take advantage of on Linux, since the kernel already provides a convenient interface to the necessary hardware (rather than having to do it the hard way).

      Note that TFA doesn't mention Linux. The Microsoft Subnet article does, but that's not too surprising. (Note that the Invisible Things guys primarily release proofs-of-concept for Linux.)

    • Linux makes it "easy" only in the sense that Linux provides a /proc file interface to modify the MTRR registers, while Windows requires you to write a few lines of assembly code to do the same thing. That means that Linux is only an easier target for those kiddies with no clue what C is or how to program in it. If you actually know C programming and assembly language, direct access to the MTRRs via assembly's probably easier than mucking around parsing and modifying what looks like a text file.

  • *facepalm* (Score:4, Insightful)

    by darkwhite ( 139802 ) on Thursday April 23, 2009 @12:09AM (#27683023)

    There are at this time about a bazillion comments here pointing out that a privilege escalation that requires root access is not a privilege escalation.

    I don't know what the authors of those comments were doing for the past 5 years, because they should really consider whether they are qualified to talk on the subject. AMD and Intel have been incorporating virtualization and paravirtualization support into their CPUs for a long time, and there is a massive market for these solutions. For an equal amount of time security researchers have been messing around finding exploits like this one in the hardware. Privilege escalation from domain to hypervisor/cross-domain level is a breach of the virtualization security model, and you can bet your ass it's a serious security issue. And if your favorite virtualization solution doesn't consider this a root exploit, then that solution is broken. Because there's no way anyone in their right mind running something like 50 domains on some 24-core beast - made specifically to virtualize the crap out of everything - will consider those domains being able to get root in all other domains to be anything short of a huge problem.

    tl;dr: root is not root if you are in a guest domain. (cue inane Matrix reference to taste)

When you are working hard, get up and retch every so often.