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."
Re:First you need root on the box (Score:4, Interesting)
Hell has frozen over (Score:2, Interesting)
SMM buried rootkits (Score:3, Interesting)
How big of a rootkit can fit in SMM memory and how does this survive a power off?
If you steal a car ... You can break the motor! (Score:1, Interesting)
Serious fear mongering.
Vulnerabilities affect secure computers. This is not a vulnerability. At most, its a shady way to build (and perhaps sell) a compromised computer.
This applies to all operating systems. Don't trust factory installs. Always build your environments from scratch -- the extra work will help you understand them. Without trust at the beginning you don't have it, ever.
OpenBSD immune... again. (Score:2, Interesting)
Yet again, OpenBSD [openbsd.org] shows foresight by having this bugginess fixed in 2003 long before the actual chips were available on which this can happen. Well done, lads.
Re:"Exploit" implies there was an actual hole (Score:2, Interesting)
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.)
Re:First you need root on the box (Score:4, Interesting)
or poke the MTRR...
Re:Queue Microsoft Trolls in (Score:4, Interesting)
I don't think it's the issue of Windows being more secure, rather of Linux exposing more of underlying hardware. Since it is a proof-of-concept exploit, it's much easier to write a shell script for linux that does the job as opposed to hunting down some obscure windows API that do the same thing, plus you've got source code for the kernel so you know exactly what has to be done.
Re:First you need root on the box (Score:3, Interesting)
Well that's a good thing then (Score:5, Interesting)
Ah, I gotcha. Use /proc on Linux, but you'll need to read/write to some address with assembly on Windows. Got it.
But a thought occurs to me though...
Everybody thinks you can get to it through /proc? Good.
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.
Of course any utilities that expect a working proc for MTRR will bomb, but other than that a patch for this should be trivial.
#ifdef HARDWARE_DQ35 ...
Here's what I see (Score:3, Interesting)
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:Linux (Score:3, Interesting)
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.
unfortunate? (Score:2, Interesting)
"This attack is hardware specific, but unfortunately, it is specific to Intel's popular DQ35 motherboards."
that seems unfortunate only to those who have a DQ35 motherboard. for everyone else, it's fortunate that it's specific to just those boards.
Re:Linux (Score:1, Interesting)
You appear to be trying to destroy your system.
Allow or cancel?
Re:Article Is Bunkum (Score:4, Interesting)
but can root, make a file he himself can't (re)move?
.'. root > god
The answer ofc is yes [securityfocus.com]
QED
Re:Linux (Score:5, Interesting)
Re:Queue Microsoft Trolls in (Score:4, Interesting)
Did nobody notice the little side bar that starts "About Microsoft Subnet Blog .. The Microsoft Subnet blog is the official blog of the Network World's Microsoft Subnet community, managed by editor Julie Bort. Microsoft Subnet is the independent voice of Microsoft customers ..."
Am I paranoid or does that scream "astroturfing operation" to anybody else?
Re:Queue Microsoft Trolls in (Score:5, Interesting)
XP and x32 do not have that "protection" though.
Re:Linux (Score:3, Interesting)
It's a religious thing I think. Unix was designed (to the extent is was designed rather than simply happening) to be run as either root or as a user with VERY limited capabilities. But it turns out that there is a need to secure it, and a lot of folks have latched onto the notion that somehow that can be done by isolating the root/admin user. They have faith that there must be an answer, and root isolation has to be it.
As far as I can see the chances of that working are slim to none. But who knows, sometimes I'm wrong. Maybe they can make it work. I hope they can actually.
Personally, I'm going to continue to run as root until they get most of the very numerous bugs out of their security model. Things like operations that don't appear to need root, but really do; and things that run subtly differently as root and user; and configuration files that are replicated with different contents in the root and user accounts. I reckon that I'm just not smart enough to use the security model and at the age of 70, I'm not very trainable.
Not that I have a better idea of how to secure a desktop PC. Because I don't.
Overall, I think that hanging a St Christopher medal on my monitor might be about as effective -- and a lot less of a PITA.
===
And I seem to be missing something. If there is a keylogger running, isn't the system already compromised? Even assuming that only the user account is compromised and that a hacker exists smart enough to compromise my user account but too dumb to escalate privileges, exactly how does that help ME out? It's not like my sensitive data is secured in the root account.
Re:Linux (Score:5, Interesting)
If an attacker can run code as your user account, then they can insert alias sudo=evilpasswordstealingsudo (as well as alias su=evilpasswordstealingsu) into your .bashrc and wait for you to start a new shell and run one of those commands.
Basically, if an attacker gets local access to an account that is ever used to privilege escalate to root, then the attacker can get root. And even if not, there are frequently local root exploits (like a recent udev bug [lwn.net]) that can escalate ordinary user privileges to root privileges. You should always assume that once an attacker has some access to a machine, that they can root it; treat any kind of remote-code execution exploit as if it were a remote root, and treat any kind of privilege escalation exploit as a remote root (since if one exists, there's a high probability that the other does too).