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."
"Exploit" implies there was an actual hole (Score:5, Insightful)
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.
you got root (Score:2, Insightful)
If you got root, aren't there easier way to install a rootkit? Just load a rootkit module into the kernel.
Re:Queue Microsoft Trolls in (Score:4, Insightful)
No kidding...
It'd be as easy (different effort...but just as easy...) with Windows or MacOS- because of the nature of the exploit in question.
This isn't a Linux thing. It's an INTEL issue, of which there's an exploit in the wild under Linux that gets around much of the security in the system.
Re:Linux (Score:5, Insightful)
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:First you need root on the box (Score:5, Insightful)
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.
Re:It requires root privileges and is hw limited . (Score:4, Insightful)
It's not a scare at all. It's only "more difficult" on Windows because Windows "admin" privileges are worthless...System permissions are higher.
This is one of the reasons why Windows viruses have historically been more annoying: they actually run at a level that's higher than the highest user level.
Saying "admin or root" permissions completely misses the point. Root is it. That's the highest level. Kill any process, control any device, install any code, read any file, everything. As many people have pointed out, once you have root you're done. There is no higher exploit than that.
Re:It requires root privileges and is hw limited . (Score:5, Insightful)
You fail.
hypervisor is higher. And code injected in there, or trojan made as hypervisor and you're screwed.
Re:First you need root on the box (Score:5, Insightful)
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.
Re:First you need root on the box (Score:5, Insightful)
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.
Re:First you need root on the box (Score:5, Insightful)
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?
Re:Queue Microsoft Trolls in (Score:5, Insightful)
Re:Linux (Score:1, Insightful)
This attack still requires root access
This is a desktop system, the user probably either has sudo access, or the user has the same password as root. Either way, that can lead to nasty programs getting root access, unless the user is both careful and paranoid. (I think I'm careful, but my sudo isn't configured with the strictest settings.)
Meh (Score:2, Insightful)
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).
Yeah? How? (Score:3, Insightful)
"With Windows this exploit can be used, but requires much more work and skill"
Someone please explain to me exactly how it's harder to get to the MTR registers under Windows than it is under Linux.
Let's assume in both cases you're root. You have to be or they're inaccessible. What happens next? Why is Windows more difficult?
I'm expecting it isn't, and it's about a couple dozen lines of assembler either way.
The benefit of being outdated (Score:3, Insightful)
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.
Re:Linux (Score:2, Insightful)
There is nothing Linux-specific in the exploit. In
fact the article says :
Of course on different systems than Linux, e.g. /proc/mtrr pseudo-file. This is
Windows, one doesn't have such a convenient
access to
however only a minor technicality, as one can very
well modify the MTRRs mapping using the
standard WRMSR instructions.
Re:Queue Microsoft Trolls in (Score:1, Insightful)
Until one talented hacker gets the hack to work and then sells it to someone who integrates it into a worm...
Re:Linux (Score:5, Insightful)
Re:Queue Microsoft Trolls in (Score:3, Insightful)
Windows is it generally handed to you as long as you are sat in front of the machine.
What, the cracker can't reboot into single-user mode?
Re:Here's what I see (Score:3, Insightful)
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.)
Re:Queue Microsoft Trolls in (Score:5, Insightful)
Actually, I like my machine. Please, don't take it. I was just trying to make a point.
Re:Queue Microsoft Trolls in (Score:3, Insightful)
And lock the case so the cracker can't reset the CMOS by disconnecting the internal battery....
Additional Security? (Score:3, Insightful)
Re:Additional Security? (Score:3, Insightful)
The same people that say the same thing about NAT - in other words people that mistake obscurity for security.
Re:Linux (Score:4, Insightful)
Sure that virtual machine is hosed if the attacker gets root, but what about the other virtual machines running on the same host? Exploits that escape virtualization are the next wave of nasty.
*facepalm* (Score:4, Insightful)
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)
Re:Linux (Score:3, Insightful)
Pretty cool stuff, when it comes right down to it.
Re:Queue Microsoft Trolls in (Score:3, Insightful)
The entire idea of requiring code signing as a security measure is horseshit. Signing is supposed to be a method which allows the user to determine if what he has is the real thing. He downloaded or otherwise obtained program A, and wants to know if it actualy came from program source B (because he trusts B.)
If he doesnt trust B, then the fact that A is signed is not material to "security." On the other hand, If he trusts B who has handed him A, then the fact that A is not signed is also not material to "security."
The windows x64 requirement of code signing isn't about trust at all, since it automatically trusts all signed drivers and automatically (and unavoidably) distrusts all unsigned drivers. There are plenty of trustworthy unsigned x64 drivers (developed for XP/64), and you sure as hell can't trust all signed ones (ex: your favorite intrusive copy protection rootkit such as TAGES or SecuROM will be signed)
Nothing about this says "security."
This screams "control" as well as propping up a few specific players in the emerging industry of "signing."