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

Linux

[the_one(2)]

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

Re:Linux

[Anonymous Coward]

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

[piojo]

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

Re:Linux

[AigariusDebian]

Yep, all it said is that it is easer to program things in Linux.

Re:Linux

[Anonymous Coward]

There is nothing Linux-specific in the exploit. In
fact the article says :

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.

Re:Linux

[dtolman]

Why is this insightful? This is a problem that can be exploited through a hosted VM! If you've rooted one VM on a system, now you can jump to the host server and all the other hosted VM's. And oh yeah - theres no way to detect it at all!!!

Re:Linux

[Bert64]

Well, if you're running any other os and someone has root equivalent access, they could easily upload a minimal linux distro, configure your bootloader to silently start it at the next boot and then install the rootkit, followed by rebooting into whatever normal os you have...
In short, if someone has root level access to your machine, you are screwed whatever os you run.

Re:Linux

[speculatrix]

$ sudo rm -rf /

You appear to be trying to destroy your system.
Allow or cancel?

Re:Linux

[AVee]

Indeed, the potential this has to cross-infect VM is the biggest issue here. It's more then just another way to hide a rootkit, it totally breaks all that added security you where supposed to get through virtualization. Oh, and it makes running a honeypot on a DQ35 system an extremly bad^H^H^Hinteresting idea ;)

Re:Linux

[RichardJenkins]

Does anyne know what sort of a risk is it to use sudo or gksudo? Could a malicious key logger start in the background and intercept my password so that it can in turn use sudo to gain root access?

Re:Linux

[Icegryphon]

I would expect such talk from a Skynet bot.

Re:Linux

[Anonymous Coward]

I seriously doubt anyone's going to get rooted from a virtual machine sharing a desktop motherboard.

Re:Linux

[the_brobdingnagian]

I can't find a authoritative answer on the VM issue, but I had the same feeling when I read this news.

Assuming you can use this (or similar) attack to escape a VM, you don't even need to root a box. Just rent a virtual box and you have instant root access to all virtual machines on the box. This shows that you really can't trust a VM as a security tool. A VM is great as a testing tool or as a way to rent really cheap "servers", but if you want security use a separate box.

Re:Linux

[Anonymous Coward]

DQ35 is a desktop motherboard with a single processor and is unlikely to be running too many VMs.

Re:Linux

[JackieBrown]

If a keylogger can grab your password, it won't matter if you are using su or sudo. Either way, you are typing in your password.

I prefer su with sudo for limited users and applications.

My root password is much more difficult to guess than my user password. The downside is that they already know the admin's user name

Re:Linux

[Anonymous Coward]

I've been using Linux a while now.

Using sudo somehow feels wrong, as opposed to opening a terminal and doing what needs to be done as root.

When I use sudo then I end up typing my password quite often. In Ubuntu at least. It seems the more often a password is entered, the more chance of it being sniffed.

Are there any good reasons to avoid sudo, or am I just being paranoid?

Re:Linux

[vtcodger]

It's a religious thing I think. Unix was designed (to the extent is was designed rather than simply happening) to be run as either root or as a user with VERY limited capabilities. But it turns out that there is a need to secure it, and a lot of folks have latched onto the notion that somehow that can be done by isolating the root/admin user. They have faith that there must be an answer, and root isolation has to be it.

As far as I can see the chances of that working are slim to none. But who knows, sometimes I'm wrong. Maybe they can make it work. I hope they can actually.

Personally, I'm going to continue to run as root until they get most of the very numerous bugs out of their security model. Things like operations that don't appear to need root, but really do; and things that run subtly differently as root and user; and configuration files that are replicated with different contents in the root and user accounts. I reckon that I'm just not smart enough to use the security model and at the age of 70, I'm not very trainable.

Not that I have a better idea of how to secure a desktop PC. Because I don't.

Overall, I think that hanging a St Christopher medal on my monitor might be about as effective -- and a lot less of a PITA.

===

And I seem to be missing something. If there is a keylogger running, isn't the system already compromised? Even assuming that only the user account is compromised and that a hacker exists smart enough to compromise my user account but too dumb to escalate privileges, exactly how does that help ME out? It's not like my sensitive data is secured in the root account.

Re:Linux

[stsp]

it totally breaks all that added security you were supposed to get through virtualization

Virtualization does not add any security to the overall system. Adding more code to a system cannot make it more secure by definition. You need less code running in the system to have less bugs in the system that malware authors can exploit. Adding virtualization adds yet another attack vector for malware: attacking the hypervisor. See http://en.wikipedia.org/wiki/Blue_Pill_(malware), for example. There are good reasons for using virtualization, but improving overall system security isn't one of them.

Re:Linux

[Kz]

any software running on a VM is limited to that VM, no matter how rooted is the VM's OS, it doesn't have access to the real CPU's MTRR

Re:Linux

[speedtux]

Adding more code to a system cannot make it more secure by definition.

According to which definition would that be?

