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."
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?
If you got root, aren't there easier way to install a rootkit? Just load a rootkit module into the kernel.
Je ne parle pas francais.
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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.
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.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
You fail.
hypervisor is higher. And code injected in there, or trojan made as hypervisor and you're screwed.
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.
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.
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 for Linux they require root access and I would argue that acquiring that in the first place requires a lot of work and skill whereas with Windows is it generally handed to you as long as you are sat in front of the machine.
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.)
A cat can't teach a dog to bark.
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).
"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.
Weaselmancer
rediculous.
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
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.
Until one talented hacker gets the hack to work and then sells it to someone who integrates it into a worm...
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!!!
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?
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.)
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.
And lock the case so the cracker can't reset the CMOS by disconnecting the internal battery....
AntiFA: An abbreviation for Anti First Amendment.
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.
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
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.
Socialism: a lie told by totalitarians and believed by fools.
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)
[an error occurred while processing this directive]
Things like SElinux are actually quite a bit more advanced than UAC. Where UAC is pretty much just a thin skin around a priv escalation, SElinux exists to control the level of authority that a pretty thoroughly compromised program or account can exercise. Other tools, like libcap and korset, also exist to enforce the same principles at different layers.
Pretty cool stuff, when it comes right down to it.
They could decide to do it by other means, but...
...they certainly didn't in the case of Atsiv
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."
"His name was James Damore."