Slashdot Mirror
Linux Kernel Exploit Busily Rooting 64-Bit Machines
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."
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.
"Anyone who [rips a CD] is probably engaging in copyright infringement." - David O. Carson
Just a quick google search: http://secunia.com/advisories/41122
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.
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.
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.
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.
That exploit requires user interaction. Even then it doesn't provide administrator access. Try again.
-1 overrated isn't the same thing as "I disagree".
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.
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)
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.
Run the tool in TFA ./diagnose-2010-3081
Diagnostic tool for public CVE-2010-3081 exploit -- Ksplice, Inc.
(see http://www.ksplice.com/uptrack/cve-2010-3081)
$$$ Kernel release: 2.6.32-24-generic
!!! Not a RHEL kernel, will skip LSM method
$$$ Backdoor in LSM (1/3): not available.
$$$ Backdoor in timer_list_fops (2/3): checking...not present.
$$$ Backdoor in IDT (3/3): checking...not present.
If you're suspicious of the binary, download the source, examine it to satisfy yourself that it's not malicious, and compile it. It's not hard to figure out if you're affected - even a dummy like me can do it!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
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
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
Because Ksplice relied on the fact that the Slashdot editors don't edit anything to have their advertisement pass as an important story?
The /. editors fall hook, line, and sinker for these advertisements for Ksplice submitted by an 'anonymous reader' every 6-8 weeks. Get used to them.
"What kind of music do pirates listen to?" -Paul Maud'dib
"Yeeeaaarrrrr n' Bee!!" -Stilgar, Leader of Sietch Tabr
You mean, like the iphone and the pdf exploit that allowed any website to root it?
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:
I am TheRaven on Soylent News