(I generally sympathize with the idea of keeping things very simple in order to help security, but that's a rule of thumb, not something "by definition")

Re:Linux

[jspenguin1]

How does this allow you to break out of a VM? Guest machines don't have access to host MTRRs. Since MTRRs are used to control caching, there isn't any need for a virtual machines to emulate them.

I just confirmed this running VirtualBox, using a Linux guest. On the guest, /proc/mtrr is empty. Trying to write to it fails with "write error: Function not implemented". On the host, /proc/mtrr contains 2 write-back, 2 uncacheable, and 1 write-combining MTRR.

Any virtual machine that doesn't trap the WRMSR instruction isn't worth considering.

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.

Re:Linux

[elizium23]

You'll want a St. Isidore medal. He's the (still-unofficial) patron of computers and the Internet.

Re:Linux

[lgw]

SE Linux is the right approach. It's not quite designed to secure a desktop PC, as it was a server solution, but it's the right approach. Limit what programs, not users, can do. There are various non-signature based AV solutions that use this approach as well, but again it's not desktop ready.

You could build a quite secure and unobtrusive security model for the desktop by bundling the "permissions envelope" with the app itself in the package management system. To the extend that you only installed apps from trusted sources, and the package management system would verify digital signatures, you'd have an environment where exploits didn't matter much.

Limt each app to what it needs to access to do it's job - no privilege escalation allowed. Limiting what a user can do makes far less sense, and some meachanism for privilege escalation is unavoidable.

Re:Linux

[lgw]

Sure that virtual machine is hosed if the attacker gets root, but what about the other virtual machines running on the same host? Exploits that escape virtualization are the next wave of nasty.

Re:Linux

[RAMMS EIN]

``it totally breaks all that added security you where supposed to get through virtualization.''

I've never understood how virtualization is supposed to enhance security, anyway.

Re:Linux

[Anonymous Coward]

...It's more *than* just another...

Re:Linux

[SanityInAnarchy]

Exploits that escape virtualization are the next wave of nasty.

I suppose. Does this?

Re:Linux

[npsimons]

the best technique is still to prevent people from getting root in the first place.

Which is why on most decent distributions root is not the primary account (default setup) and sometimes root is locked out altogether (eg, SELinux). This is also why most people still (justifiably) claim that Linux is more secure than Windows in just about every way possible: Windows' default user is root![1]

Footnote[1]: I don't know about more recent versions of Windows; I try not to touch the stuff unless I have to, and the most recent times I've had to (2000 and XP), Windows still seemed to have this problem. Even in the hands of highly skilled Windows admins, Windows seems to wallow in its insecurity.

Re:Linux

[profplump]

On a system where only one user needs root access sudo isn't terribly useful. Some people like to avoid opening root shells -- while it's certainly harder to muck things up without a root shell it's also harder to get work done. Personally I use sudo to open root shells when I need them.

But sudo is much more useful on multiuser systems -- you can grant several people root access without sharing a password, which has obvious benefits. You can also grant users access to the root (or any other) account only for certain commands, as an alternative to setuid for situations where setuid is dangerous, infeasible, or does not provide enough control.

Re:Linux

[collinstocks]

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.

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

[Beat The Odds]

The other day I was trying to explain this so someone with regards to dual booting Windows and Linux. If your windows machine gets infected and the attacker gets "root" access. Your Linux machines is also completely at risk.

In other words, root access (whatever that means for whichever OS you use) means TOTAL CONTROL of the computer.

This person was under the impression that Linux was safe, even when the other OS might get compromised. WRONG!!!!

Re:Linux

[Anonymous Coward]

Excuse my ignorance but how can a guest change the MTRRs of the host and trigger a SMI? Wouldn't the hypervisor trap those instructions?

Re:Linux

[i.of.the.storm]

That is basically what UAC in Vista tries to address, but people seem to find it annoying and disable it. With UAC on, even if you're logged in as an admin account, programs will run with reduced privileges unless elevated. There is a handy middle-ground mode, accessible only using a program called TweakUAC or I presume the registry, which has all programs running unprivileged but doesn't do popups all over the place. I use this and it's rather nice.

Re:Linux

[fractoid]

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.

If you've already been rooted, couldn't the attacker install said really sneaky rootkit by using devious hacker commands like 'cp'? Why bother trying to inject code when you can already do whatever you want?

(Honest question, maybe I missed something.)

Re:Linux

[Sadsfae]

The other day I was trying to explain this so someone with regards to dual booting Windows and Linux. If your windows machine gets infected and the attacker gets "root" access. Your Linux machines is also completely at risk.

This is not true for a dual boot setup using any standard Linux filesystem - Windows is not able to natively see/read/access ext2 and ext3 partitions.

Re:Linux

[fractoid]

Oh. OK, I get it now - the VM thing. Some guy rents a VM on your server cluster, fiddles the MTR, breaks out of the VM and can mess with other users' VMs, or outright kill them and take full control of the box.

Re:Linux

[annodomini]

If an attacker can run code as your user account, then they can insert alias sudo=evilpasswordstealingsudo (as well as alias su=evilpasswordstealingsu) into your .bashrc and wait for you to start a new shell and run one of those commands.

Basically, if an attacker gets local access to an account that is ever used to privilege escalate to root, then the attacker can get root. And even if not, there are frequently local root exploits (like a recent udev bug) that can escalate ordinary user privileges to root privileges. You should always assume that once an attacker has some access to a machine, that they can root it; treat any kind of remote-code execution exploit as if it were a remote root, and treat any kind of privilege escalation exploit as a remote root (since if one exists, there's a high probability that the other does too).

Re:Linux

[debatem1]

Things like SElinux are actually quite a bit more advanced than UAC. Where UAC is pretty much just a thin skin around a priv escalation, SElinux exists to control the level of authority that a pretty thoroughly compromised program or account can exercise. Other tools, like libcap and korset, also exist to enforce the same principles at different layers.

Pretty cool stuff, when it comes right down to it.

Re:Linux

[Anonymous Coward]

Why is this insightful? This is a problem that can be exploited through a hosted VM! If you've rooted one VM on a system, now you can jump to the host server and all the other hosted VM's.

Err... no you can't. VMs don't have access to host MTRRs, unless the VMM is completely borked. Hence the attack doesn't work.

Re:Linux

[Yfrwlf]

I think more programs need to be user-land, and perhaps there should be more gradients between root and a normal desktop user. With PolicyKit though, specifying exactly what permissions users have is more finely tuned. Perhaps in the user permissions section, they need to simply separate more things out of "Administer the System" and make more permissions.

Re:Linux

[CRCulver]

Exploits that escape virtualization are the next wave of nasty.

No kidding. Remember when they took over the Enterprise?

Re:Linux

[RivieraKid]

Um, if you get rooted, the attacker has total access to the physical machine regardless of operating system. It doesn't matter if Windows can read a Linux filesystem - if your attacker can natively read it then its game over, and there are plenty of tools out there to allow read/write access of ext2/3/4 filesystems from Windows. Just ask Google Ext2/3/4 is not the partition - it's the filesystem.

Windows is not able to natively see/read/access ext2 and ext3 partitions.

It's a partition - Windows can see/read/access any partition. It's the filesystem it has no native support for.

Re:Linux

[julesh]

Why is this insightful? This is a problem that can be exploited through a hosted VM!

[citation needed]

It doesn't say this in the linked article. Looking at the source code for the exploit, I see no way it could work:

* First of all, it needs to be able to map virtual to real addresses; this is extremely difficult in a VM.
* Secondly, it writes to MTRRs. This is a virtualized operation that is handled by the hypervisor. I see no reason to believe the hypervisor would have the same bug as Intel CPUs in this regard.

Re:Linux

[ageforce_]

I entirely agree with you. I have proposed improvements on the KDE brainstorming forum, but unfortunately nobody really seems to care, or my proposal is just not good enough... http://forum.kde.org/avoid-password-stealing-t-39488.html

Re:Linux

[Eunuchswear]

The Linux partition could be safe against snooping and modification (but not destruction) if it was encrypted.

Re:Linux

[FireFury03]

Adding more code to a system cannot make it more secure by definition.

I guess we'll all need to go back to using telnet, http and ftp to exchange data securely then, since using ssh, and ssl can't possibly make things more secure since they are way more complex...

There are good reasons for using virtualization, but improving overall system security isn't one of them.

Patently untrue - there are a lot of security advantages from segregating services. Sure, the chances of each service getting compromised are unchanged, but the point is that the damage that compromise can do is generally much more limited. You'll always have exploits - the point of security is to reduce the number of possible exploits. In this example, virtualisation will have reduced the number of known ways of a compromised service affecting another service to approximately one (and only on certain hardware).

Re:Linux

[Xabraxas]

Things like SElinux are actually quite a bit more advanced than UAC. Where UAC is pretty much just a thin skin around a priv escalation, SElinux exists to control the level of authority that a pretty thoroughly compromised program or account can exercise. Other tools, like libcap and korset, also exist to enforce the same principles at different layers.

That's not quite true. UAC is tied into Vista's MIC (Mandatory Integrity Control) which is very much like a MAC (Mandatory Access Control) system. SELinux implements MAC. It's actually not as different as you make it out to be.

Re:Linux

[SanityInAnarchy]

perhaps there should be more gradients between root and a normal desktop user.

The old solution was to use different users and groups for different things. A properly configured sudo helps -- you could have the 'mysql' user and group, under which the mysql process runs, and a 'mysql_admin' group, which is allowed to run a few mysql-related commands as root.

In fact, I think someone proved at one point that Unix permissions can do anything ACLs can, you just end up with a lot of groups.

I don't think, even in a modern distro, that there's too much stuff that requires root. I think the essential problem is that the user who owns the machine will be root. The only alternative is to give everyone an admin, or to have the person who set up the machine implement very complex sudo rules such that full root is denied, but things like updating the system and installing new packages are still allowed.

Re:Linux

[SanityInAnarchy]

If your windows machine gets infected and the attacker gets "root" access. Your Linux machines is also completely at risk.

That is true, but also (for the moment) extremely unlikely, and it can be avoidable.

For example: one solution is to install each on a separate hard drive. That makes it more difficult to share files between the two -- so put those on a network share, or on an external drive. Now, if you actually physically switch between the drives when rebooting, it is also physically impossible for Windows to touch the Linux filesystem -- it can just trash all the files that you've made shared.

Another solution: run one in a VM. Now, if the host OS gets compromised, you're hosed, but if the guest OS gets compromised, the host OS is fine.

The solution I used to use, on a laptop: Boot Linux off a USB thumb drive. Keep root and swap encrypted; /boot goes on that drive. Thus, Windows can scribble all over my Linux partition, but it can't do any sort of selective attack, nor can it gain any information -- it can just randomly corrupt it.

I don't let it bother me right now, though. I don't make much of a habit of letting my Windows machine get compromised, and I re-image it often. I also take solace in the fact that this kind of attack is currently theoretical, and there's even less incentive for someone to do this than there is for someone to try to attack Linux desktop machines. They'd probably have to be targeting me personally, and they'd still have to get lucky with a Windows vulnerability.

Re:Linux

[LifesABeach]

Hell, I'm still working on how this is easier than Root-Kitting Windows. The Parent of this article is starting to smell like fish, left 3 days in the sun. My experience with "Researchers" not stating their names is; 1, Its FUD, and 2, They're Show-Offs. When people do not put their names next to their research, then the results are at best, foundationless. I have found that beating the drum for Windows is a Fool's Errand.

Re:Linux

[Tuoqui]

Oh dont worry we know your password is hunter2.

Re:Linux

[drinkypoo]

Windows defaults to creating an Administrator user at install, but in a corporate context nobody lets their users run this way unless they're expecting to reimage frequently, or they just run Deep Freeze (or similar.) You can rename the Administrator account, or even lock it out entirely so long as you make sure any services which need to start as Administrator are changed to start as some other account with appropriate privileges. This doesn't differentiate it from Unix at all, except that by default less things on a Unix machine start as root; many of them have their own UID and even GID. Ideally, only things which MUST run as root would do so...

Re:Linux

[Fujisawa Sensei]

it totally breaks all that added security you were supposed to get through virtualization

Virtualization does not add any security to the overall system. Adding more code to a system cannot make it more secure by definition. You need less code running in the system to have less bugs in the system that malware authors can exploit. Adding virtualization adds yet another attack vector for malware: attacking the hypervisor. See http://en.wikipedia.org/wiki/Blue_Pill_(malware), for example. There are good reasons for using virtualization, but improving overall system security isn't one of them.

Unless you happen to be running your web server in one VM, app server in another, and database in yet a third.

Re:Linux

[drinkypoo]

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.

Re:Linux

[debatem1]

MIC and SElinux aren't really all that similar. MIC just basically assigns one of four categories to each process and puts each object in one of those four buckets, and disallows on that basis. SElinux, on the other hand, allows you to do much finer grained settings. More importantly, though, MIC sets object settings on a global basis, where SElinux can set them on a number of different dimensions.

Re:Linux

[Anonymous Coward]

Which is a great reason not to use ext2/3/4 for your home directory at minimum, the entire system optimally. I'm still looking for a windows driver for jfs or xfs.

Someone can trash the data, but they can't steal it. My data is all backed up, so my only real concern is someone stealing the data. It's probably more trouble then it's worth for a script-kiddie to pull all that unusable-by-windows data on the off chance they can find a way to read it.

Re:Linux

[xiong.chiamiov]

Which is why you really *should* use full paths for important administrative applications like sudo.

Re:Linux

[Metaphorically]

hehe, if only it were so simple. I miss the days when all a virus wanted to do was delete everything on your hard drive.

Re:Linux

[belphegore]

This is why I always use blank passwords! Take that, keyloggers!

Re:Linux

[lgw]

It certainly allows for it. I don't think there's a proof of concept yet. Of course, there are other (probably easier) ways to escape virtualization as well - only something like Trusted Computing can prevent this, and unless that becomes an open standard no one's going to trust it.

Re:Linux

[SanityInAnarchy]

Of course, there are other (probably easier) ways to escape virtualization as well

Interesting. I suspect Amazon might like to know about this.

Re:Linux

[Xabraxas]

MIC and SElinux aren't really all that similar. MIC just basically assigns one of four categories to each process and puts each object in one of those four buckets, and disallows on that basis. SElinux, on the other hand, allows you to do much finer grained settings. More importantly, though, MIC sets object settings on a global basis, where SElinux can set them on a number of different dimensions.

My point was that UAC is more than a "thin skin around privelege escalation". It is not as simple as something like sudo. You are not automatically given full priveleges when UAC is invoked. You are only given enough priveleges to execute a program within the necessary integrity level.

Re:Linux

[lgw]

The one demonstrated "escape" I've seen was specific to VMWare, but I don't follow this stuff on a daily basis. It's really a hot topic with security researchers (of various hat colors) both because of clouds and because of quickly increasing use of VM-alikes. One would hope that no banks are using EC2 fo anything important, but then banks aren't exactly the icons of responsibility these days.

There are also methods to leak data between virtual machines on the same host, which are of great concern to those wanting to mix secret and normal (or secret and top secret, or whatever) VMs on the same mainframe. You don't even need to escape to compromise security in that scenario.

Re:Linux

[debatem1]

Sure. Same thing as what happens with sudo. Most people don't configure it to do anything more than grant root, but its actually quite a bit more powerful than that. And anyway, my intent wasn't to slam UAC, but rather to point out that where the goal of UAC was to provide a pretty mechanism for priv escalation, something like SElinux is designed to effectively provide a supplemental security model.

Re:Linux

[Xabraxas]

Sudo doesn't integrate with MAC. It's purely a DAC solution. With UAC you can launch a program as low integrity and if spawns a process that needs more privileges UAC will ask you for those priveleges. With sudo you have to be running with the highest priveleges necessary to run a program that spawns a process that requires elevated privileges. Sudo changes privileges based on users. UAC changes privileges based on integrity level. SELinux's main component is its MAC implementation so while Vista's security model isn't exactly equivalent, claiming that they are nothing alike is just not true. UAC is just the graphic interface to Vista's MAC. Sudo is an interface to the standard UNIX DAC model. I would say UAC has more in common with SELinux's security model than sudo. They may look like they the do something similar outwardly (privelege escalation) but the privelege escalation method is very different.

Queue Microsoft Trolls in

[Cryolithic]

3 2 1

Re:Queue Microsoft Trolls in

[Svartalf]

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

[SerpentMage]

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

[Anonymous Coward]

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

[h4rr4r]

So how many of those conficker bots are alternate OSes?

Re:Queue Microsoft Trolls in

[DrLov3]

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

[Roger W Moore]

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

[Anonymous Coward]

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

Re:Queue Microsoft Trolls in

[Anonymous Coward]

Microsoft has Trolls?

Really?

Re:Queue Microsoft Trolls in

[grub]

"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

[Anonymous Coward]

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

Re:Queue Microsoft Trolls in

[zx-15]

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.

Re:Queue Microsoft Trolls in

[blackfrancis75]

..In that sense, you mean *Cue* Microsoft trolls

Re:Queue Microsoft Trolls in

[repvik]

which there's an exploit in the wild under Linux that gets around much of the security in the system.
It requires root access. I'd say that requires a lot of work and skill to get under Linux.

Re:Queue Microsoft Trolls in

[PitaBred]

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.

Re:Queue Microsoft Trolls in

[mr_mischief]

Considering this requires you to already be root ("Administrator" in Windows talk), I'm not sure how low-hanging I'd call it. If someone's your system's administrator, they can probably do all sorts of easier and nastier things.

Re:Queue Microsoft Trolls in

[mr_mischief]

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.

Re:Queue Microsoft Trolls in

[Anonymous Coward]

Until one talented hacker gets the hack to work and then sells it to someone who integrates it into a worm...

Re:Queue Microsoft Trolls in

[Tubal-Cain]

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?

Re:Queue Microsoft Trolls in

[Tubal-Cain]

...we're still ok because we have security through obscurity.

Because that argument works so well for closed-source software.

I assume you were going for Funny rather than Interesting.

Re:Queue Microsoft Trolls in

[Qzukk]

can't reboot into single-user mode?

Password protect your bios and disable external device booting, disable editing in the bootloader (both grub and lilo have a password setting that allows unattended booting but blocks manual interaction), and disable the "hold down whatever to enter single user mode" option some distributions have as part of init.

Re:Queue Microsoft Trolls in

[stevied]

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?

Re:Queue Microsoft Trolls in

[RichardJenkins]

This requires root access to the system. If a malicious application is capable of running as root it has already worked it's way into the most secure level of your OS.

Perhaps someone who understands the technicalities better could correct me, but this doesn't seem like a security problem with the OS.

Re:Queue Microsoft Trolls in

[overlordofmu]

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.

Re:Queue Microsoft Trolls in

[Anonymous Coward]

Indeed, can't a root user install a root kit anyway?? making this a (pointless) exercise?

Re:Queue Microsoft Trolls in

[CajunArson]

And lock the case so the cracker can't reset the CMOS by disconnecting the internal battery....

Re:Queue Microsoft Trolls in

[anss123]

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.

Re:Queue Microsoft Trolls in

[KZigurs]

root is often not good enough in enviroments that actually monitor for rootkits. Now dynamic monitoring of RAM contents of every machine you have in your server room is a bit more of a challenge than regulary bringing down a mirrored VM to checksum system files.

I still prefer the good old shadow machine on the network that simply dumps all network traffic and triggers on non-whitelisted connections. But even that will fail if someone is determined enough to compromise upstream router and just appear to be coming from microsoft update servers.

Re:Queue Microsoft Trolls in

[Qzukk]

Actually, that's a pretty good one too. If you put enough work into it you can (say, with LUKS) pull off something where a passphrase is memorized as an emergency backup key, and a separate key comes from the TPM module on the motherboard. The boot setup would try to use the TPM key by default for unattended booting but if someone tries to wipe the BIOS to get around the boot settings, you could still use the emergency key to get in.

Re:Queue Microsoft Trolls in

[JesseMcDonald]

Most modern distros require you to enter the root password before giving you a root shell in single-user mode. A more realistic attack would be editing the kernel command-line parameters in the bootloader to run a shell directly (init=/bin/sh), or booting from removable media. Those have been known issues for a long time now, however, and anyone interested in local security will have disabled alternate boot devices and set passwords on both the BIOS and the bootloader.

Of course, anyone with unmonitored physical access to the machine can reset, or even replace, the BIOS, and thus do pretty much whatever they want.

Re:Queue Microsoft Trolls in

[Ralish]

I don't think it's the issue of Windows being more secure, rather of Linux exposing more of underlying hardware.

I'm not sure this is strictly true, but rather, the mechanism with which the OS exposes the underlying hardware.

Whereas Linux often exposes technical hardware functionality and information in user-mode and quite possibly through the file-system, Windows is more likely to expose it through things like the Object Manager (think /dev) and WMI (think /proc) in user-mode, while some functionality that can be accessed through user-mode as root in Linux can only be accessed via kernel mode (quite probably more secure, but also quite possibly at the cost of usability, pissing off people who have a legitimate reason to need to access such functionality easily from user-mode).

Even the most powerful features exposed in the Linux filesystem can generally be found somewhere on Windows. A dual example: there is a NT equivalent of /dev/kmem, you can find it in the Object Manager under \Device\PhysicalMemory. In (some?) x86 versions of Windows, you could actually modify its permissions to enable direct read/write to a region of Physical Memory, though it can now only be accessed via kernel mode in x64 Windows. Both more obscure and in this case probably more secure.

I guess what I'm getting at is the difference in how the functionality is exposed, with Linux tending to be more "up-front" and expose the functionality out in the open, while much of it in Windows is hidden away, where you can only find it if you know what you're looking for.

Re:Queue Microsoft Trolls in

[Roger W Moore]

What, the cracker can't reboot into single-user mode?

You can do things to make that hard - although I'll admit that most do not. However Linux boxes are frequently (even predominantly?) accessed remotely and are not always located somewhere physically accessible (those in our server room for example). Windows boxes are almost always physically accessible because it is hard to use them remotely.

Re:Queue Microsoft Trolls in

[thePowerOfGrayskull]

...in the wild under Linux that gets around much of the security in the system.

Well... kind of. It doesn't get around anything unless you are root - in which case you can do whatever you want anyway. It sounds like a non-issue in that context, to me.

Re:Queue Microsoft Trolls in

[Penguinisto]

Since most distros (at least the ones worth a damn) require the root password to do single-user mode?

Nah, you're better off rebooting from a geek stick or live cd at that point so you can mount the disk and modify /etc/shadow on it...

/P

Re:Queue Microsoft Trolls in

[dudpixel]

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?

um, no, unless they're in my house - which then means they could do a lot worse than hack my computer...

Re:Queue Microsoft Trolls in

[dudpixel]

if they've managed to get root access in the first place, you're already screwed.

Put it another way, if a hacker already has root access, and yet feels that they need to use a bug in an intel motherboard to install a botnet, then they're officially an idiot.

Why not just install the botnet code straight into the init scripts?

In other news, if you own a XYZ car and someone steals it, they can change the locks so that they can steal it again later. Actually they can do this to any stolen car, but on XYZ cars its easy to change locks once inside. ?!
Therefore do not buy or drive a XYZ car because if it gets stolen, it might get...stolen...again.

Re:Queue Microsoft Trolls in

[Anonymous Coward]

Fail: http://it.slashdot.org/comments.pl?sid=1208163&cid=27678901

Re:Queue Microsoft Trolls in

[GermanG]

If the cracker is sitting in front of your server, you're lost. Period.

Re:Queue Microsoft Trolls in

[Have Brain Will Rent]

And what if your nice secure Linux box is hosting a Windows VM to run that one piece of legacy code you just have to run? Can the Windows guest be rooted and then take over the Linux host?

Re:Queue Microsoft Trolls in

[fractoid]

In my (admittedly somewhat brief) experience as a sysadmin, Win2K boxes are just as easy to use remotely as Linux ones are. If the machine breaks you'll need to see it physically, otherwise you use a remote session (whether that be a command prompt, X session or Remote Desktop connection).

Re:Queue Microsoft Trolls in

[ProfessionalCookie]

Hehe- the trick is that you don't have it either.

Re:Queue Microsoft Trolls in

[jonaskoelker]

Actually hackers have much more experience with Win 32 systems than Linux.

So, you're saying that to deploy this attack on a Linux system, there'd be a large retraining cost?

Re:Queue Microsoft Trolls in

[Rockoon]

I keep hearing people explain (or at least hinting at) that signing is some sort of system security measure.

What are you going to do? Spend a lot of money tracking down some guy in Nigeria because some malware is signed by a Nigerian Prince? Of course not!

What signing does allow is for an easy-to-trigger "OFF Switch" from Redmond through its monthly updates.
Signing is about control. This control might be used in a way that seems to bolster security, for example if a program is signed by MalWareInc then Redmond might decide to block MalWareInc signatures. On the other hand, they can also decide to block AvoidDrmInc signatures, or SpoofWindowsGenuineAdvantage signatures.

Thats control, not security.

Re:Queue Microsoft Trolls in

[Hal_Porter]

Those locks on PC's are supposed to stop coworkers from 'borrowing' expansion cards not crackers. If someone who really wanted to get into a machine had it, they'd just pick or break the lock.

That's why people say that if you have physical access it is always possible to pwn the machine.

Re:Queue Microsoft Trolls in

[Hal_Porter]

On the other hand, if the hacker has your laptop but you use full disk encryption, you're probably in the clear.

Re:Queue Microsoft Trolls in

[anss123]

True, Microsoft can use it as an off switch but if Microsoft decides to be asshats they can do so by other means as well. Also while someone in Nigeria can sign their malware it is not so easy for Joe Stark in Canada.

IOW, it's just part of the "defense in depth" strategy Microsoft swears to right now. Another barrier for malware authors to overcome.

Re:Queue Microsoft Trolls in

[Rockoon]

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

Re:Queue Microsoft Trolls in

[Anonymous Coward]

No, for two reasons. 1. He would need root to do that. And 2, the network isn't enabled in single user, so even if he manages to do so, he won't be able to access the machine.

So, either way, he would have to already have "pwned" the machine.

(Note: Physical access = pwned).

Re:Queue Microsoft Trolls in

[anss123]

A malware author could bundle his malware with Atsiv, making the protection moot, so it and simple boot.ini edits had to go. Even so it's still possible to exploit holes in signed drivers or disable driver signing by altering the OS files, so it's by no means a perfect form of protection.

Not being able to load an unsigned driver is highly annoying of course, very legitimate complaint.

your favorite intrusive copy protection rootkit such as TAGES or SecuROM will be signed

Of course, but if they are found to do anything illegal they can be held accountable - unless they flee to Nigeria :-)

This screams "control" as well as propping up a few specific players in the emerging industry of "signing."

As long as there are legitimate alternative products I don't see the problem. It's a product feature that you may or may not like. Though, it remains to be seen if this and other features will stop the prevalence of malware on the Windows platform.

Re:Queue Microsoft Trolls in

[Rockoon]

Of course, but if they are found to do anything illegal they can be held accountable

Whats this about illegal things? I thought this was supposed to be a security feature, not an illegal software tracking feature. Are you suggesting that by "security" they mean "national security" or something? I don't get it.

Don't worry.. on previous occasions where I pointed out to someone that the requirement of digital signing wasnt a security feature, they also tried to move the goal post in bizarre hard to understand ways.

I realize that you see things differently.

If you would be so kind as to explain, in plain english, how the signing requirement is a security feature.. I am all ears.

(if you cannot explain it clearly, then that tells me something)

Re:Queue Microsoft Trolls in

[anss123]

If you would be so kind as to explain, in plain english, how the signing requirement is a security feature.. I am all ears.

It's not a security feature in that sense that it can't be worked around. A criminal can get his code signed or find some other workaround, but it is an additional hassle for them to handle. In a defense in depth strategy a security feature does not have to be foolproof, understand?

Whats this about illegal things? I thought this was supposed to be a security feature, not an illegal software tracking feature. Are you suggesting that by "security" they mean "national security" or something? I don't get it.

No I'm not suggesting that by "security" they mean "national security", nor that it tracks illegal software.

In case of SecuROM they are an entity that can be held accountable for what their code do to your computer. That's in not unique to Windows or a security feature of the operation system itself. Preventing unsigned code from running will not prevent SecuROM from making signed malware, they can still do that. This is not generally a problem though due to the point above: They can be held accountable for their actions.

Preventing unsigned code from potentially unknown vendors from running is the feature. It may not be a feature you care for, or even improve security in your usage scenarios, but for some/many users not being able to install rootkits are a feature they will welcome (and if they don't Microsoft risks loosing a sale).

Re:Queue Microsoft Trolls in

[dave420]

But it means any virtual machine running on your system gets root privilege on the host running the VMs.

Re:Queue Microsoft Trolls in

[owlstead]

"I'd think that root can access EVERYTHING incredibly easily. Isn't that kind of the whole point of root? "

I don't know. In many cases I just want to be able to install applications, not have access to each and everything in the OS, let alone have direct access to hardware.

For many administrative tasks, you should not have to use root. It's good that you can have full access, but only in extreme cases.

Re:Queue Microsoft Trolls in

[belphegore]

Steps to reproduce at no effort:

1. Go to any hosting provider which uses VMs (let's say Amazon EC2).
2. Sign up for new account, get your root access on your own VM instance on the shared host.
3. Execute exploit; take control of any other VM on the same physical hardware as you.

There, that wasn't so hard now, was it?

Re:Queue Microsoft Trolls in

[Roger W Moore]

They are only "just as easy" after you have spent considerable effort installing additional software to make it "just as easy".

Re:Queue Microsoft Trolls in

[fractoid]

What software are you talking about? Remote Desktop comes as part of XP and later, and even if it didn't, 5 minutes to download and install RealVNC is hardly "considerable effort". Once you have a remote window session it's as good as being at the console, unless you have to do hardware stuff (reboots, plugging devices in, etc) which require physical presence regardless of OS.

I'll concede that over very low bandwidth lines, Linux has a large advantage because it's designed to be administered from the command prompt. Over an office intranet? Not so much.

Re:Queue Microsoft Trolls in

[dvhh]

mandatory xkcd http://xkcd.com/538/

Re:Queue Microsoft Trolls in

[Roger W Moore]

VNC? That would be a heck of a lot of clicking if I need to submit 300 batch jobs to analyse data. I'm talking about large clusters of machines that are stored in a secure room and which are used for analysis. These machines are ONLY accessible remotely. Using VNC to remotely manage desktop machines does not count because, by their very nature, desktop machines sit on someone's desk and are easily accessible. My point is that a large number of Linux machines are not physically accessible at all because they are not desktops.

Re:Queue Microsoft Trolls in

[Rockoon]

It's not a security feature in that sense that it can't be worked around. A criminal can get his code signed or find some other workaround, but it is an additional hassle for them to handle. In a defense in depth strategy a security feature does not have to be foolproof, understand?

No, I don't understand. The idea that security features don't need to be foolproof is just noise to me (noise in the context of my query, even though it is true), since it has not been shown that this signing requirement is a security feature.

Can you just describe how it is a security feature, without jumping to another topic?

Re:Queue Microsoft Trolls in

[anss123]

Can you just describe how it is a security feature, without jumping to another topic?.

1. User wants to install a program. 2. Program has a Trojan. 3. Trojan needs to load into the kernel. 4. Trojan is not loaded since it's not signed.

No current security feature in use is absolutely 100% foolproof. Requiring code to be signed handles two common attack vectors: One is unsigned code hidden in programs the user might trust (like Firefox), the other is exploiting flaws in applications or the OS that lets you execute unsigned code.

If the attacker goes to the trouble of signing his code then the signature can be revoked.

Re:Queue Microsoft Trolls in

[PitaBred]

If you do system-level stuff, you need a system-level user. The problem is that changing those applications directly affects the security of the root user, so you either run it as root, or you don't. Most (all?) applications in Linux will allow you to install them as a normal user. Just run them from your home directory or somewhere you have normal user access. I personally allow all users to have full access to /opt and install any non-distro software there.

Re:Queue Microsoft Trolls in

[Rockoon]

Trojans do not require ring0. Viruses do not require ring0. Both of these things simply require elevated privleges.. and get them via UAC prompt.

Please invoke only something that requires ring0 in your arguement that required signing for ring0 is a security feature.

Maybe somewhere within the Google search for 'x64 Required Signing Proven Effective'

surely there is a SINGLE example.. right?

Re:Queue Microsoft Trolls in

[anss123]

surely there is a SINGLE example.. right?

Uhhh... like this very article we're posting too? Where they need ring0 access to inject code into an area of memory reserved for SMM (which is why they said the exploit was easier on Linux as one could use an API call instead).

I can't personally name any trojans that need ring0 access, but rootkits (which is the usual payload of a trojan these days) desire ring0 access so that they can inject code somewhere a virus scanner can't/won't find it. One of the recent trojans/worms/"whatever it was called" failed to infect XP 64-bit since it injected 32-bit code into the kernel.

Re:Queue Microsoft Trolls in

[Rockoon]

I don't understand. Even if 64-bit Vista allowed unsigned drivers, I would still get a UAC elevation notice before it could install.

TFA of course is interesting, but has nothing to do with driver signing. Any code with the privileges to do what the article discusses, doesn't need to. Admin is enough to take over a vista box, and you gave the installer admin privs via UAC long before you were informed about an unecessary unsigned driver.

Yeah, admin can't install an unsigned driver.. umm.. so? The only reason to be in ring0 is to directly interface with hardware, or to enforce or circumvent DRM.

I don't think you understand what actualy needs ring0. It aint rootkits. It aint malware. It aint viruses.

Consider the following. I can sign my own driver using a local test certificate, boot up windows, and it will faithfully load said driver into ring0. But when I do so the windows Protected Media Path is disabled.

There is a penalty for not using a verisign signed driver, and its intentionally broken high def media. Atsiv avoided this penalty, and THAT is what it was all about. It had nothing to do with 'security.'

Re:Queue Microsoft Trolls in

[anss123]

I would still get a UAC elevation notice before it could install.

True, but users will click yes on such boxes. Not you, but some will.

I don't think you understand what actualy needs ring0. It aint rootkits. It aint malware. It aint viruses.

A rootkit can be quite annoying without using ring0, but there's a whole industry built around making rootkits. Those rootkits do hide in ring0 simply because it makes them harder to detect and remove. By taking measures such as mandatory signing one can (we've yet to find out of course) limit the success of these rootkits.

Keep in mind though that rootkits can still get into the kernel through a vulnerability and a rootkit does not need to hide if a user/system makes no attempt at detecting/removing them.

Consider the following. I can sign my own driver using a local test certificate, boot up windows, and it will faithfully load said driver into ring0. But when I do so the windows Protected Media Path is disabled.

The Protected Media Path is not something I'm familiar with, but I believe it's also disabled on x32 when loading unsigned drivers. This is a requirement for legally playing back "protected content". So no debuggers, unsigned drivers, etc, is allowed when using "protected content". The alternative is the inability to play back "protected content", legally.

I'll happily agree that it's stupid, but as long as Joe Average is satisfied with his locked down Blue Ray player connected with encrypted HDMI to a big screen telly, there's little to be done. Hopefully Blue Ray will die, tellys connects to computers by default and DRM free movies come to dl services.

First you need root on the box

[h4rr4r]

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

[Lord Ender]

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

[victim]

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

[to6o]

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

[blueg3]

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

[Anthony Liguori]

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

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

Re:First you need root on the box

[h4rr4r]

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

[LoRdTAW]

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

[Lord Ender]

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

Re:First you need root on the box

[lucag]

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

[JCSoRocks]

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

Re:First you need root on the box

[Anonymous Coward]

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

[should_be_linear]

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

[dsg123456789]

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.

Re:First you need root on the box

[amicusNYCL]

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

[bluefoxlucid]

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

[mce]

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

[OrangeTide]

or poke the MTRR...

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

[nedlohs]

Or not if the GP post was false.

Re:First you need root on the box

[dave562]

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

[tisepti]

The wooosh vulnerability? I cant find info about this one anywhere - how do i secure against it?

Re:First you need root on the box

[TeknoHog]

just do it

Re:First you need root on the box

[snaz555]

With this technique you can cross-infect VMs and rootkit the hypervisor. That's a much bigger problem than simply rolling back a VM to a clean snapshot.

Re:First you need root on the box

[Seth Kriticos]

True. This vulnerability is interesting when it comest to IDS observed systems. These normally don't tend to be normal user desktop systems, but high sec systems. Of course these systems will also check outbound traffic, binary hashes and running processes. I'd also doubt that this kind of machines will harbor a consumer motherboard, even if it is a high end one. For all potential users of this peace of equipment it does not make much difference, as it requires root privileges in the first place and that mostly owns most desktops anyway. For windows machines this probably will be a bigger problems as they have their own set of privilege escalation issues, so objectively the tone of voice of the article is misplaced.

Re:First you need root on the box

[mr_mischief]

So replace the motherboard as well, since that's the vulnerable and compromised component. You might even ask for a refund or replacement, as this is a design defect.

Re:First you need root on the box

[_avs_007]

You would think if all you wanted to do was remain hidden, there are easier ways that aren't so platform specific... If you have root access, a rootkit only needs to use Intel-VT or AMD-V and virtualize memory, such that the OS is no longer reading physical memory, but reading virtualized memory, such that it can't find the rootkit... Essentially all the rootkit needs to do is just blindly pass memory read/write operations, except for those addresses where the rootkit lives... There, it just passes back random garbage/null/etc.

Re:First you need root on the box

[Theolojin]

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.

If you have root why in the world would you need to plant a root kit?

Re:First you need root on the box

[steelfood]

Better question:

Does your machine come from Dell or HP or any other major vendor?

Re:First you need root on the box

[rbrausse]

you could add something like "127.0.0.1 slashdot.org" to your hosts-file.

not a complete solution but ~80% of all whoosh attackers are blocked :)

Re:First you need root on the box

[h4rr4r]

No, it just means if they already have physical access this is the least of your worries.

Re:First you need root on the box

[h4rr4r]

If you can boot from a pendrive you can take out the hard drive and do what you want with it, so credentials really don't matter.

Re:First you need root on the box

[blueg3]

If only there was a Wikipedia page that explained what a rootkit is and why malware would use one!

Re:First you need root on the box

[phantomfive]

It's a way to get your exploit out of a virtual machine. So if you are used to running dodgy software in a virtual machine so you don't get infected, you might get infected anyway. I expect if this technique is in the wild (and there's no reason to believe it's not), it's mainly used in targeted attacks, not in broad based phishing attacks. But that's not something I'd depend on.

Re:First you need root on the box

[pentalive]

It is true "No security without physical security". If I have access to your Linux keyboard, I can reboot the machine and come up in single user mode.

Re:First you need root on the box

[RiotingPacifist]

Can immutability be used to prevent this attack then? Or is setting +i on /proc/mtrr impossible?

I think that if you put "lcap CAP_LINUX_IMMUTABLE" in you're default runlevel startup scripts, even root can't screw up you system short of using direct disc access and i think there is an lcap for that too.

Re:First you need root on the box

[Bert64]

You could use a trojan flash bios too, or trojanise any piece of hardware that has upgradeable firmware...

Re:First you need root on the box

[noidentity]

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.

Rebooting doesn't usually cause the hardware to clear memory, so if the OS doesn't clear said memory, it DOES persist across reboots.

Re:First you need root on the box

[textstring]

Wouldn't flashing the BIOS recover the original SMM memory?

Re:First you need root on the box

[Gordo_1]

Not necessarily. There are social engineering attacks that involve USB storage devices without requiring the attacker to have physical access. Use your imagination to fill in the blanks.

Re:First you need root on the box

[AVee]

Linux is perfectly capable of asking for a root password in single-user mode (the default in sensible distibutions).
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

[SLi]

That's just presumptuous. There are different levels of physical access. I could insert a pen drive on a computer on my university. I hardly could boot from it (need bios password), but I certainly could not take out the hard drive without using a crowbar and getting caught in a security camera.

Not that I think this vulnerability is that big an issue, except for the virtualization part. If your machine is rooted, it's rooted. Don't pretend you can fix it by running some antivirus stuff.

Re:First you need root on the box

[LoRdTAW]

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

[EvanED]

Because destroying systems became passe a long time ago, and botnets are now very profitable?

(And if you want to run a good botnet, it needs to go undetected -- aka, be a rootkit.)

Re:First you need root on the box

[Brianwa]

I wouldn't be quite so confident in the hosting company - I've seen all sorts of interesting applications running on old desktops in a closet somewhere.

Re:First you need root on the box

[Anonymous Coward]

if you have physical access you can just root the box in the 1st place.. far less effort involved.

Re:First you need root on the box

[KZigurs]

yes.
And let's forget the DQ35 - it is rather unlikely that Intel would have done something specific for any particular board. Chipsets generally follow same core logic, just with different 'peripheral' configuration. Attack _might_ be specific to the board configuration, but the underlying logic is rather likely to be present in the supposedly validated, tested and signed off 'reusable part' that is copy-pasted into any subsequent 'solutions'.

Re:First you need root on the box

[Anonymous Coward]

ROFL(sorry)! Now where are *my* mod points?

Re:First you need root on the box

[sphealey]

> I read the PDF of the exploit and from what it states the code...

I hope you checked your system for rootkits after reading a PDF.

sPh

Wish I were joking...

Re:First you need root on the box

[martin-boundary]

Doesn't an antivirus usually run as root anyway? If it does, why can't it preemptively clear the cache memory in the same way that the exploit does?

Re:First you need root on the box

[gzipped_tar]

setting +i on the proc filesystem is indeed impossible.

Re:First you need root on the box

[Anonymous Coward]

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.

Yes, but with your code in SMM memory you can get write access to the bios, which is persistent. Write Enabling the bios causes an interrupt that puts you in SMM. Which if you don't have control of SMM memory means you gotta play by the rules of whatever code is there.

Re:First you need root on the box

[philipgar]

This WILL NOT survive a reinstall of the system. It does NOT overwrite your bios. It overwrites values in cache. However, when you reboot the machine, the cache is cleared so any code must be reloaded into the cache to be exploitable. What this does do is makes the attacking program undetectable from the running OS.

Phil

Re:First you need root on the box

[julesh]

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

I have to say, this is the first time I've ever seen a "why don't I have mod points?" post modded +5 funny.

Why don't _I_ have mod points?

(Oh, yeah, that'd be something to do with modding an editor offtopic.)

Re:First you need root on the box

[julesh]

Replacing the kernel tends to trigger systems designed to catch intrusions, as it's painfully obvious

Not if your modified kernel redirects requests to a copy of the old kernel whenever an application tries to probe it. OK, this can be detected by booting from a LiveCD to run a scan, but how many people do that on a regular basis?

Come to think of it, what proportion of Linux users regularly run any kind of rootkit detection system? I'll bet it's _significantly_ lower than the proportion of Windows users who do the same, which is worrying, as we are in fact just as vulnerable.

Re:First you need root on the box

[Lord Pillage]

I'd give you mine if I could. My machine at work is using IE6 which seems to have problems with the ajax on the mod drop downs. Too bad really, cause I spend so much time here reading /..

Re:First you need root on the box

[element-o.p.]

Interesting concept. About a decade ago, I used to work at an aircraft maintenance shop. Every mechanic there owned their own toolbox, maintained their own tools, and if they left one company to work for another, they took their tools and toolbox with them.

In light of this vulnerability, is the day coming when owning and maintaining your own PC "toolbox" will be required as well?

Re:First you need root on the box

[BitZtream]

How exactly is this going to survive a reinstall? The cache is cleared on processor reset.

You'd need to infect the BIOS to survive a reboot if you booted of uninfected media afterwords.

If you boot off the same infected media after reboot, then the Stoned virus will still be there as well.

Re:First you need root on the box

[nedlohs]

I wouldn't think so, it's not that uncommon for companies to have policies that company data is not to be put on non-company computers.

And everyone having different hardware would be a nightmare for IT to deal with.

Re:First you need root on the box

[element-o.p.]

That's kind of the point though -- IT *doesn't* deal with it. IT is pure overhead, so get rid of desktop support, and make IT responsible only for the network and servers. Make technical people (IT itself, engineers, etc.) responsible for their own equipment. You own it, you secure it, you fix it if it breaks. You get to choose the tool you use to get your job done (Windows, Mac, Linux, etc.) If you can't get your job done with the tools you selected, you're out of a job. If your security (or lack thereof) causes a data breach, you're responsible.

If we are reaching a point where even wiping a computer can't guarantee that it's free of malware, then perhaps it's time to rethink how companies deploy and maintain computers.

"Exploit" implies there was an actual hole

[amorsen]

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

[piojo]

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

Re:"Exploit" implies there was an actual hole

[pentalive]

Before you sudo, when the script runs sudo won't it ask for a password?

Re:"Exploit" implies there was an actual hole

[EvanED]

Actually this is a good question... I'm not actually sure if this would work or not.

I can't imagine it would be at all difficult to run sudo in such a way as the user wouldn't see the password prompt. If running sudo once and entering the password saves it for future sessions, then the saved password *could* be available to the script unless it's smart enough to check the process hierarchy or something like that. /me goes to try this idea out

Re:"Exploit" implies there was an actual hole

[DaleGlass]

That can work, assuming that:

1. The daemon runs as an user with access to sudo (exploiting the apache account won't do)
2. sudo authorization is system-wide (not true on many distros)
3. The sudo config doesn't require it to run on a tty (actual daemons don't have one)

So in theory it's doable, in practice it won't work that well on decently configured systems. For instance, in Ubuntu sudo authorization is per console. For it to work well you'd have to trick the user to start the program on the same terminal sudo will be run on.

Further difficulties can be added with for example the grsecurity patch, making the user unable to execute programs from non-root owned directories.

Re:"Exploit" implies there was an actual hole

[Maexxus]

Sick, it does work:
while true; do sudo -n whoami; sleep 60; done

At first it returns:
sudo: sorry, a password is required to run sudo

But after using sudo from another terminal it returns:
root

Re:"Exploit" implies there was an actual hole

[Maexxus]

I should point out that -n disables password prompting, and this was testing using the same user, so I'm not sure if this is actually what you meant.

Re:"Exploit" implies there was an actual hole

[petermgreen]

actual daemons don't have one
But on most linux systems any process that wants to can get a pty/tty pair through the use of /dev/ptmx .

Re:"Exploit" implies there was an actual hole

[SinShiva]

i think you need a closer look at /etc/sudoers

Re:"Exploit" implies there was an actual hole

[cbiltcliffe]

So the exploit sits and monitors for a process called sudo, su, gksu, or whatever.

When it sees it, it waits 30 seconds, then starts its loop.

Wait, don't you mean easy on windoze...

[krovisser]

oh noesss my linux!

you got root

[Dionysus]

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

[swimin]

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

Re:you got root

[lukas84]

Then again it's depending on the mainboard, which is IMO even worse..

Article Is Bunkum

[Anonymous Coward]

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

Re:Article Is Bunkum

[nicolas.kassis]

root is god thus root can do it

Re:Article Is Bunkum

[Anonymous Coward]

root is not god. root is owned by god.

Don't you read bash.org?

Re:Article Is Bunkum

[RiotingPacifist]

but can root, make a file he himself can't (re)move?
The answer ofc is yes
.'. root > god
QED

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

I'd say it's pretty fortunate, actually

[mr_mischief]

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

[Anonymous Coward]

I can do something on my computer with root.

Shit.

Re:It requires root privileges and is hw limited .

[SatanicPuppy]

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.

The point?

[srealm]

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

[LanMan04]

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?

[Anonymous Coward]

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?

[Deanalator]

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:The point?

[srealm]

Re-read my comment. I said if you already have root access, INSTALL a root kit with root access so you can return later.

This security exploit REQUIRES root access to GET root access to install a rootkit. It's moronic.

Re:The point?

[inviolet]

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.

The point is virtual servers, in which this code in one infected VM can reach up into the hypervisor and then down into the other VMs.

Re:The point?

[dedazo]

Stupidest exploit scare ever.

What about ISPs that provide shell accounts or rely on virtualized Linux instances? Would this affect them?

Re:The point?

[KZigurs]

You are missing the big point here - escalating above any virtualization layers. And that is a VERY BIG deal in enviroments where you are talking about server farms, thousands of hosted "secure and isolated" VMs and root access to your supposedly isolated machine.

Re:The point?

[Anonymous Coward]

What an idiot. This breaks sandboxing and virtual machines. Think outside the box.

Re:The point?

[omglolbah]

Say we have the following PHYSICAL machines in the server rack:

[VM-Host 1]

You rent space in a virtual machine on VM-HOST1.
This virtual machine is named [srealm.VM].

Some other bloke rents himself a virtual machine that the service provider just happens to put on the same PHYSICAL machine as yours.. This new is called [somebloke.VM].

You have root on your own virtual machine [srealm.VM] and run this exploit. Using this exploit you can then with a bit of skill inject some pesky stuff into the [somebloke.VM] virtual machine that lets you log into his machine using SSH(or similar).

See the issue here?

The hosting provider thought they separated you two by running your machines as virtual machines. Without this new class of exploit the two virtual machines are not aware of each other and function like any other physical machine (mostly).

WITH this exploit on the other hand you (or him!) could use this exploit to gain privileges on the other person's virtual machine. You BOTH have root on your respective virtual machines but not on the other person's virtual machine.

-that- is the significance of this exploit. The breach of the VM layer.

Re:The point?

[julesh]

Say we have the following PHYSICAL machines in the server rack:

[VM-Host 1]

You rent space in a virtual machine on VM-HOST1.
This virtual machine is named [srealm.VM].

Who on earth is going to base their rack-mounted server on a micro-ATX motherboard designed for low-end workstations?

Re:The point?

[omglolbah]

That is missing the point entirely. It was used as an example of how the hack works, not on what is logical to use in a server farm.

Finally!

[Cornwallis]

2009 will be the Year of the Windows Desktop!

Re:Finally!

[shutdown -p now]

2009 will be the Year of the Windows Desktop!

No, it will be the Year of Linux Botnet. ~

(or maybe it should really be the year of Cross-Platform Botnet, since the vuln. in TFA is platform-agnostic)

Re:Finally!

[linzeal]

Some sort of chimeric Linux, Windows and Mac botnet. Would hate to be the one who has to sit down and give it a clever name.

Re:Finally!

[Frank T. Lofaro Jr.]

SkyNet

Re:It requires root privileges and is hw limited .

[Creepy Crawler]

You fail.

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

At the risk of causing a war...

[Bobfrankly1]

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

Re:At the risk of causing a war...

[ITJC68]

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

[Bobfrankly1]

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.

Re:At the risk of causing a war...

[yahwotqa]

Huh? People have been writing exploits for Linux for years.

Or have I just been whooshed?

Re:At the risk of causing a war...

[Bobfrankly1]

Naaa, I think I whooshed myself trying to make sense of ITJC68's comment. Time to change my pants...

Re:At the risk of causing a war...

[BitZtream]

Actually, Linux still isn't a big enough target for 'the bad hackers' to care.

What you are seeing are people who having been laughing at all the 'I run Linux so I'm secure!' fanboys, so they've decided to start showing you just how secure you aren't to prove a point.

They get more publicity now by showing this on Linux as doing things to Windows is so old that Jesus even stopped bothering with it.

After a while, OpenBSD will be the next target for this sort of thing, and they'll do it just as easy once they decide that its more fun to take that route.

Overhyped old news.

[jdong]

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

[rs232]

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:

[..]

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

[Anonymous Coward]

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.

[eblum]

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.

[MrDelSarto]

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.

[TheCycoONE]

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.

[eblum]

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.

[kc8apf]

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.

Re:Compiler fault.

[eblum]

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.

[howlingmadhowie]

no. root should be able to do anything. that's one of the guiding principles of free software--you have total access to your own computer.

Ok, easy on Linux

[SnarfQuest]

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

[Runaway1956]

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.

Re:It requires root privileges and is hw limited .

[Anonymous Coward]

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!

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.

Hell has frozen over

[theorem4]

Could it be that Windows is actually safer?

Re:Hell has frozen over

[Anonymous Coward]

Could it be that Windows is actually safer?

No.

Re:Hell has frozen over

[not already in use]

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.

Re:Hell has frozen over

[berashith]

This may be true. If linux were to have the same desktop market share, the default install would have to only create a root account, or give enough simplicity that every command assumes a no-password-needed sudo was already typed in. Also, all applications would run as this default root user.

This should create enough simplicity and "just works" to allow everyone's grandmothers to feel fully comfortable that Linux desktops could become amazingly commonplace.

These trade offs of ease for popularity would certainly allow any "hacker" to make swiss cheese of the boxes.

Re:Hell has frozen over

[Abalamahalamatandra]

Uh, no.

When the same percentage of Windows users as Linux users run day-to-day as unprivileged users, I'll start to believe that. Note that annoying UAC prompts that give you no information whatsoever as to what action you're authorizing do not count.

A simple glance at the durations for which MS has refused to acknowledge "game over" vulnerabilities, much less patch them, should easily put the lie to that statement.

Re:Hell has frozen over

[Runaway1956]

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.

I so enjoy these failed exercises in logic. "If Linux" and "If Windows", etc.

The fact is, no one routinely breaks into Linux systems. People DO routinely break into Windows. Just try to get a grip on reality, without the "If" bullshit.

Why do you think that Gates settled on the name "Windows"? He knew that it could be easily broken. Hell, he didn't even need to put in backdoors, just break a window, any window, and you have access to the system.

I invite you to break into my system, since "hackers" can so easily make swiss cheese of it. (I use the term "hackers" very loosely, in keeping with your apparent definition of "hacker") Do you need any help, or can you manage this trivial task alone?

Re:Hell has frozen over

[Tweenk]

If linux were to have the same desktop market share, the default install would have to only create a root account

This is just nonsense. It is not inherently necessary to run as everything as root to conveniently operate a computer. The only programs I run as root are:
1. CLI commands, when I do something advanced
2. Synaptic

Re:Hell has frozen over

[Tweenk]

1. No one will bother doing this specific exploit on a desktop computer.
2. I didn't hear about any massive pwnages of Linux servers due to an exploit, so your claim is at least disputable.
3. This is a hardware exploit, not an OS exploit.

Re:Hell has frozen over

[berashith]

I would agree with you . That places us in the 2% share that doesnt find desktop linux cumbersome.

Re:Hell has frozen over

[not already in use]

Note that annoying UAC prompts that give you no information whatsoever as to what action you're authorizing do not count.

UAC is different from sudo how? Oh yeah, it's not, and is required just as much.

SMM buried rootkits

[rs232]

"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:SMM buried rootkits

[Anonymous Coward]

The second part of your question appears to be the key. Another comment suggests that, despite the initial suggestions, the rootkit will not survive a reboot AND drive wipe since the SMM is actually normal RAM, not some flashable NVRAM or what have you that would survive a reboot.

If you steal a car ... You can break the motor!

[Anonymous Coward]

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!

[SnarfQuest]

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!

[blueg3]

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.

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

[Culture20]

Your post made me think of a (complicated) method of having an easily usable car available wherever the thief is (if one isn't too choosy as to the make/model). Future Fast & Furious plot fodder, perchance?

"Okay, my tracking database says there's a Porsche two blocks south, and the driver never leaves work until 5PM."
"So we'll have four hours until he notices..."
"No, we'll have four hours to get it back, with as little mileage as we can put on it. I want to keep this car available."

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

[myowntrueself]

This is a rootkit -- which is like deciding what to do with the car after you've stolen it.

This is worse; its more like modifying the cars chassis so that regardless of whatever anyone does with the car to try to re-secure it after you have done this you can walk up to the car and drive it away.

Locks, alarms etc are all useless. Replacing the engine or car electronics won't help. You'd have to replace the entire chassis assembly.

tux is innocent

[meushi]

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

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:This is an exploit for virtual servers

[Anonymous Coward]

Thats nonsense, the exploit requires access to the MTRR registers, and no sane virtualization environment would let its guests touch those registers in the real CPU.

Re:This is an exploit for virtual servers

[mr_mischief]

If you run a virtual server farm, please don't run it on desktop motherboards with cache overflow vulnerabilities. ;-)

Re:This is an exploit for virtual servers

[Shadow-isoHunt]

As many have pointed out, there's no real point to "exploiting" a machine that you already have full (root) access to

Maintaining access?

Re:This is an exploit for virtual servers

[mindhex]

Comment from theinvisiblethings blog: "I doubt this will work from a xen domU or dom0 context because 1) AFAIK you don't have access to MTRR registers from there 2) their kernels are running in ring1 not ring0." Maybe openvz/vserver virtualization restrict access to MTRR somehow too... why you so sure?

Re:This is an exploit for virtual servers

[Runaway1956]

Except that the exploit depends on very specific architecture. http://www.intel.com/products/desktop/motherboards/DQ35JO/DQ35JO-overview.htm

I may be missing something here, but the hardware doesn't appear to be the first choice of people building server farms.

Re:This is an exploit for virtual servers

[BitterOak]

Thats nonsense, the exploit requires access to the MTRR registers, and no sane virtualization environment would let its guests touch those registers in the real CPU.

Does anyone know, for example, if VMWare does?

Re:This is an exploit for virtual servers

[BitterOak]

I may be missing something here, but the hardware doesn't appear to be the first choice of people building server farms.

Yes, but it isn't just people running server farms that use virtualization. Desktop users, including myself, routinely use products like VMWare to run things like Linux under Windows XP, often creating virtual machines when testing potentially "dangerous" software downloaded from the Internet, or visiting websites that may not be fully trusted. Given that new web browser vulnerabilities are being found all the time, I generally do my random web surfing under VMWare, and do serious stuff like banking in a different VM. This exploit means this won't provide the safety it did after all. It is a very serious issue.

This article sets a new bar for "layman's terms"

[viking80]

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.

OpenBSD immune... again.

[Anonymous Coward]

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.

Re:OpenBSD immune... again.

[Anonymous Coward]

and you know that how? It's hardware specific so it's probably in BSD too. Oh you were trolling, I forgot that all BSD users do is look for linux articles to bitch in.

Re:OpenBSD immune... again.

[Anonymous Coward]

hmm, !iopl()?

now fuck off, you ignorant loser.

Meh

[bcat24]

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

Re:Meh

[Anonymous Coward]

Alright, the post is 'flamebait', but it's still insightful nonetheless. In the best case (for MS) the exploiter will have to manage installing an unsigned driver and that's it.
And I bet that someone will appear to let us know that you can't actually write to MTRR without some capability that distros have disabled for years ;)

Yes, but does it...

[dave562]

..run on...

Oh, nevermind.

Take that you penguin loving bitches...

[Anonymous Coward]

C= FTW

MOD this guy up

[taniwha]

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

Re:MOD this guy up

[lukas84]

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.

Yeah? How?

[Weaselmancer]

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

Description for dummies

[gmuslera]

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.

Re:Description for dummies

[dtolman]

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.

Re:Description for dummies

[myowntrueself]

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.

Let me get this straigh...

[Hurricane78]

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

Re:Let me get this straigh...

[Hurricane78]

What the... From +4, insightful to 0, redundant??
Well, how about you being *wrong* about that, because you did *just ignore* the difference, or are to blind to follow it.

Nobody did point it out clearly. They all still thought that there is something like a security hole there. While in reality, there is *none*. root = root = root = root = root. Got it?

Re:It requires root privileges and is hw limited .

[Anonymous Coward]

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.

A root to root exploit ?!

[billcopc]

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

Re:A root to root exploit ?!

[mysidia]

That doesn't work against people like me who practice security protection procedures that look something like...

# echo 'sysctl kernel.cap-bound=-20377' >>/etc/rc.d/rc.sysinit

# ldconfig
# rsync -avl --one-file-system / /backup
# rsync -avl --one-file-system /tmp /backup/tmp
# rsync -avl --one-file-system /var /backup/var
# chattr -R +i /boot /lib /bin /sbin /usr/lib \
/usr/sbin /usr/bin /etc/fstab /etc/inittab \
/etc/rc.d /etc/profile /etc/profile.d \
/root /etc/ld.so.conf /etc/ld.so.conf.d \ /etc/ld.so.cache /home/adminuser1
/home/adminuser2
# sysctl kernel.cap-bound=-20377

Re:A root to root exploit ?!

[Trepidity]

You could use root on a VM to root all other VMs on the system, which is not normally expected. Certainly VPS providers don't expect their customers to be able to root their other customers' boxes.

On the plus side, the working exploit code appears only to be for a desktop board, which is not likely to be used in a lot of security-critical VMs.

Re:Tides have changed

[Locke2005]

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!

The benefit of being outdated

[damn_registrars]

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.

Re:The benefit of being outdated

[chappel]

Wow - You're the one with the last running Windows Me box?

Re:The benefit of being outdated

[cbiltcliffe]

I have a Pentium 1 system running NT4, and a 486SX running WfW3.11, although I haven't used that one for a while.
I've got a pile of Debian Etch machines (latest release is Lenny) and I don't think any of them are faster than 800MHz P3s.

My fastest Linux machine has an 8x4x32 CD-RW in it.

Do I need a padded cell, too?

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

[Urban Garlic]

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:It requires root privileges and is hw limited .

[Anonymous Coward]

Anyone who uses the phrase "you fail" in regular conversation should have their balls cut off so that there won't be a risk of more fucking idiots being born by them. People on the Internet are getting so fucking stupid they're speaking in 4chan memes now. You think anyone actually takes you seriously taking like a fucking 12 year old /b/tard?

Well that's a good thing then

[Weaselmancer]

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

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

[Kz]

most of /proc is either disabled, virtualised or useless in VMs, since they can't really affect the real hardware

Re:Well that's a good thing then

[Anonymous Coward]

Or if you want to use "virtualization" for security purposes, do it the right way: use containers; they do not have their own kernels, only get a very light subset of /proc (no trace of /proc/mtrr on OpenVZ nor on VServer containers, here), and thus, are less vulnerable to this kind of events.

Full virtualization is meant to make the simultaneous use of different kernels possible (and it is totally stupid to use it in other cases: absolute waste of resources). Nothing prevents you from containing things inside each and every virtualized OS that has its own kernel (been there, done that: works perfectly well with qemu and various accelerators; useful at most to virtualize all my servers on a single machine, for testing purposes).

Re:Well that's a good thing then

[JaumPaw]

Better yet, if you're indeed using a virtual machine, just disable CONFIG_MTRR on the kernel.
(Processor type and features -> MTRR support, from menuconfig)

Granted, this will decrease your X windows performance with AGP/PCI cards (that is, with any modern hardware). If you're using virtual machines as a way to host many servers on one iron, this is possibly a non-issue. Though I don't know what effect it has on gigabit ethernet cards, for example. It may be similar.

On desktop machines, like many posters said here, if you're root then you're root, end of story. I don't like the "sudo" approach that doesn't use a password to protect the access - it's just a wide open hole. But some will happily sacrifice ease of use on the expense of security...

Here's what I see

[erroneus]

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.

Re:Here's what I see

[blueg3]

They don't actually claim that it's a Linux vulnerability. It's a chipset vulnerability that happens to be incredibly easy to take advantage of on Linux, since the kernel already provides a convenient interface to the necessary hardware (rather than having to do it the hard way).

Note that TFA doesn't mention Linux. The Microsoft Subnet article does, but that's not too surprising. (Note that the Invisible Things guys primarily release proofs-of-concept for Linux.)

Re:Here's what I see

[Todd Knarr]

Linux makes it "easy" only in the sense that Linux provides a /proc file interface to modify the MTRR registers, while Windows requires you to write a few lines of assembly code to do the same thing. That means that Linux is only an easier target for those kiddies with no clue what C is or how to program in it. If you actually know C programming and assembly language, direct access to the MTRRs via assembly's probably easier than mucking around parsing and modifying what looks like a text file.

Re:It requires root privileges and is hw limited .

[Anonymous Coward]

I was thinking the same thing but then I checked it out. It actually wouldn't be a bad board to use for those purposes. It supports the latest processors, 8 GB RAM, and has 6 SATA connectors. It even has old-school RS-232 serial ports and twelve USB ports(!). It seems this isn't your typical micro-ATX board. Looks like it would be good because it's fairly full-featured while still being really small so you could stuff a whole bunch of them in a little space.

I had never heard of it though. Is this a new board from Intel? Newegg doesn't even carry it.

AMD is that you?

[Anonymous Coward]

./

unfortunate?

[erase]

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

Re:This article sets a new bar for "layman's terms

[tacroy]

Perhaps "layman's terms" doesn't mean what you think it means... I think anything with over 2 acronyms can no longer be considered a layman's description.

Re:It requires root privileges and is hw limited .

[Etcetera]

Anyone running (and *using*) SELinux might disagree with ya there :)

Re:Yeah? How?

[tixxit]

From the article:

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

[tixxit]

^ meant to say the user must be an Administrator (hence why I said ie. like the root access required in Linux), must've deleted it when posting.

Nothing to see here

[bughouse26]

The SMM exploit requires that the attacker already have root. You're already screwed at this point.

Re:Nothing to see here

[myowntrueself]

The SMM exploit requires that the attacker already have root. You're already screwed at this point

Given the nature of the exploit thats pretty naive.

Rootkit hypervisor in re-written bios?

You become aware that the box was rooted and reinstall from scratch, wiping the hard drive completely.

The root kit isn't gone, its in the bios.

Box is still rooted.

Re:Nothing to see here

[bughouse26]

Wiping the drive has never been a sufficient method of clearing a rootkit. BIOS, video card sram, CMOS, etc. type attack vectors for malware/virus have existed for decades. Any piece of hardware with static memory needs to be cleared/reset/reflashed etc. Is there something unique about SMM exploits that prevents a system owner from reflashing their BIOS?

Evil Linux Exploit

[Anonymous Coward]

Evil Linux exploit seizes control of Linux boxen and installs Windows VISTA!

so what?

[asdfndsagse]

Nobody runs root on linux. All you need is people signed applications from the distrobution repos, people check what they run as root. Also:if you run malicious code as root your already fucked.

This is just some FUD on microsofts part: it would be much easier on windows cause so many people run root on windows.

Also: who cares? on any computer once you are root your screwed, and the computer is toast. And it is just one motherboard.

Amazon EC2

[kylemonger]

I wonder if this hole has implications for Amazon's EC2 servers. Being able to "go over the wall" on a virtual server could make a big mess for them and their clients if their servers prove to be vulnerable.

Re:Amazon EC2

[shentino]

if you can hack the hypervisor, you are king.

It's kinda like god getting rootkitted

Re:Amazon EC2

[julesh]

I wonder if this hole has implications for Amazon's EC2 servers.

IIRC, when I played with EC2 a few months ago the servers I got were Opterons. This problem seems to only affect Intel machines.

Additional Security?

[gbutler69]

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.

Re:Additional Security?

[dbIII]

Who ever claimed that VM gives or is supposed to give additional security?

The same people that say the same thing about NAT - in other words people that mistake obscurity for security.

Re:Additional Security?

[petermgreen]

Many people assume rightly or wrongly that stuff running in a vm only has access to stuff that vm has been explicitly granted access to.

Whether this is a wise assumption is another matter but afaict it is a common one.

Re:Additional Security?

[Anonymous Coward]

Security is relative. It is more secure in certain situations. Assume you have a machine running two services. Let's take an extreme example and say it's a web server and a shell service for a bunch of users. In this case, it's more secure to separate these two services into separate VMs than to have them share a single real machine without any isolation from each other.

Re:Additional Security?

[Anonymous Coward]

Again, security is relative. Not that long ago, if you took your average system with a fresh WinXP install, no service pack and connected it directly to the Internet, you were likely to be infected by the Blaster worm before you could download any updates.

Now put that same system behind a cheap dlink NAT router and you won't have that same problem because external hosts cannot open connections directly to the system.

See, "more" secure.

Re:Additional Security?

[jhol13]

The idea of the virtual machine is that should the OS inside the VM hang or crash or do anything whatsoever the host OS is not affected in any (fatal) way.

This is no longer true (in this case).

Should the VM work as designed, it should not be able to happen.

Same applies for the NAT too, btw. It really does give security as it blocks a lot of unwanted accesses by design. It is not obscurity as the attacker can know how and what is protected. Sure it is not a bit safer than a firewall, but it does give additional security (over direct access).

Re:Additional Security?

[Eunuchswear]

All the people who use that as their business model, you know, slicehost, amazon, people like that.

Re:Additional Security?

[drinkypoo]

The same people that say the same thing about NAT - in other words people that mistake obscurity for security.

WRONG! NAT does enhance security so long as you drop source routed frames, the default in the linux kernel, and use reserved addresses, they cannot be directly attacked (or even communicated with.)

NAT is not a complete firewall security solution, but to suggest that it does not increase security is ridiculous. It makes it harder to communicate with the hosts at all unless your TCP stack retardedly forwards source-routed frames on demand.

Re:Additional Security?

[dbIII]

NAT is not a complete firewall security solution, but to suggest that it does not increase security is ridiculous

My point is some people do mistakenly think it is a total security solution instead of a beneficial side effect. It's the same with virtual machines that are not designed with security in mind - you get an improvement as a side effect but not enough people have put the time in to take care that there are no holes through which it can subvert the host OS. When you have to let the virtual machine get fairly low level access to be able to do things like accelerated 3D graphics etc there are likely to be ways that people with root access in the VM can do a lot which will affect the way the entire system runs.
You should never imagine these things are a security solution unless a lot of specific work has been done to do so and peer reviewed on that - most of this software has other aims first.

No. You Fail!

[gbutler69]

Hyper-visor is not for security.

Re-read it.

[WindBourne]

It is ONLY on a DQ35 motherboard, which is an INTEL DESKTOP SYSTEM. How many of those do you think will be hosting VMs? Not many.

Re:It requires root privileges and is hw limited .

[LordLimecat]

Generally, once you have admin on windows, you can get root trivially using a number of methods, such as replacing logon.scr with cmd.exe, or using the AT command, or this little gem,

sc create rootsvc binpath= "cmd /k start" type= own type= interact && sc start rootsvc && sc delete rootsvc

How to stop this exploit

[mysidia]

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:How to stop this exploit

[rastos1]

CONFIG_MTRR=n ?

Re:Yeah? How?

[dido]

And the the assembly code needs to be written only once for a million and one script kiddies to use it. It isn't harder, or at any rate, it soon won't be. Everyone seems to forget that software has the important property of being able to encapsulate skill. If you already have root on any system, all bets are off.

Re:Yeah? How?

[Anonymous Coward]

Typical response from a user in denial.... LOL
I can't help laughing at you guys when you refer to a bug/possible security hole as a FEATURE...
U SUX!

Re:It requires root privileges and is hw limited .

[Anonymous Coward]

You fail at the intarweb.

You mean root can install a rootkit?

[plnix0]

Oh no!

Car analogy!

[Anonymous Coward]

Getting root is breaking into someone's car through a dodgy lock. Rootkit is getting a locksmith to make you a master key for the car. Even if the owner comes in and fixes the dodgy lock, you can come back any time you want and silently break in. That is, until the owner gets a new car (reinstall/new drive) or gets a new lock (patch the rootkit).

*facepalm*

[darkwhite]

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)

Re:*facepalm*

[Anonymous Coward]

A couple of days ago, we had a discussion about a VMWare bug. Someone asked the question: "Who uses VMs for security". The answers were things like:

- No one
- Idiots

And now we have yet another way of breaking that VM that isn't used for security. And unlike the VMWare bug, this one only works on Intel motherboards, and only if the VM allows access to the real MTRR registers in the first place, and not an emulated set.

How *can* you even allow access to the real set? They will be pointing at the real physical memore, and not the virtual physical memory that the guest OS sees, so allowing the guest OS to set them directly would make them point at the wrong address anyway. So, as far as I can see, you NEED to emulate the MTRR registers, so they point to virtual physical memory. And once they are emulated, you will only get the virtual SMM area.

Re:Yeah? How?

[tixxit]

I can't help laughing when you post AC. Allowing write access to MTRRs is not a bug. Intel caching failed writes is. Cheers.

Re:It requires root privileges and is hw limited .

[Anonymous Coward]

I'm the AC you replied to....

Yeah, NewEgg has one or two of these boards.

I can't imagine running motherboard software raid on an internet facing VM host that's a production server. I run software raid quite a bit in lab systems because it's so much cheaper, but I won't on a production system.

The second limitation with most motherboard RAID systems a board with 6 sata connectors will have 4 configurable sata connections available as a RAID array and the other 2 connectors in a separate configuration. To tell the truth, I've yet to see a motherboard with all 6 sata connectors available in a single RAID array.

Third, 8 gigs of ram isn't a whole lot if you're wanting to run 6 or more vm's, with a couple of them being database servers. You get pretty limited with ram configuration in a hurry.

If you're running Xen you have to have enough ram available to the host to equal the amount of ram available to any one vm to be able to be able to backup/restore/move vm's with Xen tools without having to shut them down. If you have a vm running a decent size database it will require 3 or 4 gigs of ram, meaning your host will also be required to have 3 or 4 gigs of ram available to it too or you will have to shut down your database server vm to be able to do a checkpoint backup or restore. There goes most, or all, of the 8 gigs of ram in just the host and one vm.

Re:This article sets a new bar for "layman's terms

[julesh]

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

Well, I understand that perfectly, and when it comes to hacking I'm a layman, so it must be layman's terms, right? :)

