Intel Cache Poisoning Is Dangerously Easy On Linux 393
Julie188 writes "A researcher recently released proof-of-concept code for an exploit that allows a hacker to overrun an Intel CPU cache and plant a rootkit. A second, independent researcher has examined the exploit and noted that it is so simple and so stealthy that it is likely out in the wild now, unbeknownst to its victims. The attack works best on a Linux system with an Intel DQ35 motherboard with 2GB of memory. It turns out that Linux allows the root user to access MTR registers incredibly easily. With Windows this exploit can be used, but requires much more work and skill and so while the Linux exploit code is readily available now, no Windows exploit code has, so far, been released or seen. This attack is hardware specific, but unfortunately, it is specific to Intel's popular DQ35 motherboards."
Linux (Score:5, Funny)
They make it sound like a bad thing that it's easier to use your hardware on Linux =)
Re:Linux (Score:5, Insightful)
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 (Score:5, Insightful)
Re:Linux (Score:5, Interesting)
Additional Security? (Score:3, Insightful)
Re: (Score:3, Insightful)
The same people that say the same thing about NAT - in other words people that mistake obscurity for security.
Re: (Score:3, Informative)
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 hardwar
Re: (Score:3, Interesting)
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 (Score:5, Informative)
If the nasty programs get root, you're already hosed.
So yes, this is interesting, but also completely irrelevant. On most systems, root can also
- modify libc, thus affecting every single dynamically-linked program on the system /dev/mem, thus making attacks like this seem trivial /, thus nuking the system .ssh -- and if they have an unencrypted ssh key, thus accessing every machine they have access to! And you can find out which ones by looking at .ssh/known_hosts, and maybe .bash_history. /tmp, or swap...
- modify gcc, thus affecting any new programs downloaded/compiled from source
- modify tripwire (or whatever they're calling it now), thus hiding itself
- access
- rm -rf
- dd if=/dev/zero of=/dev/sda, thus nuking the system even more permanently
- access everyone's xauth, thus their X, thus easily keylogging and screenshotting, if it's a desktop
- access everyone's
- kill any process (except zombied processes)
- access
You get the idea.
There are various ideas to secure root (like selinux, etc), but it is still BAD for them to get root, and the best technique is still to prevent people from getting root in the first place.
Re:Linux (Score:4, Insightful)
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: (Score:3, Funny)
Re: (Score:3, Insightful)
Pretty cool stuff, when it comes right down to it.
Re: (Score:3, Interesting)
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, some
Re:Linux (Score:5, Interesting)
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 [lwn.net]) 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 (Score:4, Informative)
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 [sourceforge.net].
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 (Score:5, Funny)
Oh dont worry we know your password is hunter2.
Re: (Score:2)
Yep, all it said is that it is easer to program things in Linux.
First you need root on the box (Score:2, Informative)
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 (Score:5, Funny)
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 (Score:5, Funny)
Re:First you need root on the box (Score:5, Funny)
Your post indicates that you are suffering from the wooosh vulnerability.
Re: (Score:3, Funny)
Re: (Score:2, Funny)
Re:First you need root on the box (Score:5, Insightful)
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 (Score:4, Interesting)
Re:First you need root on the box (Score:5, Insightful)
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 (Score:5, Informative)
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 (Score:5, Informative)
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: (Score:2)
Or not if the GP post was false.
Re:First you need root on the box (Score:5, Informative)
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 (Score:4, Interesting)
or poke the MTRR...
Re:First you need root on the box (Score:5, Informative)
No, it doesn't work like that.
This came up in a previous discussion. The SMM is simply a part of the normal RAM, used for the CPUs own purposes. While the OS can't normally touch it, it's still RAM and doesn't persist across reboots.
All that putting the virus into SMM RAM means is that as memory not normally accessible by the OS, so an antivirus can't go and scan it. But something has to put the virus into the SMM RAM anyway, and that something is on the hard disk or comes from an exploit through the network.
MOD this guy up (Score:2)
SMM buried rootkits (Score:3, Interesting)
How big of a rootkit can fit in SMM memory and how does this survive a power off?
Re:First you need root on the box (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
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: (Score:3, Funny)
If only there was a Wikipedia page that explained what a rootkit is and why malware would use one!
"Exploit" implies there was an actual hole (Score:5, Insightful)
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: (Score:2, Interesting)
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.)
you got root (Score:2, Insightful)
If you got root, aren't there easier way to install a rootkit? Just load a rootkit module into the kernel.
It requires root privileges and is hw limited ... (Score:5, Informative)
Re:It requires root privileges and is hw limited . (Score:4, Insightful)
It's not a scare at all. It's only "more difficult" on Windows because Windows "admin" privileges are worthless...System permissions are higher.
This is one of the reasons why Windows viruses have historically been more annoying: they actually run at a level that's higher than the highest user level.
Saying "admin or root" permissions completely misses the point. Root is it. That's the highest level. Kill any process, control any device, install any code, read any file, everything. As many people have pointed out, once you have root you're done. There is no higher exploit than that.
Re:It requires root privileges and is hw limited . (Score:5, Insightful)
You fail.
hypervisor is higher. And code injected in there, or trojan made as hypervisor and you're screwed.
I'd say it's pretty fortunate, actually (Score:2)
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.
The point? (Score:5, Informative)
"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? (Score:5, Informative)
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.
Comment removed (Score:5, Funny)
Windows Cache Poisoning only a minor technicality (Score:5, Informative)
[..]
We see here the first entry (reg00) is marking the whole memory as Write-Back cacheable8. Next we see a bunch of "exceptions" -- regions of memory each marked as uncacheable. One of those regions, (reg03) corresponds to the memory where the SMM's TSEG9 segment is located. We can now simply remove this MTRR entry for TSEG, with the following shell command:
echo "disable=3" >|
[..]
Of course on different systems than Linux, e.g. Windows, one doesn't have such a convenient access to
Once the TSEG's memory is marked as WB cacheable, one can do something as simple as:
*(ptr) = evil_data;
outb 0x00, 0xb2
Ok, easy on Linux (Score:2)
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: (Score:2)
To answer your question, some uber-script-kiddie wants to have uber-root privileges. ;)
I ain't no Linux guru - but, this really does seem to be a circular logic thing. I gotta be root to install a root kit - but, WHY?!?!?! I'm already root, I already have access to all of root's p0rn (not to mention all the users on the system), WHAT MORE IS THERE?!?!?!!!!
Maybe I'll change my handle to UberRoot now. I've always wanted to be a master script kiddie.
Probably a month-old dupe (Score:5, Informative)
Thi story is probably a dupe [slashdot.org]. The original not only has the same blog post, but also has links to far more relevant information. Please tag it.
Hell has frozen over (Score:2, Interesting)
Re: (Score:2)
This is an exploit for virtual servers (Score:5, Informative)
As many have pointed out, there's no real point to "exploiting" a machine that you already have full (root) access to - with one exception: virtual servers.
The whole 'danger' of this exploit is that it enables a virtual server's "privileged" "root" user to gain hypervisor access, which is equivalent to taking over the entire physical machine and any/all other virtual servers hosted on said machine.
If you don't run a virtual server farm, this exploit means absolutely nothing to you. If you do, it's a very easy, scary way whereby any of your "clients" can take over your physical machines and access all of the other virtual servers hosted on the same piece of hardware.
This article sets a new bar for "layman's terms" (Score:5, Informative)
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.
Meh (Score:2, Insightful)
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).
Description for dummies (Score:2)
Now we must get a time machine and a paradox solving engine, and the vulnerability will turn to be pretty scary.
Re: (Score:3, Informative)
Re: (Score:3, Informative)
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.
A root to root exploit ?! (Score:2, Redundant)
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...
The benefit of being outdated (Score:3, Insightful)
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.
Here's what I see (Score:3, Interesting)
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: (Score:3, Insightful)
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: (Score:3)
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.
*facepalm* (Score:4, Insightful)
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:Queue Microsoft Trolls in (Score:4, Insightful)
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: (Score:2)
So how many of those conficker bots are alternate OSes?
Re:Queue Microsoft Trolls in (Score:5, Insightful)
Re: (Score:3, Insightful)
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 (Score:5, Insightful)
Actually, I like my machine. Please, don't take it. I was just trying to make a point.
Re: (Score:3, Insightful)
And lock the case so the cracker can't reset the CMOS by disconnecting the internal battery....
Re:Queue Microsoft Trolls in (Score:5, Funny)
"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 (Score:4, Interesting)
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 (Score:5, Interesting)
XP and x32 do not have that "protection" though.
Re: (Score:3, Insightful)
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
Yeah? How? (Score:3, Insightful)
"With Windows this exploit can be used, but requires much more work and skill"
Someone please explain to me exactly how it's harder to get to the MTR registers under Windows than it is under Linux.
Let's assume in both cases you're root. You have to be or they're inaccessible. What happens next? Why is Windows more difficult?
I'm expecting it isn't, and it's about a couple dozen lines of assembler either way.
Re:Yeah? How? (Score:5, Informative)
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? (Score:5, Informative)
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.
Well that's a good thing then (Score:5, Interesting)
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 (Score:5, Informative)
> 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:Yeah? How? (Score:5, Informative)
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:Queue Microsoft Trolls in (Score:5, Funny)
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 (Score:4, Informative)
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 (Score:4, Informative)
Yes, but does it... (Score:4, Funny)
..run on...
Oh, nevermind.
Re: (Score:3, Informative)
Re: (Score:3, Funny)
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 (Score:4, Interesting)
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: (Score:2)
Re:Article Is Bunkum (Score:4, Interesting)
but can root, make a file he himself can't (re)move?
.'. root > god
The answer ofc is yes [securityfocus.com]
QED
Re: (Score:2)
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: (Score:2)
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 i
Re:At the risk of causing a war... (Score:4, Funny)
OpenBSD immune... again. (Score:2, Interesting)
Yet again, OpenBSD [openbsd.org] shows foresight by having this bugginess fixed in 2003 long before the actual chips were available on which this can happen. Well done, lads.
Re: (Score:2)
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: (Score:2)
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: (Score:2, Funny)
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!