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."
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
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.
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.
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
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.
Linux user since early January 1992.
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...
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.
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
> 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.
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!