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."
Even scarier, you can boot from a pen drive, where you have root access and just plant the thing
"People's problem is not that they are mortal, but that they are suddenly mortal" Terry Pratchett
or poke the MTRR...
“Common sense is not so common.” — Voltaire
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.
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 ...
Weaselmancer
rediculous.
but can root, make a file he himself can't (re)move?
.'. root > god
The answer ofc is yes
QED
IranAir Flight 655 never forget!
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 ;)
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?
To run code in kernel space on Vista x64 it needs to be signed. That will prevent exploits that needs to use kernel mode instructions, unless you find some way around the signed requirement. With Social engineering being the most popular way of getting code into the kernel the signed requirement is a simple and effective way of stopping common attacks.
XP and x32 do not have that "protection" though.
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) 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).