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."
First you need root on the box (Score:2, Informative)
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.
It requires root privileges and is hw limited ... (Score:5, Informative)
The point? (Score:5, Informative)
"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.
Windows Cache Poisoning only a minor technicality (Score:5, Informative)
[..]
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
Re:First you need root on the box (Score:5, Informative)
No, SMM is loaded from ROM memory by the BIOS. You would have to reload the SMM code every time.
What's more, this only works while the SMM code stays resident in the CPU cache. You would need something running at the OS level that was constantly rewriting this memory to ensure it stayed in the CPU cache.
I expect this would actually be quite difficult to build a root kit with that was not as easy to detect as any other root kit.
Re:First you need root on the box (Score:5, Informative)
No, it doesn't work like that.
This came up in a previous discussion. The SMM is simply a part of the normal RAM, used for the CPUs own purposes. While the OS can't normally touch it, it's still RAM and doesn't persist across reboots.
All that putting the virus into SMM RAM means is that as memory not normally accessible by the OS, so an antivirus can't go and scan it. But something has to put the virus into the SMM RAM anyway, and that something is on the hard disk or comes from an exploit through the network.
Probably a month-old dupe (Score:5, Informative)
Thi story is probably a dupe [slashdot.org]. The original not only has the same blog post, but also has links to far more relevant information. Please tag it.
Re:Queue Microsoft Trolls in (Score:4, Informative)
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!
Re:The point? (Score:1, Informative)
This is an exploit for virtual servers (Score:5, Informative)
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.
This article sets a new bar for "layman's terms" (Score:5, Informative)
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.
Re:First you need root on the box (Score:5, Informative)
The key point is that it's a problem that will survive a complete reinstall. Of course, physical accessibility is a really major problem. But if, after an intrusion (or because you even just suspect that someone might have had physical access for no more than say 5 minutes), you positively remove physical access and reinstall the box as a precaution, the rootkit will still be there.
Proper management of security risks requires not only that you restrict physical access and feel good about having done so. It also requires you to have multiple layers of protection, just in case some piece of your armor unexpectedly fails after all. And, crucially, it requires you to be able to recover in case something illegal does happen despite all your efforts.
Re:The point? (Score:5, Informative)
Um, wrong?
The idea of a ROOTKIT is that once you get root access, you want to be able to keep it for later, even if the hole that got you root in the first place gets patched.
For example, the kids are going in a spree with this new udev vuln that came out recently. They are upgrading all their user shells that they got from mass web exploitation to root shells, and dropping rootkits to make sure that they still have access next month when the boxes are sure to be patched.
With root it is much easier to do things like sniff outgoing and incoming ssh passwords, and mitm other boxes in a colo, so you can take the whole local network.
Re:First you need root on the box (Score:5, Informative)
Do you buy every new employee a new machine?
Or when Bob leaves does his machine get the hard drive reimaged and Bill uses it?
If so Bob's root kit survived that re image of the hard drive...
Re:Queue Microsoft Trolls in (Score:3, Informative)
Re:Yeah? How? (Score:5, Informative)
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.
Re:MOD this guy up (Score:2, Informative)
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.
Re:Yeah? How? (Score:5, Informative)
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.
Re:Queue Microsoft Trolls in (Score:4, Informative)
Re:Description for dummies (Score:3, Informative)
Re:Well that's a good thing then (Score:5, Informative)
> 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.
Re:First you need root on the box (Score:2, Informative)
Linux is also perfectly capable of ignoring ctrl+alt+del keystrokes, so you might not even be able to reboot with just access to the keyboard. Actually, there doesn't even need to be a single usermode at all.
So no, access to the keyboard doesn't have to be enough to do anything. Physical access to the machine is a different story, although there is still stuff you can do in that case, to at least make it harder to compromise the system (encrypted disks for example).
Re:First you need root on the box (Score:3, Informative)
Not that you can jump into another VM but possibly inject code into them which in turn allows you to gain access to them. Or gives you access to the hypervisor which could lead to similar results. I am no security expert but from what I heave read in the paper it does appear to be possible. I highly doubt the DQ35 is going to be found in a data center serving VM's though. Systems serving VM's are most likely dual/quad CPU systems with multicore CPU's.
Re:Yeah? How? (Score:5, Informative)
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.
Re:Linux (Score:2, Informative)
DQ35 is a desktop motherboard with a single processor and is unlikely to be running too many VMs.
Re:Description for dummies (Score:3, Informative)
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.
Re:It requires root privileges and is hw limited . (Score:2, Informative)
sc create rootsvc binpath= "cmd /k start" type= own type= interact && sc start rootsvc && sc delete rootsvc
Re:Linux (Score:5, Informative)
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.
How to stop this exploit (Score:2, Informative)
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
Re:Linux (Score:4, Informative)
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 [sourceforge.net].
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.
Re:Linux (Score:3, Informative)
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.