an interesting practical result from the attack

[Anonymous Coward]

Thanks to work by Joanna Rutkowska et al
http://it.slashdot.org/article.pl?sid=09/03/19/179228
it is now possible to take a glimpse at some secrets Intel is hiding from us in SMM code.
Many people had troubles using iTCO_wdt driver (and its ichwd counterpart in FreeBSD) with recent Intel motherboards based on ICH9 family chipsets.
E.g.: http://lkml.org/lkml/2008/2/1/595
A strategy to make the driver work was to disable generation of SMI upon watchdog timeout, but this is not always possible because now the bit that
controls watchdog/TCO SMI can be locked by BIOS.
So I got curios what it is that SMI handler does that prevents the normal operation of watchdog and thanks to the quoted above research I was able to obtain
and disassemble the key code that is involved in handling watchdog timeout.
And here it is:

hanlde_tco_timeout_smi proc near

x = dword ptr -18h
unused_arg_1 = qword ptr 8
unused_arg_2 = qword ptr 10h

mov [rsp+unused_arg_2], rdx
mov [rsp+unused_arg_1], rcx
sub rsp, 38h
movzx eax, cs:PM_BASE
add eax, 34h
mov dx, 2000h ; val
movzx ecx, ax ; port
call outw_subr ; ack TCO_STS in SMI_STS reg
movzx eax, cs:PM_BASE
add eax, 68h
movzx ecx, ax ; port
call inw_subr ; read TCO1_CNT
movzx eax, ax
and eax, 800h ; check TCO_TMR_HLT
test eax, eax
jnz short enter_infinity ; a BUG? should be jz?
movzx eax, cs:PM_BASE
add eax, 64h
mov dx, 8 ; val
movzx ecx, ax ; port
call outw_subr ; ack TIMEOUT bit in TCO1_STS

