Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel Cache Poisoning Is Dangerously Easy On Linux

timothy posted more than 5 years ago | from the anything-you-set-your-mind-to dept.

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

cancel ×

393 comments

First POST! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#27677909)

Also SHIT!

Re:First POST! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#27677989)

Yes your first post is shit. How perceptive of you.

OpenBSD immune... again. (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27678479)


Yet again, OpenBSD [openbsd.org] shows foresight by having this bugginess fixed in 2003 long before the actual chips were available on which this can happen. Well done, lads.

Linux (5, Funny)

the_one(2) (1117139) | more than 5 years ago | (#27677915)

They make it sound like a bad thing that it's easier to use your hardware on Linux =)

Re:Linux (5, Insightful)

Anonymous Coward | more than 5 years ago | (#27677981)

This attack still requires root access, so all this says is that if you have an Intel DQ35 motherboard, are running linux and you've already been rooted, then someone could probably install a really sneaky rootkit.

Not a nonissue, but also not the end of the world.

Re:Linux (1, Insightful)

piojo (995934) | more than 5 years ago | (#27678453)

This attack still requires root access

This is a desktop system, the user probably either has sudo access, or the user has the same password as root. Either way, that can lead to nasty programs getting root access, unless the user is both careful and paranoid. (I think I'm careful, but my sudo isn't configured with the strictest settings.)

Queue Microsoft Trolls in (1, Funny)

Cryolithic (563545) | more than 5 years ago | (#27677917)

3 2 1

Re:Queue Microsoft Trolls in (4, Insightful)

Svartalf (2997) | more than 5 years ago | (#27677959)

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.

Re:Queue Microsoft Trolls in (0)

SerpentMage (13390) | more than 5 years ago | (#27678151)

Did you read the article?

" With Windows this exploit can be used, but requires much more work and skill "

This is both an Intel and operating system issue.

I think the difference now is that Windows is pretty secure. And the effort required to break Windows is not worth the results. Whereas other operating systems have low hanging fruit and that is being exploited.

So I think it is time for the other operating systems to buckle their seat belts because it could become a rough ride.

Re:Queue Microsoft Trolls in (1)

h4rr4r (612664) | more than 5 years ago | (#27678221)

So how many of those conficker bots are alternate OSes?

Re:Queue Microsoft Trolls in (0)

Anonymous Coward | more than 5 years ago | (#27678577)

I'm going with 0.
To be safe I'll say 0% rounded down to the nearest whole number.

Re:Queue Microsoft Trolls in (4, Insightful)

Roger W Moore (538166) | more than 5 years ago | (#27678257)

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.

Re:Queue Microsoft Trolls in (5, Funny)

grub (11606) | more than 5 years ago | (#27678501)


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

Re:Queue Microsoft Trolls in (3, Interesting)

zx-15 (926808) | more than 5 years ago | (#27678583)

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.

Yeah? How? (2, Insightful)

Weaselmancer (533834) | more than 5 years ago | (#27678641)

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

Re:Queue Microsoft Trolls in (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27678511)

It'd be as easy (different effort...but just as easy...) with Windows or MacOS- because of the nature of the exploit in question.

I obviously didn't RTFA but right in the summary:

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.

So unless you are orders of magnitude better than these researches are, I call BS. It says right there it requires *much more work and skill* to do it in Windows.

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.

Since "Linux allows the root user to access MTR registers incredibly easily..." and apparently Windows and OS X do not; I dare say by all intents and purposes this makes it a Linux thing.

Re:Queue Microsoft Trolls in (5, Funny)

Anonymous Coward | more than 5 years ago | (#27678189)

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.

Re:Queue Microsoft Trolls in (4, Informative)

DrLov3 (1025033) | more than 5 years ago | (#27678241)

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!

Re:Queue Microsoft Trolls in (0)

Anonymous Coward | more than 5 years ago | (#27678369)

Besides the annoying use of 'some1', why was this modded down. It's true.

Re:Queue Microsoft Trolls in (0)

Anonymous Coward | more than 5 years ago | (#27678429)

Microsoft has Trolls?

Really?

Yes, but does it... (3, Funny)

dave562 (969951) | more than 5 years ago | (#27678575)

..run on...

Oh, nevermind.

Re:Queue Microsoft Trolls in (3, Informative)

blackfrancis75 (911664) | more than 5 years ago | (#27678681)

<pedant>..In that sense, you mean *Cue* Microsoft trolls </pedant>

First you need root on the box (2, Informative)

h4rr4r (612664) | more than 5 years ago | (#27677919)

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.

Re:First you need root on the box (4, Funny)

Lord Ender (156273) | more than 5 years ago | (#27678037)

It's a whole new class of vulnerabilities. In addition to remote code execution and privilege escalation vulnerabilities, we now have privilege equalization vulnerabilities. Scary stuff.

Re:First you need root on the box (-1, Redundant)

Sir_Real (179104) | more than 5 years ago | (#27678145)

It's a whole new class of vulnerabilities. In addition to remote code execution and privilege escalation vulnerabilities, we now have privilege equalization vulnerabilities. Scary stuff.

How do you not have any of this if you have root? You're root! You can replace the kernel! This isn't scary at all!

Re:First you need root on the box (5, Funny)

Lord Ender (156273) | more than 5 years ago | (#27678319)

Your post indicates that you are suffering from the wooosh vulnerability.

Re:First you need root on the box (3, Funny)

JCSoRocks (1142053) | more than 5 years ago | (#27678377)

You're 2/2. Where are my bloody mod points when I need them...

Re:First you need root on the box (4, Funny)

should_be_linear (779431) | more than 5 years ago | (#27678415)

It tried to attack my Ubuntu box. I entered admin password on request, but then it complained about missing c libs and opened Synaptic. Lame!

Re:First you need root on the box (4, Insightful)

victim (30647) | more than 5 years ago | (#27678039)

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.

Re:First you need root on the box (4, Interesting)

to6o (838477) | more than 5 years ago | (#27678095)

Even scarier, you can boot from a pen drive, where you have root access and just plant the thing

Re:First you need root on the box (5, Insightful)

h4rr4r (612664) | more than 5 years ago | (#27678197)

If you can stick a pen drive in the box you have physical access and that means all security pretty much goes out the window.

Re:First you need root on the box (1)

amicusNYCL (1538833) | more than 5 years ago | (#27678435)

What? So we're only interested in protecting remote machines now? Don't bother protecting machines that someone might have physical access to, because if you can use the keyboard, there's absolutely no security involved whatsoever.

Re:First you need root on the box (4, Informative)

mce (509) | more than 5 years ago | (#27678481)

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:First you need root on the box (5, Informative)

nedlohs (1335013) | more than 5 years ago | (#27678571)

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:First you need root on the box (1)

nedlohs (1335013) | more than 5 years ago | (#27678593)

Or not if the GP post was false.

Re:First you need root on the box (0)

Anonymous Coward | more than 5 years ago | (#27678399)

If your machine allows you to boot from a pen drive without asking any credentials, your computer was not safe from the start.

Re:First you need root on the box (4, Informative)

Anthony Liguori (820979) | more than 5 years ago | (#27678183)

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 (3, Interesting)

OrangeTide (124937) | more than 5 years ago | (#27678561)

or poke the MTRR...

Re:First you need root on the box (5, Informative)

DaleGlass (1068434) | more than 5 years ago | (#27678195)

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.

MOD this guy up (1)

taniwha (70410) | more than 5 years ago | (#27678623)

SMM doesn't persist across reboots unless you can flash the boot roms/BIOS

SMM buried rootkits (2, Interesting)

rs232 (849320) | more than 5 years ago | (#27678237)

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

Re:First you need root on the box (4, Insightful)

blueg3 (192743) | more than 5 years ago | (#27678175)

If you have root you can plant a root kit in any number of ways, heck just replace the kernel if you want.

Replacing the kernel tends to trigger systems designed to catch intrusions, as it's painfully obvious. Running your malware persistently without being detected by the system is the point of a rootkit.

Re:First you need root on the box (5, Insightful)

LoRdTAW (99712) | more than 5 years ago | (#27678217)

I read the PDF of the exploit and from what it states the code injected into the SMRAM is effectively being executed in a region where no OS or hyper visor can touch. So from what I understand a system running virtualization software only needs one of the guest operating systems to become compromised in order for the attacker to gain control of the entire system. From there the other guest/host OS's or possibly the hyper visor can be attacked. So yes for a single OS system it is redundant to attack the SMRAM because if you already have root then whats the point?

But even with the ability to attack other software on a virtualized DQ35 system, their numbers I am sure are close to none. The DQ35 board is a uATX desktop board. If it were specific to Intel server boards or Intel based server boards then I would worry.

I wonder if this exploit is truly only limited to the DQ35. How many different Intel systems have they tested this on. And what about AMD systems, are they vulnerable to similar attacks?

Re:First you need root on the box (1)

bluefoxlucid (723572) | more than 5 years ago | (#27678459)

Yes, but if your virtualization system doesn't virtualize SMM (and the BIOS by extension both ways), you already have problems. If it allows direct BIOS calls at all, you have an escape.

Re:First you need root on the box (2, Interesting)

dave562 (969951) | more than 5 years ago | (#27678645)

So what you're saying is that if I lease space from a hosting company that has my VM on a system with a DQ35 board, I can jump from my VM into any other VMs that happen to be on the same box?

Re:First you need root on the box (1)

lucag (24231) | more than 5 years ago | (#27678367)

The point of this exploit is not to install a rootkit, but to do it without altering the kernel or the executables at all; this is clever & nice.
Yet, there is the "trascurable detail" that you have to become root first; this seems to be lost to the author of the second piece in the summary.

As the poster says, once you are root you can do anything you want (including, but not limited to, reflash the bios in many cases) and hide all your tracks; to get a rootkit hidden without messing the system, that is definitely more challenging.

Re:First you need root on the box (1)

dsg123456789 (1315293) | more than 5 years ago | (#27678417)

Unlike many other places to put a rootkit, doing it like this makes it very difficult to find. Hiding the rootkit is the other difficult part, and this hides it and makes it resistant to being removed.

"Exploit" implies there was an actual hole (5, Insightful)

amorsen (7485) | more than 5 years ago | (#27677925)

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.

Re:"Exploit" implies there was an actual hole (1, Interesting)

piojo (995934) | more than 5 years ago | (#27678535)

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.

Is it so hard to write a daemon that essentially does "do sudo install_rootkit; sleep 5; while [ $? -ne 0 ]". The syntax may be wrong, but it just tries running sudo until it works. In most systems, sudo permissions are system-wide--once a user uses sudo to install some software, the daemon will succeed in its attempt to get root. Is there a reason this won't work on most linux desktop systems? (Obviously it won't work if the affected account doesn't have sudo.)

Wait, don't you mean easy on windoze... (1)

krovisser (1056294) | more than 5 years ago | (#27677927)

oh noesss my linux!

I think I might be r00t3d (-1, Offtopic)

Gizzmonic (412910) | more than 5 years ago | (#27677933)

Does it affect FP performance? If so, I think I might be r00t3d!

you got root (2, Insightful)

Dionysus (12737) | more than 5 years ago | (#27677941)

If you got root, aren't there easier way to install a rootkit? Just load a rootkit module into the kernel.

Re:you got root (1)

swimin (828756) | more than 5 years ago | (#27678045)

Advantage to this is that you wouldn't have to modify any system files or the kernel.

Article Is Bunkum (0)

Anonymous Coward | more than 5 years ago | (#27677947)

I'm sorry, but this simply ISN'T possible, Linux is flawless God spunk. You people are on drugs.

Re:Article Is Bunkum (1)

nicolas.kassis (875270) | more than 5 years ago | (#27678055)

root is god thus root can do it

Re:Article Is Bunkum (0)

Anonymous Coward | more than 5 years ago | (#27678465)

root is not god. root is owned by god.

Don't you read bash.org?

It requires root privileges and is hw limited ... (5, Informative)

Nicolas Roard (96016) | more than 5 years ago | (#27677979)

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:It requires root privileges and is hw limited . (3, Insightful)

SatanicPuppy (611928) | more than 5 years ago | (#27678071)

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.

Re:It requires root privileges and is hw limited . (4, Insightful)

Creepy Crawler (680178) | more than 5 years ago | (#27678107)

You fail.

hypervisor is higher. And code injected in there, or trojan made as hypervisor and you're screwed.

Re:It requires root privileges and is hw limited . (0)

Anonymous Coward | more than 5 years ago | (#27678181)

Oh... oh YEAH? Well, I'm gonna invent a new computer system after this generation! And that one will have hypersupermegaultravisor access you'd need to get! Stupid hypervisor wuss!

Re:It requires root privileges and is hw limited . (0)

Anonymous Coward | more than 5 years ago | (#27678709)

Just how many systems with micro ATX boards do you think are going to be running things like Xen, VirtualBox, or VMware and be connected to the internet running possibly vulnerable daemons? Not too many as most of those small boards just don't have the expandability that an ATX or E-ATX board would have.

I surely wouldn't use that hardware platform on which to build a virtual host. No room for RAID cards, not enough memory slots, maximum allowable ram too low, etc.... Those are workstation boards, at best, and almost all of those machines that will run any vm's will be doing it in a lab environment, not as internet facing vm's.

I'd say it's pretty fortunate, actually (1)

mr_mischief (456295) | more than 5 years ago | (#27678031)

One popular chipset is still far better than all chipsets. Besides, as several other have mentioned, needing to be root to plant a rootkit is a pretty circular security risk.

It's probably a good thing Intel got bit by this publicly. Maybe they'll be more careful in the future.

Damn (0)

Anonymous Coward | more than 5 years ago | (#27678057)

I can do something on my computer with root.

Shit.

The point? (4, Informative)

srealm (157581) | more than 5 years ago | (#27678077)

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

Re:The point? (0, Redundant)

LanMan04 (790429) | more than 5 years ago | (#27678265)

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.

^^^^^^^^^^^
Quoted from some smart guy.

Re:The point? (1, Informative)

Anonymous Coward | more than 5 years ago | (#27678401)

Right, but when you power the computer off to remove and shred that hard drive, the SMM buried rootkit goes away, because SMM is RAM. So, problem solved.

Re:The point? (4, Informative)

Deanalator (806515) | more than 5 years ago | (#27678513)

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.

Finally! (5, Funny)

Cornwallis (1188489) | more than 5 years ago | (#27678099)

2009 will be the Year of the Windows Desktop!

At the risk of causing a war... (1)

Bobfrankly1 (1043848) | more than 5 years ago | (#27678119)

Another reason not to buy Intel Mobos. Asus and Gigabyte for me, thank you very much!

Re:At the risk of causing a war... (4, Funny)

ITJC68 (1370229) | more than 5 years ago | (#27678393)

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.

Re:At the risk of causing a war... (1)

Bobfrankly1 (1043848) | more than 5 years ago | (#27678591)

This is a wake up call. Linux is becoming more popular and there will be people who will write these exploits for it.

I don't see how this is a wake-up call. A researcher wrote the exploit code as a proof of concept. Even though another researcher states that this might be in the wild, doesn't prove it is. For all we know, no-one outside of these researchers has targeted this chipset on Linux.

I'm all for Linux and FOSS, but trying to relate this as a wake up call is akin to trying to squeeze blood from a turnip.

Overhyped old news. (1)

jdong (1378773) | more than 5 years ago | (#27678141)

The original exploit release ALREADY acknowledges that in Linux, the root user can reconfigure MTRRs from userspace while Windows/OS X can't. The original authors also acknowledge that successful exploitation is highly platform and hardware dependent. However, under those OS'es the equivalent superuser (Administrator, root) can load a kernel module that does the exact same thing. So, I ask, what exactly is the news here? These guys managed to demonstrate an actual exploit on a particular motherboard? Ooh. Aah.

Windows Cache Poisoning only a minor technicality (4, Informative)

rs232 (849320) | more than 5 years ago | (#27678143)

On Linux systems it is trivial for the root user to modify system MTRRs7 via the /proc/mtrr [invisiblethingslab.com] 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:

[..]

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" >| /proc/mtrr

[..]

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.

Once the TSEG's memory is marked as WB cacheable, one can do something as simple as:

*(ptr) = evil_data;
outb 0x00, 0xb2 // generate SMI

Feature not Bug (0)

Anonymous Coward | more than 5 years ago | (#27678153)

This exploit allows a root user, or a kernel, to put code into System Management Memory that is normally only accessible in System Management Mode (SMM). System Management Mode is used by the BIOS writers to keep control of a system even after control has been handed off to an OS. SMM's theoretical use is for hardware monitoring and maintenance. Its practical use is for DRM.

So this sounds like a feature, and not a bug. The Linux kernel should do everything in it's power to disable SMM anyway.

Compiler fault. (1)

eblum (624940) | more than 5 years ago | (#27678161)

Please pardon my ignorance, but isn't this as much linux compiler fault and it is Intel fault? Can you as a programer, decide what goes into the cache and what not?

Re:Compiler fault. (1)

MrDelSarto (95771) | more than 5 years ago | (#27678525)

The operating system needs to be able to control caching behaviour of areas of memory.

Consider if you map the registers of a device into some memory range, you don't want writes there to be cached, e.g. you write to the memory mapped to the device register that syncs your disk or sends a network packet or something and the underlying device doesn't actually see it until the CPU gets around to flushing the cache some random time later.

Userspace programmers should not (and can not) modify this state. The exploit requires root, and from there it's just handy that Linux lets you access these settings via /proc, rather than having to go to the trouble of writing and loading your own kernel module, etc.

Re:Compiler fault. (1)

eblum (624940) | more than 5 years ago | (#27678731)

My OS classes kicked back from the past right into my mind... Even as root or it equivalent on any other OS. I think the "right" and polite behavior for root is: "You may kill any process, but you should not be able to modify the content of any process or thread that it is not your own or that you directly spawned". Because this is actually what happens with this exploit. You insert code into the cache, that when executed it does something like jumping into some other code that does the nasty stuff. Right?

Re:Compiler fault. (1)

TheCycoONE (913189) | more than 5 years ago | (#27678545)

No... see in linux various hardware is made available to the (root) user via the file system. You can, for example, modify the brightness of many laptop screens by echoing text to a file. Of these files, one of them is the mtrr.

Re:Compiler fault. (1)

eblum (624940) | more than 5 years ago | (#27678547)

Answering myself. If the cache is altered, the CPU should rise a flag saying something has happen. I am not sure how the cache works, but I imagine the cache is a table with the address of the value it has cached in one side, and the actual value on the other. If this is the case, who to blame depends if the compiler has any control over the cache, if the cache is hardwired. Or both!

Re:Compiler fault. (1)

kc8apf (89233) | more than 5 years ago | (#27678707)

Yes, as a programmer, you can decide what comes into the cache. If not from C, you can certainly do so from assembly. Many architectures even include cache manipulation instructions so the program can better control cache reuse if it has sufficient external knowledge about the program's behavior.

Ok, easy on Linux (1)

SnarfQuest (469614) | more than 5 years ago | (#27678173)

So, after getting the root access on Linux, you use this goofy script to install some software.

Why bother with this crap, when having root access allows you to install the same software without needing the goofy scripts? What additional access does this give you that you don't have by being root?

Why are kits like this that require root access considered as deadly as Windows viruses that can be easily installed on any Windows system without any user action or password needed?

Re:Ok, easy on Linux (1)

Runaway1956 (1322357) | more than 5 years ago | (#27678487)

To answer your question, some uber-script-kiddie wants to have uber-root privileges. ;)

I ain't no Linux guru - but, this really does seem to be a circular logic thing. I gotta be root to install a root kit - but, WHY?!?!?! I'm already root, I already have access to all of root's p0rn (not to mention all the users on the system), WHAT MORE IS THERE?!?!?!!!!

Maybe I'll change my handle to UberRoot now. I've always wanted to be a master script kiddie.

Probably a month-old dupe (5, Informative)

Bazer (760541) | more than 5 years ago | (#27678211)

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.

Hell has frozen over (2, Interesting)

theorem4 (1101729) | more than 5 years ago | (#27678219)

Could it be that Windows is actually safer?

Re:Hell has frozen over (0)

Anonymous Coward | more than 5 years ago | (#27678323)

Could it be that Windows is actually safer?

No.

Re:Hell has frozen over (1)

not already in use (972294) | more than 5 years ago | (#27678519)

Windows has been safer for a while. If Desktop Linux had the market share that Windows boxes did, hackers would make swiss cheese of it.

If you steal a car ... You can break the motor! (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27678277)

Serious fear mongering.

Vulnerabilities affect secure computers. This is not a vulnerability. At most, its a shady way to build (and perhaps sell) a compromised computer.

This applies to all operating systems. Don't trust factory installs. Always build your environments from scratch -- the extra work will help you understand them. Without trust at the beginning you don't have it, ever.

Re:If you steal a car ... You can break the motor! (1)

SnarfQuest (469614) | more than 5 years ago | (#27678357)

Better car analagy:

You steal a car with the keys in the ignition.

Now, you could just pop open the hood to steal the battery, or like this exploit, you could get to the battery by disassembling the engine from underneath until you reach the battery.

Re:If you steal a car ... You can break the motor! (1)

blueg3 (192743) | more than 5 years ago | (#27678463)

No, stealing the car is a privilege escalation exploit (and potentially a remote code execution exploit first).

This is a rootkit -- which is like deciding what to do with the car after you've stolen it. There are lots of simple, straightforward approaches -- stealing the battery, stealing the stereo, or taking it to a chop shop. You get something, but the owner of the car certainly notices, and once you've stolen the battery and left, your interaction with the car is done. You could steal the car and sell it (bigger payoff), but the chances of getting caught are much higher. This is more like using your access to the car to make a duplicate of the keys and install a hidden tracking device. If all you want is to steal the battery, it's much too complicated. But, it allows you to take what you want when you want it, and gather potentially-useful information (depending on the car's owner) without detection.

Great now 3 people in the world will get hacked. (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27678301)

Great now 3 people in the world will get hacked.

tux is innocent (1)

meushi (1074855) | more than 5 years ago | (#27678355)

the fault is not on linux or any particular os, it's on intel's harware.

This is an exploit for virtual servers (5, Informative)

ashmodai9 (644800) | more than 5 years ago | (#27678425)

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" (4, Informative)

viking80 (697716) | more than 5 years ago | (#27678433)

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.

Tides have changed (-1, Troll)

not already in use (972294) | more than 5 years ago | (#27678439)

The best rapper is white.
The best golfer is black.
Windows is more secure than Linux.

Re:Tides have changed (1, Funny)

Locke2005 (849178) | more than 5 years ago | (#27678733)

The only good rapper is a dead rapper.
I prefer to think of Tiger Woods as a great Thai golfer.
If somebody has physical access to a Windows box, then they can reboot it off a Knoppix Live CD, and they have the same exact problem. If somebody has the Admin password, they can do anything they want too. This only really effects cases where hostile users are running in another Virtual Machine on the box. If you need security, don't share your hardware with other people!

Meh (1, Insightful)

bcat24 (914105) | more than 5 years ago | (#27678521)

So, basically the entire paper boils down to "OMG! Hardware works as advertised, and Linux lets root actually use said hardware." Color me unimpressed (and unconcerned).

Take that you penguin loving bitches... (0)

Anonymous Coward | more than 5 years ago | (#27678597)

C= FTW

Description for dummies (1)

gmuslera (3436) | more than 5 years ago | (#27678675)

If the attackers have root access to your linux box, they could use this vulnerability to get root access.

Now we must get a time machine and a paradox solving engine, and the vulnerability will turn to be pretty scary.

Let me get this straigh... (0, Redundant)

Hurricane78 (562437) | more than 5 years ago | (#27678687)

...it is a danger, that someone on an Intel system, who has root access to a box, can plant a rootkit??

Unpossible! The sky falls down, and earth explodes! I can't believe it!

A root to root exploit ?! (1, Redundant)

billcopc (196330) | more than 5 years ago | (#27678729)

Why the hell would anyone go through the trouble of pulling a motherboard-specific cache exploit, if the program is already running with root privs ?

How about "cp hax0red-vmlinz /boot" and have a nice day...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...