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."
Since you need root on the box first, how is this anything new?
If you have root you can plant a root kit in any number of ways, heck just replace the kernel if you want.
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....
"On Linux, if you have root access, you can override the MTR buffers and install a root kit."
If you already have root access, WTF is the point, just install the root kit. The idea of exploits is to *GET* root access to be able to install these root kits.
Now while this might be moderately interesting if you can somehow manage to get a service running as root to run said code, but then, if you can get the service running as root to execute arbitrary code like this, then why not get it to install the root kit for you.
Stupidest exploit scare ever.
On Linux systems it is trivial for the root user to modify system MTRRs7 via the /proc/mtrr pseudo-file. Assuming your system is an Intel DQ35 board with 2GB of RAM, it is likely that the
"caching map" of your memory looks like this, e.g:
/proc/mtrr
/proc/mtrr pseudo-file. This is however only a minor technicality, as one can very well modify the MTRRs mapping using the standard WRMSR instructions.
// generate SMI
[..]
We see here the first entry (reg00) is marking the whole memory as Write-Back cacheable8. Next we see a bunch of "exceptions" -- regions of memory each marked as uncacheable. One of those regions, (reg03) corresponds to the memory where the SMM's TSEG9 segment is located. We can now simply remove this MTRR entry for TSEG, with the following shell command:
echo "disable=3" >|
[..]
Of course on different systems than Linux, e.g. Windows, one doesn't have such a convenient access to
Once the TSEG's memory is marked as WB cacheable, one can do something as simple as:
*(ptr) = evil_data;
outb 0x00, 0xb2
davecb5620@gmail.com
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.
From the article : 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.
If some1 is able to run code on your machine as root, then you have a lot of other and more pressing issues to fix!
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.
Copied from TFA:
Here's how the attack works in layman's terms, and Notice the simplicity of this exploit:
1) Attacker modifies system MTR registers to change the SMM memory space from uncacheable to cacheable with type Write-back. (...) It uses a set of programmable model-specific registers (MSRs). Any type Write-back writes to the CPU's cache are marked dirty. This will force their contents to be written to memory later.
2) The attacker now can write code into the memory space that is normally reserved only for SMM functions. The attackers accesses to this memory space are now written to the CPU cache because of the changes made in step one. Normally SMM space is marked uncacheable and the chipset will discard any attempts at access except from system BIOS.
3) Now the attacker code is in the CPU cache memory normally reserved only for SMM. To execute the code the attacker issues an SMI. This triggers a CPU preempt that transfers execution control over to SMM code. The CPU will execute the SMM code but it will fetch it from the cache before DRAM. The attackers data is in cache (step 2) so it is executed. The code now runs with full SMM privileges. Remember that SMM is the most privileged on the box, more so than the operating system or any hypervisors.
don't cut it off www.mgmbill.org
..In that sense, you mean *Cue* Microsoft trolls
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.
Which you can do with root/admin privileges anyway.
"Slightly harder to detect rootkit now available. Extremely hardware specific."
It's an issue. It needs to be mitigated, but it's nowhere near as bad as the headline makes it sound.
In Linux, the /proc pseudo-filesystem exposes the kernel internals. Anyone can read /proc/mtrr, and root can write it. It's one line of bash, and zero lines of assembler.
No idea how to do it on Windows.
2*3*3*3*3*11*251
I'd think that root can access EVERYTHING incredibly easily. Isn't that kind of the whole point of root? That's why every desktop centric Linux distro I know of has you set up a normal user by default, and many times completely disallow direct root logins.
My blog. Good stuff (when I remember to update it). Read it.
You missed the point. The description for dummies is: Get root access to one linux VM. Congratulations, you now have undetectable root access to the host server and all the other VMs.
> 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
With Windows it can still be done but requires much more work and skill. No Windows exploit code was released.
From the paper:
Of course on different systems than Linux, e.g. Windows, one doesn't have such a convenient access to /proc/mtrr pseudo-file. This is however only a minor technicality, as one can very well modify the MTRRs mapping using the standard WRMSR instructions.
This is an Intel problem. The only reason the exploit is easier on Linux is because of a FEATURE Linux offers (which, btw, you can disable when compiling the kernel).
A user can easily run arbitrary kernel code in 32-bit Vista or Windows (ie. like the root access required in Linux). In Windows >= Vista 64-bit, kernel code must be signed before it is run. So, you must rely on vulnerabilities in that system to run your code.
DQ35 is a desktop motherboard with a single processor and is unlikely to be running too many VMs.
Attackers get root and then modify the bios to ensure that whatever you do with the box including install fresh hard drives and reinstall from scratch they still have root.
This is not a trivial 'oh they need root to install a rootkit' joke.
In the free world the media isn't government run; the government is media run.
sc create rootsvc binpath= "cmd /k start" type= own type= interact && sc start rootsvc && sc delete rootsvc
If the nasty programs get root, you're already hosed.
So yes, this is interesting, but also completely irrelevant. On most systems, root can also
- modify libc, thus affecting every single dynamically-linked program on the system /dev/mem, thus making attacks like this seem trivial /, thus nuking the system .ssh -- and if they have an unencrypted ssh key, thus accessing every machine they have access to! And you can find out which ones by looking at .ssh/known_hosts, and maybe .bash_history. /tmp, or swap...
- modify gcc, thus affecting any new programs downloaded/compiled from source
- modify tripwire (or whatever they're calling it now), thus hiding itself
- access
- rm -rf
- dd if=/dev/zero of=/dev/sda, thus nuking the system even more permanently
- access everyone's xauth, thus their X, thus easily keylogging and screenshotting, if it's a desktop
- access everyone's
- kill any process (except zombied processes)
- access
You get the idea.
There are various ideas to secure root (like selinux, etc), but it is still BAD for them to get root, and the best technique is still to prevent people from getting root in the first place.
Don't thank God, thank a doctor!
Disable CAP_SYS_MODULE and CAP_SYS_RAWIO while the system is in operation, and then you cannot directly access your hardware. rawio to /dev/mem is required for that exploit to work, hence the exploit will be inoperative.
# sysctl kernel.cap-bound
kernel.cap-bound = -257
# sysctl -w kernel.cap-bound=-131329
kernel.cap-bound = -131329
# sysctl -w kernel.cap-bound=-196865
kernel.cap-bound = -19865
Then just drop that last line in /etc/rc.d/rc.local
If you feel really paranoid, also turn off CAP_LINUX_IMMUTABLE, i.e. set sys cap-bound to -20377
After making all your system startup scripts, important programs and config files like your kernel, bootloader, boot config, etc, all +i.
Thus preventing any changes to the boot system or any tampering, except from single user mode, or with some sort of kernel bug.
I just wish the Linux kernel would provide you a sturdy way of 'turning those features back on, for patching... i.e. a sysctl for storing a SHA1 hash of a secret 'unlock' password for re-setting cap-bound
I once found a keylogger written in Python. I don't think I have the code for it anymore, but from what I remember, all it did was ask politely for X to give it all the inputed keys, as well as the name of the window and some other information.
This program did not need to be run as root; however, it would only pick up keys from the X session it was running in (duh) which was usually only the user it was running under. If that user was in the admin group, though, and typed in their password to run something as root, it would catch the password. I think that I started writing a program that tried to root the system through keylogging, but I think that through a combination of boredom with the project and thinking that this was a bit too dangerous a program to exist on my own computer, I purged it. Either way, I can't find any trace of it anymore on my own computer.
If anyone is interested, the program is here.
Personally, I take security on my own computer semi-seriously. I am as guilty as anybody else of running programs as root without doing a full background check on them. I plan to change this at some point, but at the moment I don't have the time to do a full redesign of my computer usage. Perhaps this summer I will... I do, at least, have a non-obvious username, and a root that has no valid password. Oh, and don't forget that blocking program that calls sleep in a loop from /etc/rcS.d that requires someone to press ctrl-alt-del during the boot process in order to finish booting the computer.
I've never understood how virtualization is supposed to enhance security, anyway.
The idea is that you can break the functions of a single machine with a single OS into a single machine running multiple OSes which are theoretically prevented from influencing each other, so that if someone owns your ftpd they didn't just own your httpd as well. The problem with the idea is that only processor emulation can ever really achieve this; by definition if you're messing with virtualization you're executing at least some instructions directly on the host CPU. You have direct access to the hardware at certain points, so your system can only be as secure as the hardware all VMs have access to.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"