Re:It requires root privileges and is hw limited .

[Anonymous Coward]

And anyone running a Linux VM on a hypervisor based system is stupid anyway. The Linux kernel is perfectly capable of running VMs (of various flavours) without needing a hypvisor.

DANGER

[norteo]

Oh my God!!! So do you mean that if someone has root access, my system is in danger?!?!?! What am I going to do!?!?!?

easy fix

[shiba_mac]

"The attack works best on a Linux system with an Intel DQ35 motherboard with 2GB of memory"

So, IF I'm using a specific motherboard and IF I have 2GB of memory and IF I've been dumb enough to give someone root access, I have to buy another 1GB of ram?

Sweet, I've been looking for a good excuse to spend money.

Utter Rubbish

[nevvamind]

It is analogous to saying "If someone has access to your Bank safety vault, he can burn your money" These guys are deluded !

Technically ..

[freaker_TuC]

.. yes!

Re:Yeah? How?

[Anonymous Coward]

You've got to be joking right?

After all the righteous crap that Linux users have plastered over Windows about security vulnerabilities, you have the audacity to state 'The only reason the exploit is easier on Linux is because of a FEATURE Linux offers'

Holy moley -- automatically executing attachments in Outlook was considered a feature, doesn't make it right.

Damn Linux zealots.

