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."
They make it sound like a bad thing that it's easier to use your hardware on Linux =)
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.
I would recommend that you don't give out root access to script kiddies on systems where you don't want them to install root kits.
Finally! A year of moderation! Ready for 2019?
If you got root, aren't there easier way to install a rootkit? Just load a rootkit module into the kernel.
Je ne parle pas francais.
No kidding...
It'd be as easy (different effort...but just as easy...) with Windows or MacOS- because of the nature of the exploit in question.
This isn't a Linux thing. It's an INTEL issue, of which there's an exploit in the wild under Linux that gets around much of the security in the system.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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....
It's not a scare at all. It's only "more difficult" on Windows because Windows "admin" privileges are worthless...System permissions are higher.
This is one of the reasons why Windows viruses have historically been more annoying: they actually run at a level that's higher than the highest user level.
Saying "admin or root" permissions completely misses the point. Root is it. That's the highest level. Kill any process, control any device, install any code, read any file, everything. As many people have pointed out, once you have root you're done. There is no higher exploit than that.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
"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.
2009 will be the Year of the Windows Desktop!
You fail.
hypervisor is higher. And code injected in there, or trojan made as hypervisor and you're screwed.
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
Actually hackers have much more experience with Win 32 systems than Linux. So while it is easier to program this exploit with Linux, we're still ok because we have security through obscurity.
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.
Could it be that Windows is actually safer?
"The significance of SMM buried rootkits is that you can remove and shred the hard drive of your compromised machine, replace it with a new one, do a fresh install, and still be compromised"
How big of a rootkit can fit in SMM memory and how does this survive a power off?
davecb5620@gmail.com
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!
Yes but for Linux they require root access and I would argue that acquiring that in the first place requires a lot of work and skill whereas with Windows is it generally handed to you as long as you are sat in front of the machine.
Better to just use AMD CPU and Nvidia Chipsets? Unless those are also exploited. The truth be told is if a hacker wants in and is smart enough given enough time they will find a way in. Up to this point Linux was not popular enough to truly target. Not so anymore. This is a wake up call. Linux is becoming more popular and there will be people who will write these exploits for it. 2009 is the year of Linux on the server and the desktop.
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
Yet again, OpenBSD shows foresight by having this bugginess fixed in 2003 long before the actual chips were available on which this can happen. Well done, lads.
"With Windows this exploit can be used, but requires much more work and skill"
That eliminates the VBS crowd, or about 99.8% of Windows 'programmers'.
Trolling is a art,
..run on...
Oh, nevermind.
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.
"With Windows this exploit can be used, but requires much more work and skill"
Someone please explain to me exactly how it's harder to get to the MTR registers under Windows than it is under Linux.
Let's assume in both cases you're root. You have to be or they're inaccessible. What happens next? Why is Windows more difficult?
I'm expecting it isn't, and it's about a couple dozen lines of assembler either way.
Weaselmancer
rediculous.
..In that sense, you mean *Cue* Microsoft trolls
All the hardware I currently use is considered "obsolete" by hardware vendors, software vendors, OS groups, and any kind of support personell you can imagine. However, by being that dated it is also considered to not be worthwhile for virus writers or others who work on compromising peoples' systems en masse.
Long live my P4, bitches. It might not be perfect, it might not be able to play Quake 7 or any other bleeding edge games, but with each passing month we see more security threats that fall under the category of "unapplicable" to my system.
Don't even ask me what video card I use, what kind of hard drive I have, what kind of optical drive I use, or what operating systems I boot. I'll likely get carted away to a nice padded room if I try to tell people that those are still useful.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
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.
I think you missed the pun. To "queue" a group means to have them form a line so they can each have their turn at something.
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.
Windows is it generally handed to you as long as you are sat in front of the machine.
What, the cracker can't reboot into single-user mode?
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.
Like so many others, this is an Intel problem.
I just finished reading up on what SMM is and that it can potentially be used to trash a BIOS, or worse, rewrite a BIOS so that it includes something along the lines of a hypervisor that can then run all kinds of things while at the same time allowing the regular OS to run.
The comment about Linux making it easier than Windows to exploit this? Kudos for Linux!! Okay, root is required to get to run the exploit code, but after that it is "easy." That's exactly what it should be. We don't need the OS getting in our way when we want to do things with our machines. If Windows makes it harder, that's just sad... but probably necessary. There are few things in Linux that run as root unnecessarily, so running anything as root is usually no accident and isn't usually the result of a process running as root being exploited. (This is typically not the case with Windows... too often processes must run as Administrator and those processes are routinely attacked and exploited.) The threat is fairly minimal... unless someone intentionally weakened their systems for convenience. Sad for those people.
But this is ultimately limited by the hardware all of this is running on. Older hardware is not affected. Newer hardware will not likely be affected either... and you can probably expect some sort of fix from Intel as well.
It is an important story and it keeps people thinking in the right ways. The idea that this is a Linux vulnerability is a pathetic assertion. I am all for disclosing and eliminating problems with Linux. The quicker we know about it, the quicker it is fixed. But this is a rather limited scope and when all factors are combined, it makes this a very VERY limited problem.
"This attack is hardware specific, but unfortunately, it is specific to Intel's popular DQ35 motherboards."
that seems unfortunate only to those who have a DQ35 motherboard. for everyone else, it's fortunate that it's specific to just those boards.
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!
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?
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.
And don't forget about the encrypted root file system. Take my drive. Hell, take my whole machine and you still don't have my data.
Actually, I like my machine. Please, don't take it. I was just trying to make a point.
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.
And lock the case so the cracker can't reset the CMOS by disconnecting the internal battery....
AntiFA: An abbreviation for Anti First Amendment.
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.
Who ever claimed that VM gives or is supposed to give additional security? As far as I know and understand, the purpose of VM is to provide easier management of disparate systems and better overall utilization of expensive hardware.
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
sc create rootsvc binpath= "cmd /k start" type= own type= interact && sc start rootsvc && sc delete rootsvc
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
There are at this time about a bazillion comments here pointing out that a privilege escalation that requires root access is not a privilege escalation.
I don't know what the authors of those comments were doing for the past 5 years, because they should really consider whether they are qualified to talk on the subject. AMD and Intel have been incorporating virtualization and paravirtualization support into their CPUs for a long time, and there is a massive market for these solutions. For an equal amount of time security researchers have been messing around finding exploits like this one in the hardware. Privilege escalation from domain to hypervisor/cross-domain level is a breach of the virtualization security model, and you can bet your ass it's a serious security issue. And if your favorite virtualization solution doesn't consider this a root exploit, then that solution is broken. Because there's no way anyone in their right mind running something like 50 domains on some 24-core beast - made specifically to virtualize the crap out of everything - will consider those domains being able to get root in all other domains to be anything short of a huge problem.
tl;dr: root is not root if you are in a guest domain. (cue inane Matrix reference to taste)
[an error occurred while processing this directive]
They could decide to do it by other means, but...
...they certainly didn't in the case of Atsiv
The entire idea of requiring code signing as a security measure is horseshit. Signing is supposed to be a method which allows the user to determine if what he has is the real thing. He downloaded or otherwise obtained program A, and wants to know if it actualy came from program source B (because he trusts B.)
If he doesnt trust B, then the fact that A is signed is not material to "security." On the other hand, If he trusts B who has handed him A, then the fact that A is not signed is also not material to "security."
The windows x64 requirement of code signing isn't about trust at all, since it automatically trusts all signed drivers and automatically (and unavoidably) distrusts all unsigned drivers. There are plenty of trustworthy unsigned x64 drivers (developed for XP/64), and you sure as hell can't trust all signed ones (ex: your favorite intrusive copy protection rootkit such as TAGES or SecuROM will be signed)
Nothing about this says "security."
This screams "control" as well as propping up a few specific players in the emerging industry of "signing."
"His name was James Damore."