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