just installed

[Anonymous Coward]

Debian Lenny on a i486/266MHz (no cache == no poisoning!) for the worst case. since you can't really have X on such a machine, i'd guess this solves also a lot of other common security problems. surfing with w3m and wget still faster than with firefox on my thuron boxes. what the heck...

Re:It requires root privileges and is hw limited .

[AlterRNow]

Actually, I have had "permission denied" while running a command as root ( listing a directory ) so even root is not 'all powerful'.

And for the not-quite-so-paranoid

[Mathinker]

What you say is perfectly correct for machines which need the utmost of security. It seems to be a bit of overkill in my eyes because

• Most Linux privilege escalations are quickly patched.
• Most of those privilege escalations are dependent on the use of a specific buggy driver and are therefore not general to all Linux installations.

I suffice by never using the initial account, which has sudo powers, for anything but command line operations essential for the administration of the installation, and only from a (text-only) virtual console.

For all other uses I set up a second account which is as unprivileged as conveniently possible (and for sure it has no access to root via sudo).

Re:Yeah? How?

[Jackiesaurus]

So could one theoretically use wrmsr.exe to pull this off on Windows?

Re:Yeah? How?

[Jackiesaurus]

It's kind of like how the delete button could be used by an attacker to delete important files. It's just a tool that's available that could be used for good or evil.

