Slashdot Mirror
Intel Cache Poisoning Is Dangerously Easy On Linux
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."
They make it sound like a bad thing that it's easier to use your hardware on Linux =)
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.
Finally! A year of moderation! Ready for 2019?
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....
2009 will be the Year of the Windows Desktop!
Actually hackers have much more experience with Win 32 systems than Linux. So while it is easier to program this exploit with Linux, we're still ok because we have security through obscurity.
No, it doesn't work like that.
This came up in a previous discussion. The SMM is simply a part of the normal RAM, used for the CPUs own purposes. While the OS can't normally touch it, it's still RAM and doesn't persist across reboots.
All that putting the virus into SMM RAM means is that as memory not normally accessible by the OS, so an antivirus can't go and scan it. But something has to put the virus into the SMM RAM anyway, and that something is on the hard disk or comes from an exploit through the network.
If you can stick a pen drive in the box you have physical access and that means all security pretty much goes out the window.
Thi story is probably a dupe. The original not only has the same blog post, but also has links to far more relevant information. Please tag it.
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?
Your post indicates that you are suffering from the wooosh vulnerability.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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.
"With Windows this exploit can be used, but requires much more work and skill"
That eliminates the VBS crowd, or about 99.8% of Windows 'programmers'.
Trolling is a art,
Do you buy every new employee a new machine?
Or when Bob leaves does his machine get the hard drive reimaged and Bill uses it?
If so Bob's root kit survived that re image of the hard drive...
There are interfaces to access that stuff in Linux, while in Windows you actually need to write your own custom software in assembly. That is the only difference.
> Just go into whatever driver code that handles the MTRR /proc filesystem and have it spoof writes. The invading rootkit will think "all is swell", and it won't be.
Indeed. In particular, this exploit is really only scary-bad on virtual servers, since it might allow someone with root on a virtual system to get root on the physical box. (On any other system, the attacker was already root, so it's a matter of closing the barn doors...)
A sensible-seeming precaution would be to just disable /proc/mtrr in particular on virtual servers -- it refers to a global physical register, and that's out of scope for a virtual machine anyways.
2*3*3*3*3*11*251
And don't forget about the encrypted root file system. Take my drive. Hell, take my whole machine and you still don't have my data.
Actually, I like my machine. Please, don't take it. I was just trying to make a point.