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."
Re:*Yawn* Local Root Exploit (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:OSS Strikes Again (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:Patch on its way... (Score:1, Informative)
It appears to be safe. (was: Re:Not running it...) (Score:1, Informative)
I'm not the king of all C coders, and please for the love of all that is good and holy don't trust some random stranger on the internet, but I read the source and if it's doing anything bad, it's doing it quite sneakily -- more so than I'd expect the teenager who wrote the exploit source to be capable of, frankly.
Now, do I wish the ksplice guys would've cleaned up/de-obfuscated their 'borrowed' code to make it a little less alarming-looking? Yep. Do I wish they weren't doing their ridiculous Chicken-Little routine in a transparent attempt to move some product? Also yes. Could that binary be pretty much anything? Uh-huh.
Is anything bad going to happen to you if you compile and run that C code? As far as I can tell, no.
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: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:Oh what rubbish (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 the system's dynamic loader and execute the binary, as in
passthru("/lib/ld-linux.so.2 /path/to/some/exploit/binary");
Re:Bad Publicity... (Score:1, Informative)
Stop perpetuating this fucking myth. There are other good reasons to use a 64-bit build besides the address space it gets its namesake from. I can run crufty old 32-bit software just fine on a 64-bit Linux.
There have been plenty of benchmarks pointing to 64-bit being no worse and in many cases outperforming their 32-bit counterparts. Things like SSE being enabled for all 64-bit binaries by default with GCC, extra registers, NX bit, and so on all standard on 64-bit Linux machines.
As for compatibility, I want to know. WTF doesn't run on a 64-bit Linux that actually affects more than some obscure corner case that maybe 10 know about and three of which actually care about? I hear it all the time, but never actually see it. What is this compatibility problem?
Its just a bunch of crap that has been regurgitated on the internet because it once had some amount of truth many years ago. Go ahead with your i386 and i586 packages built for 1993 and act all smug.
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: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:*Yawn* Local Root Exploit (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 files can be accessed by arbitrary code based on security labels.
However, if there is also a vulnerability in the kernel. SELinux cannot stop a buffer overflow in a program from being used in conjunction with a kernel vulnerability, to run arbitrary code in kernel mode.
Basically: buffer overflow in a program + kernel escalation bug = SELinux or AppArmor fail
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: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:Ya (Score:2, Informative)
Yes it does. You are a zealot, interested in dogmatic belief what you believe to be the one and only way of doing things. Thus you insult anything that doesn't conform.
Re:Then perhaps do as the GP asks (Score:4, Informative)
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:2, Informative)
There are plenty of privilege escalation and remote access exploits on that site. Some patched, some unpatched (not everyone keeps up to date with updates). Did you even look at the list there?
Anyway, a lot of exploits there are remote access exploits. The exploit talked about in this story is a local privilege escalation exploit way down on the severity list and it was patched before it became public.
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: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.
There are two bugs (Score:2, Informative)
Just to clarify I understand that there are two zero day root-providing bugs. (Everyone talks about THE bug.)
CVE-2010-3301 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=36d001c70d8a0144ac1d038f6876c484849a74de [kernel.org] and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=eefdca043e8391dcd719711716492063030b55ac [kernel.org]
CVE-2010-3081 patched by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c41d68a513c71e35a14f66d71782d27a79a81ea6 [kernel.org]
Re:poorly described (Score:5, Informative)
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
Re:virus scanner (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 a rootkit. The techniques that rootkits developed to hide themselves have been borrowed by malware, and the term has been usurped too (in a similar fashion to what happened to the word "bricked", which now seems to mean "requires a power cycling or re-flashing".
That doesn't make that usage correct.
Re:Is Slashdot advertising now? (Score:5, Informative)
Oh it's not paid (Score:5, Informative)
Re:But wait (Score:4, Informative)
Re:Then perhaps do as the GP asks (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: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:virus scanner (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: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:poorly described (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:poorly described (Score:2, Informative)
Now, the question is: do you trust ksplice or even (as cited below) the naive http download?
Re:slashdvertisement ... and full of crap. (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.
Re:slashdvertisement ... and full of crap. (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 say that I don't know which of two complex systems is more secure.
Now, since I believe it is impossible to determine whether or not Windows is more secure or less secure than whatever OS you would like to compare it to, I think words like "the winslow assholes that don't understand shit about security and somehow think that this means that GNU/Linux is insecure and as bad as their shitty system" are uncalled for. Especially considering that Microsoft has been hard at work to improve the security of Windows, while popular Linux distros are making absolutely no haste with including security solutions that have already been developed. That is the point I was trying to make.
Maybe it's fun to point and laugh at the poor Windows-using sods and ridicule the poor security track record of their system, but, without a good security culture on our side, I'm afraid we might end up looking mighty foolish when the exploits start coming our way. And frankly, if our security culture consists of pointing and laughing and ignoring security solutions that _even Windows_ has adopted, I think we're in very bad shape. I don't care if we're doing better than someone else, I care that we aren't doing as well as I feel we should.