Automatically executing files that happen to land on your machine is just plain stupid and completely different.

Cache poisoning breaks virtualization

[gwolf]

The big threat regarding cache poisoning is not just having root users subvert their own systems - It allows breaking free of the hypervisor and attacking other virtual hosts running on the same hardware.

Re:It requires root privileges and is hw limited .

[csartanis]

You fail.

Administrator and System can both run code in kernel mode by loading a device driver. The hypervisor is not a permission level like what GP was talking about.

Re:Yeah? How?

[tixxit]

No, the difference is the bug is not in Linux's /proc/mtrr proc entry, it is with Intel caching failed writes. Saying the /proc/mtrr entry is the problem is like saying that the internet is a bug the Conficker worm exploited. It clearly isn't, it just used the internet to exploit a vuln in Windows. See the difference? Similarily, I would NOT say that Outlook letting users run executables is a security flaw. That fault clearly lies in the user running it or the policy of the IT dept which should disable it. Personally, I thought my post was giving the nod to Vista (64-bit only) and Win 7, but whatever.

Re:Yeah? How?

[tixxit]

They are machine instructions. So, on Windows, you would need to load some code into the kernel ("device driver") that calls these instructions. As I said, on Vista 32-bit and XP, the Administrator can do this. So, the extra step would be loading a kernel module that writes to the MTRR registers, instead of doing it directly. I should note, making this exploit more generic (work on more then a DQ35 w/ 2GB RAM) requires a bit of skill, certainly more so then would be required to write a no-op Windows driver (seriously, 3 or 4 lines).

