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."

Comments

It requires root privileges and is hw limited ...

[Nicolas Roard]

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....

Re:First you need root on the box

[DaleGlass]

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

[Bazer]

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.

This is an exploit for virtual servers

[ashmodai9]

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.

Re:First you need root on the box

[nedlohs]

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:Yeah? How?

[AigariusDebian]

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:Well that's a good thing then

[Urban Garlic]

> 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:Linux

[SanityInAnarchy]

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
  - modify gcc, thus affecting any new programs downloaded/compiled from source
  - modify tripwire (or whatever they're calling it now), thus hiding itself
  - access /dev/mem, thus making attacks like this seem trivial
  - rm -rf /, thus nuking the system
  - 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 .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.
  - kill any process (except zombied processes)
  - access /tmp, or swap...

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.