Linux Kernel Exploit Busily Rooting 64-Bit Machines 488
An anonymous reader writes "Running 64-bit Linux? Haven't updated yet? You're probably being rooted as I type this. CVE-2010-3081, this week's second high-profile local root exploit in the Linux kernel, is compromising machines left and right. Almost all 64-bit machines are affected, and 'Ac1db1tch3z' (classy) published code to let any local user get a root shell. Ac1db1tch3z's exploit is more malicious than usual because it leaves a backdoor behind for itself to exploit later even if the hole is patched. Luckily, there's a tool you can run to see if you've already been exploited, courtesy of security company Ksplice, which beat most of the Linux vendors with a 'rebootless' version of the patch."
But wait (Score:3, Insightful)
Re:But wait (Score:5, Informative)
It's a local user privilege escalation exploit. Every OS has those. What it means is that if someone can get in to your computer as a local user (or gain control of a process that runs as a local user, such as the web server process), then they can gain root access to your system.
However, the first step - getting in as a local user - is really really hard on most servers. Unless you're handing out local user accounts to people left and right (like a university cluster or something), it's going to be nearly impossible for Joe Random Hacker to get control of a local user account.
You know how it's generally held to be true that if you have physical access to a running machine, the only thing stopping you from getting root access to it is time? Well, the next step up (in terms of difficulty) is not having physical access, but having access to a local user account.
The exploits that work on Windows, on the other hand, are ones where someone who doesn't even have local user privileges - who's just looking at your website - can get root access, like the one Slashdot posted here [slashdot.org].
Re:But wait (Score:5, Insightful)
Uhh.. dude. Seriously. Did you even think about this?
Your web browser runs as a local user. If there is a flaw in your web browser (and all of them have had plenty), then they can use that flaw, just by looking at a web site, to gain root access to your machine using this vulnerability.
So yes. This *IS* the kind of flaw that just looking at someones web site can exploit, if they can also attack your web browser (which is typically pretty easy to do as most people aren't always up to date).
Re:But wait (Score:5, Insightful)
As a home user, I'm always a bit aghast when people determine that preventing access to root is my biggest priority.
If they've got access to my browser, this means that they now have access to all of my documentation, and have the ability to run programs (e.g. through my .bin and .profile files) including full access to the internet.
I mean, they've got my data, they've got the power to run applications and they've got full internet access. I'm personally not that worried about root access - if they break through the browser barrier I'm basically f*cked already.
(yes, yes, I know, SELinux and such could protect me if I configure them correctly. Not even I can easily do that however, and nobody that I know would go that far).
Re:But wait (Score:4, Insightful)
Yeah, super-easy. Just learn YET ANOTHER fucking configuration file setup, figure out why usr.bin.firefox is in the /etc/apparmor.d/disable folder, figure out that you have to use the "enforce" command line utility, figure out why that does not change any status for firefox and figure out why the fuck I am bothering in the first place. And that for something for which I wonder if it is still maintained at all. Reading the FAQ was interesting, but do you really want users to care if the system uses inodes or paths? More to the point: *should* users know that kind of crap?
Common guys, when are you going to learn that this way of handling systems is something for sysadmins that care to know what the system does? I don't have the time to go into this, let alone prove that it actually works for my setup.
Thanks for pointing out the app, but I'll pass.
Re:But wait (Score:5, Insightful)
What part of Web *BROWSER* did you not understand?
I said nothing about a server. Even so, you don't need a shell to execute arbitrary code. You just need to be able overflow a buffer or some other kind of attack. A shell is meaningless.
Re: (Score:3, Funny)
IE's rendering engine? ;)
Re: (Score:3, Insightful)
Yeah. If only we had some way to prevent that - some kind of programming language feature where all buffer accesses were automatically checked by the machine. But Real Men Manually Manage Memory, and usually badly.
Re: (Score:3, Funny)
I agree, the web browser is highly insecure. Anyone that cares about security will not run one.
poorly described (Score:3, Interesting)
What is annoying me about these issues is that they are described so poorly that I'm not certain if I have a problem. I run 64-bit Linux but no 32-bit code and there are no local users other than for the services I'm running (http and ssh). So do I need to take the time to do something or can I wait for a normal update?
Re: (Score:3, Interesting)
What is annoying me about these issues is that they are described so poorly that I'm not certain if I have a problem. I run 64-bit Linux but no 32-bit code and there are no local users other than for the services I'm running (http and ssh). So do I need to take the time to do something or can I wait for a normal update?
Short answer - it depends on whether your kernel has the vulnerability. Seriously, Slashdot is the worst place to find out more into about vulnerabilities. At least it did give the CVE which you can use to get more details and determine if you're affected.
Re:poorly described (Score:5, Informative)
Re: (Score:3, Funny)
Function names like wtfyourunhere_heee, p4tch_sel1nux_codztegfaddczda and datatypes like __yyrhdgdtfs66ytgetrfd as well as hex-code doesn't make the code look less suspicious.
I can't be sure that the rootkit (or a different one) is not in there.
You are a dummy for downloading from a http website without a checksum. No thank you.
In-band checksums with downloadable files (Score:3, Insightful)
What exactly is the point of supplying a checksum by the same route/download method as the file in question? Surely if the file can be modified, so can the checksum. Maybe it would be useful if people got the checksum and verified it was the same checksum everyone else saw, then verified the file with it, but that just doesn't happen.
Re: (Score:3, Informative)
why the fuck do they need to
apart making the code horrible? Seems like an entry for IOCCC. I don't trust this check at all! Wtf is doing this?
Regardless, it fails on my pc at
A little search shows they just took the public exploit and mangled names plus other small changes. Are they joking?
Re:But wait (Score:4, Insightful)
My own Computer - Dude! (Score:3, Funny)
Dude! - I am SO going to root my very own computer!
Re: (Score:3, Insightful)
For a home user, not a big deal. For an business environment, much more so. Dismissing it as 'nothing to see' is shortsighted at best, especially when considering the backdoor left by the hack.
Re:But wait (Score:5, Funny)
No, Apple devices do not have security vulnerabilities to exploit. They do sometimes have remote-user-friendly jailbreaks, but that's an entirely different thing.
Re:But wait (Score:4, Informative)
Re: (Score:3, Insightful)
Is Slashdot advertising now? (Score:5, Insightful)
Why does the summary and articles read like a paid advertisement for Ksplice?
Re:Is Slashdot advertising now? (Score:5, Interesting)
Re:Is Slashdot advertising now? (Score:5, Funny)
***Ding ding ding***
We have a winner -- Don Pardot, tell Ms. Hudson what she's won!
Re:Is Slashdot advertising now? (Score:5, Insightful)
Because sensationalism sells and best of all, people on the other side of the fence (eg, MS) can then link to the article as way of providing "proof" of how insecure Linux really is. Facts be damned, let's just spray some more fear-mongering around and scare the dillys out of every person. It's just not a /. story anymore unless it's an advert or traffic-whore.
Re:Is Slashdot advertising now? (Score:5, Informative)
Oh it's not paid (Score:5, Informative)
Re: (Score:3, Insightful)
Why does the summary and articles read like a paid advertisement for Ksplice?
Probably because the Ksplice guys offer a solution to a problem for admins who have standalone servers that can't be rebooted and nobody else does.
I don't understand the Ksplice hate here - they're filling a niche. I'd advise my clients (should I slashvertize too?) to instead go with a redundant clustered solution, preferably with automatic failover and/or live migrations of vm's so reboots don't hurt. But, that's more expensive
Re:Is Slashdot advertising now? (Score:5, Insightful)
Ksplice are attention whores.
Re: (Score:3, Insightful)
Yea, and guess what? When someone breaks into $LAME_PHP_CODE and runs something, that something is running locally, no?
Oh Noes (Score:5, Insightful)
Yes, there's an available rights escalation vulnerability in recent Linux Kernels that's best patched by updating your system with the latest updates. The breathless nature of the fine summary betrays an eagerness to get Linux admins to click the links before they've done so. I'd rather not. Social engineering is such a powerful exploit mechanism after all.
The Windows geeks obviously will want to paint this as a native Linux vulnerability that they don't have - and it is marginally true. That's fine - but it's an escalation bug, not a remote root, and they've several dozen remote root bugs to close before they point fingers.
Re: (Score:2, Insightful)
The Windows geeks ... they've several dozen remote root bugs to close before they point fingers.
Care to point them out?
Re: (Score:2)
The Windows geeks ... they've several dozen remote root bugs to close before they point fingers.
Care to point them out?
Just subscribe to the SANS newsletters - they point them out every week (for all OSes, not just Windows).
Then perhaps do as the GP asks (Score:3, Insightful)
Point out a current remote root exploit in Windows. To the best of my knowledge, there are none. Which means that the original poster is just fluffing his feathers trying to divert attention from the Linux issue.
While this isn't something that means Linux is majorly insecure or anything, it is a Linux issue. However fanboys don't like that, they can't just say "Yep, there's a problem." Instead they want to try and deflect it, make it about something else. So he deflects the issue by claiming there are some
Re:Then perhaps do as the GP asks (Score:5, Informative)
Just a quick google search: http://secunia.com/advisories/41122 [secunia.com]
There are quite a few listed on secunia, it's a really good site. Currently lists 10 unpacked vulnerabilities in Windows Vista, none for Linux surprisingly, it must be a conspiracy against Microsoft and those damn Linux fanboys.
Re:Then perhaps do as the GP asks (Score:4, Informative)
Re:Then perhaps do as the GP asks (Score:4, Insightful)
>Point out a current remote root exploit in Windows. To the best of my knowledge, there are none.
You're kidding right? They're enumerated the second Tuesday of each month. We even have a word for it now: "Patch Tuesday". It's an IT anti-holiday. How do you not know about this?
Re: (Score:3, Informative)
Most local exploits are outright dismissed by Microsoft as "not a bug".
For a big example, although one that Microsoft later partially mitigated due to the outcry, look for the "shatter attack".
Windows may not be as defenseless to remote attacks as it used to be, but locally, it'd be a lunacy to claim it has even semi-working security. Allowing programs root access left and right doesn't help, either.
Re:Then perhaps do as the GP asks (Score:5, Informative)
Did you skip the end of the video where the demonstrator opens up a command prompt on the remote machine running as the NT Network Authority? That's as close to "remote root" as makes no difference.
Re:Then perhaps do as the GP asks (Score:4, Insightful)
Re: (Score:3, Insightful)
>Care to point them out?
No.
I don't want them fixed. I am aware of several dozen remote root exploits for Windows and am sure there are hundreds I'm not aware of. But I don't have to prove it. I can say it, and Microsoft could sue me. Between the time they sued me and the time we got to court they would have to span two years of updates, in which they would have to admit several dozen remote root exploits and concede their case. They are there, and if you trawl the darker corners of the Internet yo
Moderation abuse (Score:3, Insightful)
Y'know, sometimes there are posts that are poignant, interesting, on-topic, and yet are modded down as a troll for no better reason than people who have mod points are more interested in squelching challenging ideas. That's fine, and slashdot has a mechanism to deal with that, called Karma.
Because I have good /. Karma I can call your attention to the parent post even though I believe it's been badly moderated. Because I'm a Slashdot subscriber, I get an extra point to add to this post, which calls attent
EH (Score:4, Insightful)
This is a local exploit so I'm not horribly concerned and here is why.
You should always treat your systems as if an exploit already exists for both remote and local connections.
The systems I maintain are part of a bit of an elaborate network. There is a huge investment in controlling incoming and outgoing traffic as well as managing who actually has access to systems. While a local exploit a big deal it's not like there are a great number of places for users to inject this code. If someone could compromise an input vector and piggyback the exploit that still wouldn't get them very far. In fact, without knowing key details regarding the network infrastructure they would simply nab a host that could not reach the outside world.
With that said we do have a bit of reliance on lbs, traffic inspection, firewalls and a good bit of monitoring equipment. However, there is a solid investment in specific purpose network and security protocols to accomplish these goals. In a bit of a cheaper shop I'm wondering what others do to maintain security and get some of the same tools. (I'm being very vague about our setup intentionally, but there have to be some decent foss network tools as well).
Re:EH (Score:5, Insightful)
THIS ^^^^^^
I understand why you are posting as AC and being vague about it, I'm fucking paranoid about revealing details of the entrails of my network too.
People don't understand how security works. If I told you the alarm in my office will fail to detect movement in zone 7 if you do X and Y, would you say that my office is absolutely compromised? No. I still have a security guy, bars, security doors, CCTV, and most things of real value inside is doubly secured (source code is encrypted, money is in the safe). A simple glitch doesn't mean I'm getting robbed.
The problem is that there are many admins out there that do it by the book, and just think that patching systems is enough. You have to work with the OS to keep it secure, not just rely on it. Of course, securing a platform like windows is fucking impossible, that's why we don't use it (not even in the desktops). But if you have a reasonably secure OS, you have to use the rest of your architecture plus some level of monitoring and log-watching to keep things safe.
Re: (Score:2)
But, you see, some anonymous reader said you are probably already rooted. He said probably, which indicates there is greater than a 50% chance you are already screwed, so it must be true. Nevermind that that the summary reads like an ad, looks very fishy, and is preaching doom and gloom, it got approved here, so believe it!!!
*Yawn* Local Root Exploit (Score:5, Insightful)
Re:*Yawn* Local Root Exploit (Score:5, Insightful)
This doesn't require being physically close to the computer. For example, a web hosting company might give people limited permission ssh accounts on a web server, and the people could then use this exploit to get root.
Re:*Yawn* Local Root Exploit (Score:5, Insightful)
Pretty much Greyfox sums it up right there. The days of having hundreds to thousands of users with shell access on a university or public access machine are long gone. Instead, the focus of security has moved from keeping users out of root [1] to keeping people from getting to the machine in the first place, and if they get to the machine via a networking protocol, not being able to execute code in any meaningful context on the machine.
The only time I'd worry about this is if someone could get a shell or execute code in an application's context (say they manage to do a buffer overrun and are able to stick a user shell on a port, for example.) However, this is what AppArmor and SELinux are designed to stop anyway, so even with root context, and attacker is limited to what they can do.
[1]: This isn't to say that user to root priv exploits are something to be completely neglected, of course.
Re: (Score:3, Informative)
The exploit in question actually includes a SELinux bypass. SELinux and AppArmor are not as great as you think; they are understood well enough that hackers can defeat them, and they are deployed on enough systems that hackers write their exploits so these protections are defeated.
Re: (Score:3, Informative)
SELinux and AppArmor are not as great as you think; they are understood well enough that hackers can defeat them, and they are deployed on enough systems that hackers write their exploits so these protections are defeated.
SELinux and Apparmor can't do much if you have an exploit that allows you to execute arbitrary code inside the kernel (which I believe this does). But they'll certainly stop the kind of random buffer overflow exploit that's been the most common avenue of remote attack.
Re: (Score:3, Informative)
SELinux and Apparmor can't do much if you have an exploit that allows you to execute arbitrary code inside the kernel (which I believe this does). But they'll certainly stop the kind of random buffer overflow exploit that's been the most common avenue of remote attack.
They will stop the simple use of a buffer overflow exploit to do something the program with the vulnerability couldn't do.
That is: a buffer overflow exploit allows running arbitrary code in the context of the program. SELinux limits what
Re:*Yawn* Local Root Exploit (Score:5, Informative)
The days of having hundreds to thousands of users with shell access on a university or public access machine are long gone.
What makes you say that? All of the three universities I've been at in the past eight years have provided shell access for all students and faculty to at least one cluster, and often more than one. The current university uses Solaris, so this particular issue isn't relevant, but I would be more surprised to hear of a university that doesn't offer shell access.
Re:*Yawn* Local Root Exploit (Score:4, Insightful)
Mod the parent up. It's funny how certain folks try to down play a security hole like this just because it happens on Linux.
slashdvertisement ... and full of crap. (Score:2, Insightful)
Now Ksplice is really starting to piss me off. This is at least the fifth time we've get this kind of crap on slashdot.
Besides that, this is an escalation vuln ... it's local, ok? Not a remote exploit. And, regardless of all that, there's already a fix, which was promptly released before this got out of hand.
So, between the ksplice assholes that abuse each vulnerability that is published to blow it out of proportion and somehow imply that if you require ksplice to patch this without loosing your job (I mean
Re: (Score:2, Insightful)
Ya (Score:5, Insightful)
Our UNIX admin has the philosophy that anyone with local access can get root if they want it bad enough. Security isn't done by presuming you've made that impossible. Rather security is done by making sure you don't give access to just anyone, and to monitoring what people do. Local escalation exploits are things to be fixed, since they can always make a remote exploit worse (someone exploits something remotely, gets unprivileged access, exploits the local exploit to get root) they aren't a critical threat usually.
However I will say you don't make things much better when you start with name calling with regards to Windows and the people that run it. That smacks of being the sort of asshole that knows little about the other platform that you are painting them to be. That you have a preferred platform is great. One would hope it is based on good reasons. However name calling on another platform indicates it is more likely based on zealotry than anything else.
Re:slashdvertisement ... and full of crap. (Score:5, Informative)
it's local, ok? Not a remote exploit.
Ironically, a local exploit is somewhat more serious for Unix systems, because Unix hosters are much more likely to give shell access to their customers (effectively giving "local" access), while the most a typical Windows hoster will do is let you connect with IIS admin console.
Re:slashdvertisement ... and full of crap. (Score:5, Interesting)
``assholes that don't understand shit about security and somehow think that this means that GNU/Linux is insecure''
It _is_ insecure. There are plenty of vulnerabilities being found and reported, and there are several things that many distributions could do to improve security. To name a few examples, many distros ship with stack smashing protection and address space layout randomization disabled, and allow pages to be writable and executable by default. Also, usually, many operations are reserved to the root user, and the root user can do everything which means that more programs than necessary run as root, and root has more power than necessary. These are not the properties of secure systems; it's not even close to state of the art security.
``as bad as their shitty system''
I am not sure that such derogatory language makes the world a better place. I'm not even sure comparing the security of Linux with that of Windows is useful. If you do compare them, you will find that, at the very least, Microsoft has improved the security picture on Windows a great deal. In some cases, such as running with reduced privileges by default and only elevating privileges for programs that need it, they have merely caught up with Linux systems. But since Windows Vista, Windows ships with address space layout randomization and non-executable pages (Microsoft calls it DEP) enabled for many libraries and executables. Newer versions of Internet Explorer (certainly 8, but also newer versions of 7 if I'm not mistaken) are among those applications, and also include a "protected mode" where most of the program can't do very much at all, and all potentially harmful operations are concentrated in a small, trusted kernel running in a separate process. These are the sort of security measures taken by a vendor who takes security seriously. On the *nix side, you will find this kind of stuff in OpenBSD and a few specialty hardened Linux distros, and that's about it. Ubuntu has AppArmor, but hardly uses it.
If you look at vulnerabilities, like the privilege escalation vulnerability in the story, I would not be surprised to find that more of these are being found and reported in Linux than in Windows these days. What that means about the relative security of Linux and Windows, I don't know. But clearly, serious security flaws are being found in Linux. As far as I am concerned, Linux's security track record is far from stellar, and there certainly isn't a strong security culture that will make this better in the near future. Easily applied security measures (see first part of my post) are being left on the table, and we have far too much code running in all-powerful kernel mode for me to be comfortable with (just one data point: I have over 100 MB of kernel modules on my system, and on the order of tens of megabytes in the running kernel image).
Considering all the above, I would certainly refrain from calling names or making derogatory remarks against users of non-Linux systems. I don't profess to know which system is the most secure, all things considered, but I'm a firm believer in not needlessly stepping on people's toes.
Kind regards,
Your friendly neighborhood Linux guy
Re: (Score:3, Informative)
``Are you a troll?''
No, I'm quite serious. But I might have led a few people astray by not stating my point more clearly.
Let me start by saying that I am *not* claiming Windows is more secure than your favorite Linux-based OS. Nor am I claiming it's the other way around. I believe the relative security of these systems is undeterminable. If anyone does come up with a good definition of relative security, and a test that yields meaningful scores and rules out bias, I'm all ears. For now, I am just going to s
Re: (Score:3, Informative)
Just out of curiosity, when was the last time you reviewed the the new source of an update to your linux system before compiling it yourself? If not, how do you know somebody didn't sneak some vulnerable and/or malicious code in there?
I don't know, but I have a better chance than with Windows.
The continued prevalance of Windows XP brings Windows' security record down substantially, but even given modern software I only trust Microsoft to ship me vulnerable malware anyway.
Oh what rubbish (Score:2)
First you need remote access to my home machine, which is behind a NAT'd router and doesn't expose any services outside. That means that drive-by scanning won't work, and even if it did you'd have to find your way in via the only open port - ssh.
My systems in the commercial space are properly firewalled. It's a bad thing if anyone has shell access to them at all, let alone root.
Re: (Score:2)
Re: (Score:3, Informative)
You don't necessarily need shell access, just the ability to run a binary as any user.
This could be done, for example, if it is a web server and there is a PHP script with a vulnerability. If a hacker can run arbitrary PHP code, then they can run code to accept an upload of the binary.
Once the binary is uploaded to a world-writable directory such as /tmp or /var/lib/php/sessions,
the hacker can use the ability to run arbitrary PHP code again to invoke fchmod(), make the binary executable then use th
Not running it... (Score:5, Insightful)
And good lord god almighty, what 12 year old wrote this code, that they think having function names like put_your_hands_up_hooker() makes them cool?
Re: (Score:2)
Testing it in a quick throw-away VM (e.g. in VirtualBox) is always instructive though. Just don't run it on your real machine.
Re:Not running it... (Score:5, Informative)
And good lord god almighty, what 12 year old wrote this code, that they think having function names like put_your_hands_up_hooker() makes them cool?
This is copied directly from Ac1db1tch3z's exploit.
So the answer is Ac1db1tch3z thinks function names like put_your_hands_up_hooker() makes him cool.
Re:It appears to be safe. (was: Re:Not running it. (Score:5, Informative)
Is anything bad going to happen to you if you compile and run that C code? As far as I can tell, no.
You are very likely correct in thinking that adding yet another anonymous recommendation on the internet will make more people run the code. However, this is Slashdot, where the users are slightly more security aware than on an average internet site.
You see, If I were to attack all those nifty linux boxen out there, what would be a better attack vector than advertising your exploit on slashdot, which is known to accept almost anything on the front page, and yet is very likely to contain the biggest active linux user community on the nets? By looking at the code it seems obvious that the tool contains enough binary code to contain an exploit or three. If it is never used in a malicious way, it is somewhat difficult to say. So, outside a security lab setting, it is hard to tell if the provided code is not the exploit itself. Definitely "You are probably getting hacked right now! Check for viruses for free!" has been one of the more common attack vector against Windows users.
Whatever the case, I would not recommend running code that looks like this:
static char dis4blens4sel1nuxhayettgdr64545[] and
static int wtfyourunhere_heee(char *out_release, char* out_version)
Re: (Score:3, Funny)
Looks like a poor mans attempt at humour.
I'd say from looking at it those were a bunch of sensible #defines before the code was released and in a fit of humour said author thought it would be funny to do a find and replace on the original ALL_CAPS_SENSIBLE_NAMES.
It just looks cheap, if you ask me.
Now back in my University days we had to implement the producers consumer problem in lisp and whilst I don't have the code to hand I do remember that I came up with the poem the code was going to say _before_ I wro
Re:Not running it... (Score:5, Funny)
This is all really transparent.
You obviously get __yyrhdgdtfs66ytgetrfd to turn into __yyy_tegdtfsre by the addition of a reverse polish goto callback, an obscure function performed by overloading TMAGIC_66TDFDRTS and calling it every clock cycle.
Using PREPARE_GGDTSGFSRFSD and OVERRIDE_GGDTSGFSRFSD is standard procedure when dealing with credentials that are formatted in octal precision trinary floating point, and reverting them via REVERT_DHDGTRRTEFDTD is a result of taking GGDTSGFSRFSD and applying the ')(' operator.
And, of course, any competent CS professional who passed his first freshman year introductory course knows that gggdfstsgdt_dddex is the result of your cat walking across the keyboard.
FUD (Score:5, Insightful)
C'mon now. As others have pointed out, and has been mentioned earlier on /., this is a local root exploit. It's bad, it affects a lot of users (in theory), but to write this is to simply spread fear for most of those using Linux.
Why? Because the systems that inexperienced users run also happen to be those with a few, generally trusted users. Think netbooks. Sure, all local root exploits are bad and should be patched asap. But that doesn't mean "you're probably being rooted as I type this". It means that a remote attacker needs user-level privileges (say, with a browser or plugin vulnerability) first. Since Ubuntu and probably other major distros have already patched this, and the default settings for updates on these systems is to check fairly frequently, most end users will have the patched kernel quickly.
That leaves multi-user systems. The admins of these servers certainly benefit from finding out about the vulnerability asap, and they did (including through previous stories here). By now, though, most admins should have something in place if they don't have full trust in their users. If they don't, they should definitely be looking at whether this was exploited.
The bottom line is that there are many local root exploits which come out every year. This is the latest one, with a patch already available. Responsible admins of multi-user systems are used to dealing with this, and home users are almost certainly going to be patched before it causes any issues. For them, the latest Flash vulnerability is more worrisome. Even the extremely rare remote exploit of a service isn't usually an issue, since most modern distros don't start much of anything by default (including ssh, IIRC).
Re: (Score:2)
Absurdly sensationalistic line in the summary.
Slashvertisement (Score:5, Insightful)
As a long time user I get the option to disable advertising. I don't. I even whitelist Slashdot in Adblock because I support the site and the banner ads are rarely obnoxious.
These poorly disguised articles-as-ads are quite annoying though. Just make KSplice pay for a banner like everyone else.
Comment removed (Score:5, Insightful)
Forget the self-advertisement, it's a real issue (Score:4, Informative)
The situation appears to be exactly as described by Ksplice.
CVE-2010-3081 has been discussed on RedHat forums and elsewhere.
The Ac1db1tch3z exploit published on the full disclosure list http://seclists.org/fulldisclosure/2010/Sep/268 [seclists.org]
does indeed appear to contain a backdoor (0p3n1ng th3 m4giq p0rt4l).
From the comments, the vulnerability was found in 2008 and the exploit has been used by the author for some time, and may have been circulating in the underground. When the vulnerability was found and disclosed by Ben Hawkes, the exploit was published to a wider audience.
A number of sysadmins may well have run the exploit on their systems to prove to themselves that this was a real threat. In doing so they may unknowingly have left a backdoor.
More commonly, proof-of-concept exploits posted on full-disclosure lists are crafted by security researchers, do not contain backdoors, and are relatively easy to read. In this case, the disclosed exploit is crafted by a hacker, may well contain a backdoor, and is written with leetspeak runtime messages and obfuscated code.
I admit I do not fully understand the code in the exploit or in the detection tool, or indeed the nature of the backdoor. However, on a Fedora 9 system, running the detector says there is no backdoor. After the exploit is run, the detector says there is a backdoor, so
the exploit must have changed the state of the system in some way. The detector looks for 3 separate backdoors; the one on my
test system disappears after reboot. As I thought the fix was to update the kernel to a patched version, which requires a reboot, I'm not sure how the backdoor could survive. I do not see how having the backdoor is riskier than having an unpatched system.
I can say, though, that the vulnerability exists in stock kernels 2.6.25 - 2.6.36, and was back-ported by RedHat into 2.6.18 used /proc.
in RHEL 5 (hence CENTOS 5). As stated by others, an unprivileged user account is required in order to exploit the vulnerability, which exists only on 64-bit x86 systems which also can run 32-bit code. One published mitigation step, which does not require a reboot, is to disable 32-bit compatibility mode by writing into
LOL (Score:3, Funny)
did anyone check the source code for that diagnose command?
static void put_your_hands_up_hooker(int argc, char *argv[])
WTF?
Re: (Score:3, Interesting)
1. MS & Windows shills may laugh about this, but only because they feel your pain. Beyond that, what does making this statement even mean?
2. 64bit hardware is cheap. You can buy an AMD64 X2 5000 Dual Core CPU for 38 bucks shipped.. add a mobo for another 45 and if you need ram, another 50. eBay for more savings
Re: (Score:2)
Dang, my 3 year-old laptop, mid-level (at best) when it was news, runs 64-bit operating systems, and so does the $200 desktop I just built for my mom. There's plenty of decent 3-4 year-old hardware available used for dirt cheap that is 64-bit. this isn't a new thing any more, and you don't have to be rich. That comment just sounds odd in 2010, unless you are not in an English-speaking country or Western Europe.
Re:Bad Publicity... (Score:5, Interesting)
Microsoft already felt the pain, because the Xbox 360 hypervisor got owned by the same exact hole . It would almost be the same instruction-by-instruction identical bug were it not for the fact that the 360 is a PowerPC system and this is an x86_64 hole. Yes, they, too, used a 32-bit compare to check the system call humber, then indexed into the array using the full 64 bits, exactly the same bug that caused this Linux hole.
Re: (Score:3, Funny)
Obviously both copied from SCO. Namely their 64 bit code.
Re:Bad Publicity... (Score:5, Insightful)
There is something to be said though about going to a 64bit operating system. The fact that there are a little more than twice as many general purpose registers in the CPU available means that code can be compiled to not need to do memory fetches anywhere near as often which means that the code will run faster. the extra addressing space has always been a red herring argument (e.g. i only need it if i have more than 4gb of ram).
Re:Bad Publicity... (Score:4, Informative)
Actually, the extra virtual memory space program-side is far more important than the extra physical memory space ever was. Typically, a 32-bit program is limited to 2GB of address space, including actually used ram, memory mapped files, reserved but unused pages (e.g. the stack growth area), memory mapped device memory (e.g. graphics mem) and the program and its dlls. Thanks to fragmentation of the address space by all of these, a program can fail to allocate memory without even getting close to 2GB of ram use. I could, as a proof of concept, write a program which will fail to allocate a 512MB block while only using kilobytes of ram, simply by requesting one 4kB memory page from every 512MB through the address space.
64-bit software resolves that problem (at least until we get programs trying to allocate exabytes of ram in one block)
Re:Bad Publicity... (Score:5, Informative)
I have 64 bit hardware but I run x86 based distros. 64 bit is only good for the extra ram maybe to the desktop user. And there still is a lot of issues getting older programs to run on a 64 bit distro.
The x86_64 architecture has more registers than i386 and can do some operations 64 bits at a time rather than 32 bits. This means that programs compiled to run on a 64 bit architecture are often significantly faster than those compiled to run on 32 bit architectures.
I think an average figure is 20% faster or so on the same hardware -- you get this simply by installing a 64 bit distribution and using 64 bit binaries. Your system can probably still run 32 bit binaries (if it has the right libraries) but they won't be faster.
The advantages go beyond a larger address space.
Re:Bad Publicity... (Score:5, Informative)
Going to 64 bit means your instructions will be 64 bit, which means doubling the cache mem usuage.
Not true. x86 and x86_64 both use a variable-length instruction encoding. You actually get slightly better instruction density with x86_64, because a number of instructions that used to only work with eax now work with any target register, so for a couple of bits extra in the longer version of the instruction you avoid two register-to-register moves.
Pointers are 64-bit, but you'd need your program to consist entirely of pointers for this to double cache usage. In practice, you do see a small increase in data-cache usage, but it's offset by other things.
From performance point of view, if you don't really need 64 bits ( probably most of users will be fine with 4GB ram in next years) stay at 32 bits.
If we were talking about PowerPC or SPARC, you'd be (basically) correct. x86-64, however, is not just x86 with 64-bit pointers. It also gives you these other advantages:
Re: (Score:3, Interesting)
... until you get closer to 16GB of RAM and you start running out of lowmem (especially on older 2.4 kernel systems).
Re: (Score:3, Insightful)
Re: (Score:3, Interesting)
this is an exploit to gain "root" (administrator) access not a rootkit which is a malicious program built to hide itself from the operating system.
But the exploit leaves a backdoor (hell, it's right there in the summary) which *is* what a rootkit does.
Rootkits do typically hide themselves -- but only so they aren't removed, so they can provide root access at a later date. Their primary function is to provide root access at a later date -- which this exploit does, according to the summary.
Re: (Score:3, Informative)
You are using the word in the layman sense, disregarding it's origins. Why do you think it's called rootkit? It's a term used to describe a "kit" of software that allows the attacker to regain root access later on. Patch login to always allow a second predefined password, drop it into place, and you have yourself
Re: (Score:3, Informative)
Is it really difficult to understand?
Rootkit = software installed on a machine to serve some unsavoury purpose.
Backdoor = A method of accessing a system, generally hidden from the user and/or administrator of a machine
A rootkit can open a backdoor, but then so can poorly-configured machines, or kernel vulnerabilities. They are not the same.
Re: (Score:2)
Re: (Score:2)
Isn't it a little past your bed time, Mr. 1374367?
Re: (Score:3, Funny)
Re:Scriptkiddies these days (Score:5, Funny)
Re:Scriptkiddies these days (Score:5, Funny)
Re:Scriptkiddies these days (Score:5, Funny)
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
Would you kids get off my lawn?
Re: (Score:3, Informative)
Tell us how great OSS is.
OSS is great... my Ubuntu machines were already patched a day before the first scare stories about this exploit appeared here on Slashdot.
Re: (Score:3, Insightful)
Tell us how great OSS is.
Tell us how much better Linux is.
Tell us how badly Microsoft sucks.
I'm a PC, and using Windows instead of Linux was my idea.
I knew it was just a matter of time before Ballmer showed up as an AC on Slashdot.
Re: (Score:3, Funny)
post your ip address and root password and I'll check it for you.
Re:Need help patching/checking (Score:5, Funny)
post your ip address and root password and I'll check it for you.
127.0.0.1
hunter2