Re:It requires root privileges and is hw limited .

[Anonymous Coward]

You fail.

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

One more reason not to use Intel boards

[AG the other]

The subject says it all.

AG

great.........

[Anonymous Coward]

unite the separated VM as one.......
so....just use one PC at a time.....
>.^

'haha' tag

[KermodeBear]

C'mon guys, where's that 'haha' tag that you so eagerly slap on to similar articles about Windows, hm?

Why was this even implemented?

[argent]

Why was there even an attempt to implement a data store on the CPU that isn't accessible to the OS? Once any such repository is compromised, it's impractical to access and repair, so why not get out of the frigging way and just provide an API to access it.

Yes, I'm looking at you, TPM.

Sudo is the real hole. / Asus EEE

[sowth]

Casual setup of sudo is the biggest security hole. On my Asus EEE running the pre-installed Xandros, they have sudo enabled for everything and passwordless as well. If you turn it off, you can't shutdown or boot up. WTF? Then again, they also have an ancient vulnerable version of samba since the last time I checked updates a month or so ago, and the kernel is vulnerable to the vmsplice exploit. Easy root access with no user interaction.

I managed to disable samba, and I found the programs to enable in sudo so I could shutdown the system, but it wouldn't boot up! They locked down the system tight so it is very hard to access the boot process, so it took some panic and effort to get it working again.

Dell?

[Anonymous Coward]

OK, so how do I know what motherboard my Dell server has in it?

Re:Yeah? How?

[BitZtream]

Actually, all you need is debugging rights on the machine to do whatever you want to whatever memory you want.

Admins have debugging rights out of the box, nothing special required. So while you need to know a little about the debugging API, I don't really see how this is any different than say using /dev/kmem or something like that, since you need to have a clue about how /dev/kmem works and the IOCTLs involved with using it.

Same idea, different API, people just don't really call it an API when you're using a device.

Re:Yeah? How?

[BitZtream]

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

While I agree with you completely, I would like to point out that people think ActiveX is nothing but one big exploit when it really is just a feature and is no less secure than a Firefox plugin.

So while you and I may not call this a 'Linux exploit', I do not call any ActiveX issue an exploit either. If you intentionally allow someone to run unsafe code the bug is in the operator, not the software.

I just get urked by people who don't understand that ActiveX isn't a security problem, the users who click 'YES YES YES YES' to every warning that pops up telling them its a bad idea are the security problem.

Of course anything that lets a web page install and run an ActiveX without the users explicit permission is no different than any thing that allows a web page to run an app on a Linux box without explicit permission. But that would be a browser exploit, not a Linux exploit or a Windows (or ActiveX) exploit.

Why virtual machines are of little use ...

[BitZtream]

for production machines with real workloads.

Lets think about it for a second for all those idiots who use VMs like a security fence.

If the OS isn't capable of protecting itself, why on Earth would you think the hypervisor would be? The OS is capable of doing EVERYTHING the VM hypervisor can do. Its just a matter of if it is written to do so or not. The hypervisor is really just another OS with an API that is a lot like physical hardware that it exposes to the virtual machines. With hypervisors you actually expose the physical

If the VM server can say 'don't let anything break out of this sandbox' SO CAN AN OS WRITTEN TO DO SO. If an exploit comes out that can not be stopped by the processor hardware then neither the hypervisor nor the OS can stop it. The only way to truely stop such a thing is software emulation of EVERY ASPECT of the hardware, which for reference would suck ass and no one would want to use anyway, and its probably got its own set of exploits.

VM servers are only useful if you are one of those lucky bastards who works somewhere that where you end up with a bunch of departments wanting to run software that you can't put on other servers because of incompatibilities with libraries and the hardware would be so under utilized most of the time that you might as well throw another similar package on it. Other reasons are because you want to give the department (such as development) full control over the 'machine' but they really don't need a full machine.

Hypervisors are NOT A SECURITY TOOL. Anyone who thinks they are is ignorant. They are simply ways to better utilize under used hardware. Period.

With that said, I run a small VM server for our company, its got 15 or so VMs running on it, lets me allow random people to run whatever they want in a sandbox for testing and development without having 15 boxes in the server room wasting space, heat and energy. When I separate production machines for security reasons, they run on physically separate hardware. Those machines all pretty much do A SINGLE TASK so I can limit the possible ways each component can be exploited and how far that exploit can go.

Re:Linux - all your data is in the user account

[hellop2]

No, you're not missing anything. What's been said is that if someone has access to your user account, it's pretty easy for them to gain root. If all you care about is protecting your data, then you are compromised enough. But, maybe the hacker/worm doesn't care about your data, and just wants your computer... to say, be a zombie for a DOS attack or for an ftp server.

If I am root

[SlashDev]

If I am root, why do I need to use 'Intel cache poisoning' to install a rootkit?