Local Root Exploit in Linux 2.4 and 2.6

Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"

*sits back*

[Anonymous Coward]

*awaits justifications and explanations of why this is nothing like Microsoft*

Re:*sits back*

[ackthpt]

*awaits justifications and explanations of why this is nothing like Microsoft*

Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

Re:*sits back*

[Lodragandraoidh]

"We are sorry, all circuits are busy..." - Microsloth Help Desk

"You can download the fix

• here

..." - Any Linux website within a days (perhaps hours) of the report.

Re:*sits back*

[Laur]

And dont forget, recompile the kernel!

Then run a different distribution. On Debian a new kernel is just an apt-get away, no compiling required (unless you need something special of course). I'm sure other distros are similar.

Re:*sits back*

[darc]

Yeah yeah, that's the responsible thing to say. But responsible stuff is sooooooooo boring. I mean, if we were all responsible people that wanted stability, we'd all be running kernel 2.2, Apache 1.1, many year old revisions of programs patched to all heck, never install any packages that aren't yet at least of legal age, and still tout ISA support as a bleeding edge feature.

Hmm. Wait, I think I just described Debian Stable.

*is hit by a gigantic potato from the debian crowd*

(Yes, I am aware that stable is called Woody, and the last version was called Potato. But if I said "is hit by a gigantic woody..." i'd probably get murdered. Oops.)

Re:*sits back*

[identity0]

I was going to make a comment about "rounding up workers for underground C mines", but I figured that didn't sound painful enough.

So, I would like to remind Linus that I will be very useful in rounding up workers to toil in the underground Perl mines.

Re:*sits back*

[EnronHaliburton2004]

Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.

Dude, he was our new overlord like 10 years ago, get with the program...

Re:*sits back*

[Jay Carlson]

It's quite a bit like Microsoft in one way.

The uselib() system call is quite old. It was introduced in Linux 0.12 as a quick way to support dynamically loaded, statically linked libraries.

The way shared libraries worked was like this:

libc was compiled and linked like a normal program would be, except that its start address was set to (say) 0x400b0000. printf() would be at (say) 0x400cb110.

Main programs were linked down at 0x08048000 or so, and knew where in memory printf was. The kernel knew how to load your main program and jump to its start. However, there was nothing but a segfault waiting for you at 0x400cb110 initially. So how did the kernel know what shared libraries to load?

Well, one possibility was to put a list of library paths into the executable and teach the kernel to load 'em. Ugh. Didn't SCO do that?

Instead, the linker would add a little assembly language stub to start your main program. It looked a little like:

uselib("/lib/libc.2.so")
uselib("/lib/libm.2.so")

and the uselib syscall would graft the contents of those files directly into memory, in the same fashion the kernel knew how to load the main program. Voila, calling printf at 0x400cb110 will now work.

Eventually, this switched to a single uselib("/lib/ld.so") so we could have search paths and dynamic linking. But it was a pretty good start.

After we all switched to ELF, uselib wasn't such a good idea, as ELF allows some more clever things than just direct-mapping the whole executable at a fixed address. /lib/ld-linux.so switched to using mmap(). If you haven't run an a.out or libc5 executable, it is extremely unlikely your machine has ever invoked this syscall.

As part of the a.out->ELF transition, the uselib() syscall was preserved. It allowed old-style fixed location libraries to be dressed up in new ELF clothing. A few years ago I tried uselib() on MIPS, and had a miserable time trying to get GNU ld to make a library the kernel didn't reject. I gave up.

So how is this bug like Microsoft? The bug is in a mechanism that is a holdover from an older, simpler time. Nobody saw a good reason to take it out. And it didn't get much security scrutiny until somebody said, "hey, what's THAT still doing in my OS? I bet it's got bugs!"

your wait is over.

[twitter]

*awaits justifications and explanations of why this is nothing like Microsoft*

While I can't justify the difference, I'll tell you that there is one if we don't see any regularly recurring network born auto-root that's so bad it threatens the top level domain servers. It's not like someone cracked kernel.org and owned it for three months [slashdot.org] injecting whatever they pleased into the codebase. One good explanation of the difference is that Marketing dorks who do little more than buy other's code can't maintain

Re:your wait is over.

[dedazo]

It's not like someone cracked kernel.org and owned it for three months

No, just GNU.org http://uk.builder.com/manage/work/0,39026594,20277 728,00.htm [builder.com]

Re:*sits back*

[gmuslera]

One word: "LOCAL"

The concept of local security is usually ignored in the MS side, that someone already using the machine could access/modify things that he should not.

Most Microsoft related advisories/reports are centered in remote vulnerabilities, things that only have a meaning for a network connected machine accessing services or being accessed from outside.

Of course, a local vulnerability could be exploited if some piece of software (i.e. a web app) have an entry point, and what should be running

*raises hand*

[marcello_dl]

errm...

SElinux?

(don't even get started on the easyness of setting policies for selinux, you get offtopic: post the link of a MS equivalent else you lose the argument :D )

Re:*sits back*

[Allnighterking]

For one thing it works. For another we admit it. For a third we don't have to lie about it.

Oh yeah. I've never yet seen a local exploit on Windows. This is true. The number one exploit from Console on Windows is usually turning on the box. Once I do that I really don't care what you've done. I own you and I'm root (Yes even with WinXP SP2 and the supposed user password protection.)

Note too to be fair. ANY box where I am at the console I don't need fancy exploits and code to grab root etc. Once I

Re:*sits back*

[gweihir]

*awaits justifications and explanations of why this is nothing like Microsoft*

This is a local exploit. These are so common in Windows that nobody talks about them anymore. Most reported Windows exploits are remote exploits (exploitable over the net) or application exploits, e.g. in the bundledbrowser or Email apps.

Really no comparison at all

Re:*sits back*

[Anonymous Coward]

Second, it'll probably be patched rather quickly.

I can only laugh out loud. Read this story [lwn.net] for example.

Re:*sits back*

[ip_fired]

* When you copy newlen into len, this could cause len to be negative if newlen truly is an unsigned int.

* It all depends what copy_from_user does. Does it check to make sure that len is sane? Is it an unsigned int, or a signed int. If it's signed, then a negative value is obviously not sane and should be rejected.

Where did this code come from? What file please?

Combined with another flaw, it could be bad.

[khasim]

All that this needs is to be combined with a vulnerability that grants remote access to a machine and you have a serious problem (provided that the remote access allows them to exploit this).

All flaws need to be fixed. Even ones you don't think are very important because they could be exploited together.

It doesn't matter how many holes Windows has compared to Linux. The exploits are usually scripted and tied to a port scanner. If you're vulnerable, you will be cracked.

That's why multiple levels of securi

Re:Combined with another flaw, it could be bad.

[sloanster]

All that this needs is to be combined with a vulnerability that grants remote access to a machine and you have a serious problem (provided that the remote access allows them to exploit this).

- and if we had some ham, we could make ham and eggs, if we had some eggs... seriously, we could play "what if" games all day long, but let's not blow this issue all out of proportion. It is what it is and nothing more, and at the end of the day it will have resulted in none of the sort of disasters we see on a regular basis with the microsoft platform...

Re:Combined with another flaw, it could be bad.

[miu]

Seriously, we could play "what if" games all day long, but let's not blow this issue all out of proportion

Dangerously wrong. It is incredibly common for web applications to have holes that allow execution of arbitrary programs. A "local only" vulnerability is the other half of the weakness an attacker needs to turn a simple coding or configuration error into a root exploit.

Re:Combined with another flaw, it could be bad.

[sloanster]

I keep seeing posts here about somebody setting their grandma up to run $DISTRO but nobody will admit then that said grandma might be easily duped into clicking that link in that e-mail to get the latest cookie recipe (or some other nonsense) and woops! there goes a local exploit and now her box is Pwn3d!

This sort of thing is not as easy as you suppose - in the windows world one can write a quick vbscript to cause all sorts of nonsense, but on a unixlike platform such as Linux there would be a considerably higher barrier to the success of such shenanigans.

It sounds like you're saying this isn't such a big disaster because there aren't that many Linux users...and that strikes me as a ridiculous point of view.

I see you've failed to understand my statement. I'm at a loss as to how my meaning could have been contorted from "a potential local exploit isn't going to cause the sorts of internet disasters as we see regularly with windows" into the bizzare statement "hardly anybody uses linux" - (strokes beard thoughtfully). We can put the lie to that sort of thinking by simply considering the apache webserver, it's market share, and security record, compared to the microsoft iis web server, it's market share and it's security record. And by "security record", I don't mean "counting the number of advisories from all linux vendors and comparing them to the number of advisories from microsoft", which is a meaningless comparison. No, I mean "compare the frequency, scope and severity of the security incidents associated with the two platforms", which would be much more telling.

Re:Combined with another flaw, it could be bad.

[sloanster]

The reason that's not possible TODAY is security through obscurity, which isn't something you should be proud to rely upon. The only thing you can prove through that line of argument is that Linux has no significant desktop marketshare.

I don't think you understand what security through obscurity is, and your reasoning is the same old joe sixpack thinking that we've heard before, that linux has a better security record only because it has a smaller user base than microsoft windows. By that same logic, apa

Re:*sits back*

[EvilAlien]

Compare apples to apples unless you are also willing to count vulnerabilities in all the GNU stuff, other opensource apps included in major distros, etc. There are far more vulnerabilities announced on a frequent basis for Open Source due to its strength: transparency. The actual numbers of vulnerabilities/flaws in Microsoft's closed source code is unknown until a vulnerability is detected and announced. Open Source also has the potential of a vulnerability coinciding with a patch since those who detect can also fix due to the openness of the code... Microsoft relies on "responsible disclosure" to ensure that they are able to release fixes with vulnerability announcements. Closed source means that announcements can be scheduled and planned for monthly "patch day"... open source means that a vulnerability and maybe the fix can be announced at any time, and therefore with greater frequency.

So, as far as the number of vulnerabilities, you can't convince me (as someone in the industry) that Linux "wins". You also can't convince me that the Linux kernel has far fewer holes found than the Windows kernel. The available evidence does not support the claim. However, that doesn't mean that the Open Source development method tends towards greater potential quality than the closed source method.

Also, remember that a local root vuln is only 1 remote non-root vuln away from becoming effectively a root vulnerability. Too many people who think they are responsible admins try to ignore or downplay the seriousness of local root vulnerabilities.

Thats enough rambling for the day...

Re:*sits back*

[m50d]

I'm willing to compare apples to apples, but if you want me to include the major apps installed on linux distros, you should also include lots of external software for windows - some of it third party, since there doesn't seem to be an MS alternative to (for example) the GIMP.

Patch available (testing)

[zCyl]

Second, it'll probably be patched rather quickly.

There is a preliminary patch in testing for the 2.4 series.

Look here. [kernel.org]

The file is patch-2.4.29-rc1.bz2

Note that it's in TESTING, because it probably needs testing yet. But if you're desperate to patch it up quickly at your own risk, then there you go.

Re: bugs in code

[AceCaseOR]

3rd party developers make buggy software too

And when some third-party developers write buggy code, they really write buggy code. Remember "Return to the Pool of Radience: Ruins of Myth Drannor". Now that was a buggy game!

Re: bugs in code

[FireBreathingDog]

I don't know what sigma level Microsoft is at but with 2 defects per 100 is 360000 per 1,000,000 lines of code. That puts them at a sigma level between 3 and 4. The Majority of software makers are below that. Yet if MS were six-sigma (they sell software that tracks it) they would have only 61 defects for those 18 million lines of code.

That's why you should always put curly braces on their own lines, to increase your total lines of code. Helps achieve a more favorable sigma.

Re:*sits back*

[VertigoAce]

In this case, local means you are logged in as a user already. It does not mean you are physically at the machine. This kind of exploit is why Remote User Exploits are actually a serious issue even though they might not give you root access directly. All you have to do is combine an exploit that gives you user-level permissions with a Local Root Exploit to get root access.

Copyright Poo Poo

[Anonymous Coward]

Read down to the Credits on the link and you see this line:

Credits:
========

Paul Starzetz has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.

Did I violate you buy hitting ctrl-c and ctrl-v? Yeah copyrights stink even in free and open source realm. Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.

isec.pl's guys rule

[diegocgteleline.es]

Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):

Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking [www.isec.pl]
Linux kernel do_mremap() local privilege escalation vulnerability [www.isec.pl]
Linux kernel do_mremap VMA limit local privilege escalation vulnerability [www.isec.pl]
Linux kernel setsockopt MCAST_MSFILTER integer overflow [www.isec.pl]
Linux kernel file offset pointer races [www.isec.pl]
Linux ELF loader vulnerabilities [www.isec.pl]
Linux kernel IGMP vulnerabilities [www.isec.pl]
Linux kernel scm_send local DoS [www.isec.pl]
Linux kernel uselib() privilege elevation [www.isec.pl]


Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code [www.isec.pl]

Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.


(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)

Re:isec.pl's guys rule

[gbjbaanb]

Perhaps someone should offer a job to those guys so they can audit parts of the kernel better

Yeah, lol. Microsoft.

Oh sorry, I though you meant, 'someone should offer these guys a job so they can audit the kernel better to find *more* exploits, allowing MS to publicise all these anti-linux holes' ;)

Re:Copyright Poo Poo

[_Sprocket_]

Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.

What's interesting is the preface that shows up on several lists:

Hi all,

first of all I must comply about the handling of this vulnerability that I reported to vendorsec. Obviously my code posted there has been stolen and plagiated by Stefan Esser from Ematters. The posting containing the plagiate will follow. Now I have been forced to release the full advisory however another disclosure timeline have been agreed on vendorsec. Sorry for the inconvenience.

Followed by:

Hi all,

first of all I must comply about the handling of this vulnerability that I
reported to vendorsec. Obviously my code posted there has been stolen and
plagiarized in order to put the blame on Stefan Esser from Ematters and
disturb the security community.

I really apologize to Stefan Esser for the inconvenience and thank him
for his cool reaction - the plagiarism did work.

Further steps must be taken to investigate the security leak on vendorsec.

No, think about it ...

[Seraphim_72]

Actually copyrighting the exploit is kinda cool. Say you are a admin, and some kid gets fresh and tries this out. "Hey kid, not only am I nailing you to the wall for this, but I am turning you over to the guy who "owns" it and you get to pay him a nice fine." No, I think that is it pretty hilarious that the code is copyrighted.

Sera

How the hell

[BoomerSooner]

How do people find this stuff? Amazing. Open source is astounding.

When do I get my kernel update?

Re:How the hell

[PornMaster]

Have you tried kernelupdate.kernel.org?

Oh, wait. This is Linux. You'll have to reply to 5-10 questions before we can offer an answer. :)

Re:How the hell

[BoomerSooner]

I meant when. Whoops!

Re:How the hell

[pasde]

When do I get my kernel update?

No worry. I ve already installed it for you.

Failed on RHEL

[SuperQ]

I compiled included code at the end of the advisiory, this was the output on RHEL 2.4.21-20

% ./test

[+] SLAB cleanup
child 1 VMAs 65525
child 2 VMAs 65392
[+] moved stack bfff8000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xdf400000 - 0xfe5f2000
Wait... -
[-] FAILED: try again (Cannot allocate memory)
Killed

Re:Failed on RHEL

[ericzundel]

I tried it on a couple of boxes. It tries to exploit a race condition, so it won't necessarily work all the time. However I have tried it a few dozen times and haven't gotten it to work yet. (One RH 7.3 box and one RH 9.0 box)

Re:Failed on RHEL

[ericzundel]

Hmm. right after I posted that, it came through on the RH 9 box:

./elflbl -n2

[+] SLAB cleanup
child 1 VMAs 65527
child 2 VMAs 65527
child 3 VMAs 65527
...
child 18 VMAs 63322
[+] moved stack bfffb000, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xdf800000 - 0xfedbb000
Wait... \
[+] race won maps=49205
expanded VMA (0xbfffc000-0xffffe000)
[!] try to exploit 0xe2d25000
[+] gate modified ( 0xffec903c 0x0804ec00 )
[+] exploited, uid=0

sh-2.05b#

Re:Failed on Debian

[ecliptik]

I got it to compile and run on Debian Sarge with gcc version 3.3.5, kernel 2.4.25-1-386, and it says it succeeded, but I'm still my normal UID, just drops me into a bourne shell:

micheal@jezebel:~/dev$ gcc -v
gcc version 3.3.5 (Debian 1:3.3.5-5)
micheal@jezebel:~/dev$ uname -a
Linux jezebel 2.4.25-1-386 #2 Wed Apr 14 19:38:08 EST 2004 i686 GNU/Linux
micheal@jezebel:~/dev$ ./elflbl -n5

[+] SLAB cleanup
child 1 VMAs 65527
child 2 VMAs 65527
child 3 VMAs 65527
child 4 VMAs 28849
[+] moved stack bfffe000, tas

won't be exploted here!

[Dominatus]

It's a good thing I've got the patch downloa

Once again...

[Sheetrock]

A2M swapping rears its ugly head. This semaphore system has worked well to date, but perhaps should be mandated (i.e. code will not work unless a semaphore is set.)

They've got a pretty good record. Unfortunately, kernel-level stuff is nasty -- how do you fix embedded devices?

Re:Once again...

[grub]

how do you fix embedded devices?

Shouldn't be much of an issue, most embedded devices don't have user accounts.

Embedded devices?

[rewt66]

How do you fix embedded devices? Um... you mean how do you update/patch the code on the embedded device so that a local user can't escalate to root?

First of all, for many embedded devices, this isn't an issue. I mean, if you're an attacker, what are you gonna do once you get root? If the owner can't patch the OS, you probably can't install a rootkit either. Sure, you can DOS it, but if you're physically at the device, you can DOS it just by hitting the power button.

However, manufacturers of all embedd

Funny you should mention...

[Yaa 101]

I need no exploit to gain root privileges, I just login...

Re:Funny you should mention...

[garcia]

Bah, logging in sucks. I just use the sudo hack to gain root access...

garcia@shitbox:~$ sudo su
shitbox:/home/garcia#

woot, the hack works like a charm. They should really include the C source for the hack so all the kiddies can use it.

lets hope no-one discovers

[Anonymous Coward]

su

This could help

[datadriven]

... if I forget my root password.

Local Access is always a trump card

[Delusional]

Is there ever a time when you can consider your systems secure against an attacker with physical access?

Re:Local Access is always a trump card

[rjstanford]

Well, yes and no. There's a difference between being vulnerable to those with physical access (pretty much always true, but very limited) and vulnerable to those folks with the ability to run something on your machine locally (fewer than true remote users, but much higher in number than those folk with actual physical access). All you need for this exploit is a way to run unpriv. code on the machine. Note that using a network exploit to run said code is a great way of gaining access - suddenly the fact that your webserver is running as "nobody" doesn't really matter any more.

Re:Local Access is always a trump card

[rjstanford]

That won't necessarily save you, I'm afraid. If the machine is running any software that through feature or an exploit allows a remote user to run uploaded code, you're screwed. That's because as soon as you're running that code, it can use this type of hole to grant itself full root privileges. Once its done that, what makes you think that its going to be nice enough to check /etc/passwd and spawn a requested shell (not that that would be terribly useful for this type of remote exploit). At that point,

Re:Local Access is always a trump card

[arose]

Local as in "need user level access" not "need screwdriver level access".

Maybe.

[jd]

It depends on how secure you want your system. Intel's new chips with built-in DRM, for example, would allow you to have a system where you couldn't remove the hard drive and install it elsewhere, or reboot into something that'll give access, using a live OS CD.

Atmel, amongst others, produce encrypted RAM. If you don't have the key, you can't read the memory. That's pretty secure, if you ask me.

Any OS with B1 (or better) security has comprehensive mandatory access controls, so that if you DO find an exp

Local vs. Remote

[Gherald]

Obviously if it is local if it is exploitable from the console. But can it be exploited remotely through ssh if one already has a user account?

Re:Local vs. Remote

[rewt66]

In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.

A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.

Re:Local vs. Remote

[Bloater]

yes, local normally means user-space software running on the system can exploit it. That means any program you type in, compile, and run from a physically attached keyboard, or through ssh, or even any code that a local daemon or client program is tricked into using. That means possibly one of those old libpng buffer overflows can be used to insert code into mozilla and eventually get root - you have patched those seemingly unimportant security announcements haven't you?

To be limited to a physical access e

Only in select modules?

[Leadhyena]

Doesn't this only work if you compile the ELF and a.out support into the kernel, or am I mistaken? If so, it's just yet another reason to be VERY CAREFUL what you enable in the kernel when you compile it, lest you enable something that you don't need and is yet exploitable.

I should mention that enabling ELF format is still highly recommended (after the patch for this is released of course) and unless you do special programming work in linux then enabling a.out format is not recommended.

making APIs secure takes time

[jeif1k]

"uselib" is a Linux-specific extension, and, as a result, has received much less real-world testing than traditional UNIX system calls. Keep in mind that the traditional UNIX system calls have received millions of man-years of real-world testing in large user communities likely to attempt both remote and local exploits. It is not surprising that Linux-specific extensions are at a much greater risk of containing serious security problems.

Re:making APIs secure takes time

[Alan Cox]

No this was just a dumb locking bug. You could reasonably argue that some of the kernel API's for do_brk were less than well designed but thats more historical accident.

Its fixed by 2.6.10-ac6 along with the setsid crash and some other corner case bugs Coverity found.

Distribution restrictions

[cperciva]

COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.

Is it just me, or is this mind-bogglingly stupid? A security advisory which can't be redistributed freely? Imagine if the same approach was taken to important warnings in the real world -- "There's a tsunami heading towards you... but you're not allowed to redistribute this warning to all the people around you without my permission."

Security advisories should be in the public domain.

Re:Distribution restrictions

[Jerf]

Is it just me, or is this mind-bogglingly stupid?

It's irrelevant anyhow. If you didn't sign a contract to keep it secret, they have no grounds to gag you. They can copyright their exact words and can (and probably should*) control the distribution of those words, but copyright does not give them any protection of the facts contained within. And neither does anything else.

For the same reason, when you are accidentally mailed something with one of those "you must delete this immediately if you are not the intended recipient", unless it is actually and literally classified, you have no obligations. It's just to scare people.

The legal system has a ways to go before you can be obligated by an email out of the blue, or a random announcement on a webpage taking rights not granted to them by copyright but implementing no real access control (i.e., attempting to obligate you after you downloaded a page; it might work if you make it a condidion of reading but not just out of the blue, after the fact).

*: Reputation is important. One of the reasons copyright should not be straight-out abolished is its usefulness in making sure that words are correctly attributed and can be quality controlled, a virtue you are so used to you may never even think about until it is gone.

I'm safe!

[ferratus]

It doesn't work on my Gentoo box running 2.6.9 so I'm safe. This machine will not be hacked.

It's a good thing I have telnet running on that box so that I could try it remotly though.

/me flips off isec.pl

[htmlboy]

why did they release exploit code before a fixed kernel was released and mirrored throughout kernel.org? and on a friday afternoon?

i'm not too impressed with the timing of this announcement, and i have to wonder what their motives were. it doesn't hurt their cause that slashdot is advertising for them.

please, people. there's no reason that a situation like this should ever happen.

Here's the exploit (-;

[MacJedi]

#!/bin/sh
echo "1|nux r007 3xp10|7 by 1c4m7uf"
cd /tmp
cat >ex.c <<eof
int getuid() { return 0; }
int geteuid() { return 0; }
int getgid() { return 0; }
int getegid() { return 0; }
eof
gcc -shared ex.c -oex.so
LD_PRELOAD=/tmp/ex.so sh
rm /tmp/ex.so /tmp/ex.c

Re:Here's the exploit (-;

[Erich]

For those not so versed in the way things work, here's what this does:

getuid() and geteuid() get the "user ID" and "effective User ID". This scripts makes a library that makes these functions return 0 -- signifying that you are the superuser. It doesn't actually make you the superuser, but it implements functions that pretend you are.

Anyway, then it compiles these functions into a library and tells the loader to link that library first. So when you start up a shell, it will call getuid() to figure out your userid, and your new library will tell it that you are userid 0. The shell prints out the root prompt instead of the regular one.

But this in no way actually gives you root privs, if you go to edit /etc/passwd you will not be able to.

Pretty funny joke, though, kind of like telling everyone that they can ftp to 127.0.0.1 using their own regular userid and password and find all the porn they could ever want...

what's that sound I hear?

[Trepidity]

It's the sysadmins of University email and webservers across the country going apeshit as suddenly the entire student body potentially has root...

Re:what's that sound I hear?

[scottking]

I wish there was a +1 Used 'Apeshit' in a sentence modifier.

Re:what's that sound I hear?

[DiscoOnTheSide]

meh, it just means I get to bitchslap anyone who tries this out of the university :)

Fix is merged in mainline already

[spurious cowherd]

See the message on The kernel mailing list [theaimsgroup.com]

raw diffs to for those brave souls who want them

Yawn!

[erikharrison]

What news is this? There have been local exploits in the Linux kernel before, and there will be again. This is less news than the Debian break in a while back - that was worth mentioning because a major Linux installation was comprimised with an unknown kernel vulnerability. But come on! The last few 2.4 kernels (IIRC) have included patches to fix local root exploits. Marcello didn't even rush those out the door. This exploit certainly doesn't seem especially unusual nor was there an exploit in the wild.

Newsflash kids! Linux isn't perfect! Certainly not Linux specific API extensions like uselib. Move along, this isn't the kernel vulnerability you are looking for.

Thank God...

[mackman]

Thank God I run Firefox!

For those who say "just a local exploit..."

[erroneus]

This means only that it must be used in conjunction with a process that is exploitable. Let's say, for example, apache was running and there was an exploit available to it. Well, most people would say "oh well.... can't trash the whole machine, the apache user doesn't have the rights." Well once apache is compromised, they can likely find a way to inject the local exploit code for the apache user to run. Once that's accomplished, apache user becomes root user. From there, the machine is 0wned to borrow a word.

Yes it's serious but I expect a fix shortly...

Is this real?

[agurkan]

May I recommend that Do not run this code if you can not understand what it is doing.
For all we know, this is a social engineering trick to spread some malicious code. Let's wait until some official folks eg. CERT, or your vendor/distribution responds. Are the people who released this code have some credibility that can be verified independently?

Unfortunately not the only one...

[greppling]

LWN article [lwn.net] about some more local security holes in Linux published today. The advisory does contain some harsh words about Linux security as well.

I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.

And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.

Re:Unfortunately not the only one...

[Anonymous Coward]

From TFA:

Between December 15th and today, Linus has committed many changes to
the kernel. Between January 2nd and today, Andrew Morton has committed
several changes to the kernel. 3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability. A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well. Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, i

Doesn't work?

[andfarm]

Segfaulted in sys_mmap2 when I tried it on a couple machines. For what it's worth.

That's right! Stick with 2.0.36

[Tom7]

That's why I've been sticking with 2.0.36 all these years. I haven't seen a security advisory for it in ages.

Dangit...

[catdevnull]

All those MCSE dorks down the hall are gonna give me sh*t for the next week.

Reminds me of a punchline to my favorite Scottish joke:
"Aye, lad...ya screw ONE goat..."

Re:What, no remote exploit?!?

[Ly0n]

since windows is more "single user" oriented, most local exploit flaws on windows do not get very much publicity.

For instance, shatter attacks are still a very large threat for multi-user windows systems

Re:What, no remote exploit?!?

[Foolhardy]

Shatter attack [tombom.co.uk]

It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.
B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.

First, there are ways to divide the window handle space into seperate parts, each securable with desktop [microsoft.com] and window station [microsoft.com] objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects [microsoft.com] will prevent messages from leaving the job.
MS guidelines specifically forbid [microsoft.com] the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.

Re:What, no remote exploit?!?

[Foolhardy]

I thought MS issued a hotfix for this a couple of years ago, around about the time XP SP1 was released, I thought.

Sending unsolicited WM_TIMER messages to another process has been blocked, but there are still other messages that can cause arbitrary code execution. The messaging model was inherited from versions of Windows way before security was considered. Sending messages (even the unsafe ones) to other processes can't be blocked or it would break way too many things. No security isn't an option in NT, so

Re:What, no remote exploit?!?

[pVoid]

Because the API has a structure: any object running in the current interactive desktop is considered part of that security context. Period. It's not a question of having left the door unlocked. In fact, anyone who defends that "rm -rf /" should not be hidden from the user can have no legitimate protest to this system design.

Consoles apps (not consoles themselves*) are not vulnerable because they are not part of the windowing system, they output to the window via stdout/stdin/stderr.

As for X, I don't kn

Re:What, no remote exploit?!?

[iabervon]

The linux kernel does very little interpretation of remotely-provided data. There are occasionally remote exploits (e.g. the Ping of Death in '97 or so), but that code has now been pretty thoroughly checked at this point. Most of the code which cares at all about the validity of data is interfaces only accessible locally.

Re:What, no remote exploit?!?

[Michalson]

Because Linux is a kernel, with no real knowledge or direct interaction with outside (remote) sources, while Windows is a kernel plus a GUI plus a ton of other services. Remote exploits aren't found in the Windows kernel, they're found in the application/service part of Windows, on the Linux side these buggy, infinitely exploitable services are given individual names like "sendmail" and "bind".

Re:What, no remote exploit?!?

[EnderWiggnz]

you mean to tell me that people have found exploits in bind and sendmail?

no way - they're perfect open source programs. model programs, so to speak.

next, you'll tell me that x is a crufty, inefficient kludge.

Re:What, no remote exploit?!?

[lakeland]

Incidentially, the finding of exploits found in bind and sendmail has really slowed to a crawl.

It seems that, even though they were written in different times and without security as the first concern, a sufficiently large number of bug fixes will eventually result in code that is almost as secure.

Re:What, no remote exploit?!?

[Richard_at_work]

Because 'Linux' exploits are kernel exploits, because Linux is a kernel, as people are so fond of pointing out, which actually has very little to do with remote entities other than the well looked at TCP/IP stack. Windows on the other hand is an Operating System, which includes things other than the kernel, including system daemons/services, user interface code, web browsers, and a whole host of other things.

Long story short, while it may be shoddy, MS Windows is a LOT bigger than Linux, and thus theres

Re:What, no remote exploit?!?

[shaitand]

Windows is a distribution, an operating system IS a kernel.

Semantics aside however, your right, comparing apples to apples gives a better comparison.

The minimal windows install versus a minimal redhat install is a better comparison and there aren't many linux distros in which you'll ever find remote exploits in the core minimal install.

It's still not perfect though, pretty well everything can be stripped from a linux box to harden it. A windows box cannot be hardened since most remote exploits are in cor

Re:What, no remote exploit?!?

[csnydermvpsoft]

Linux is just a kernel. A more accurate comparison is Linux distributions vs. Windows. Bugs are discovered all the time in application software that is bundled with many distributions. The difference, however, is that if there's a bug in a Linux app, you can uninstall/disable it until it is fixed, while many of the apps shipped with Windows can't be easily removed.

Re:What, no remote exploit?!?

[shaitand]

This would be false. It's not the gui front end most people recognize as IE that is the problem. It's the renderer and trust model behind it.

The same flawed engine is used to display your folders (turn on the location bar and type in a url, see what happens), your desktop, and your email in Outlook express and even most 3rd party apps. If you use AOL, it uses IE to render web pages. When you view a help file, guess what it's IE. It is impossible to avoid IE on a windows system.

By choosing a browser which

Re:What, no remote exploit?!?

[proverbialcow]

It should be simple enough - if you have remote access to the machine already (i.e. you want to r00t a machine at school or whatever.) Log in, run the exploit from the shell, bingo bango bongo - you're root.

It's not like the code magically runs on your machine at home...

Re:

[account_deleted]

Comment removed based on user account deletion

Re:What, no remote exploit?!?

[mm0mm]

where as every nearly every Windows flaw is remotely exploitable?

Don't you think it's more convenient for you to be able to hack multiple machines over LAN? Another reason to choose Windows over Linux.

Re:What, no remote exploit?!?

[the_mad_poster]

It can be exploited by any user or process that can compile and load executables on the machine.

Re:That's why MS will rule the world.

[spac3manspiff]

Mod parent -1 denial.

Typical biased Slashdotter numbers

[Anonymous Coward]

Right, let's compare the flaw in a single kernel versus the ENTIRE OPERATING SYSTEM of Windows, GUI, shell, and associated apps like Internet Explorer as well as user-ran executable attachments in Outlook, which have nothing to do with Microsoft.

What happened to all the "Linux is just the kernel" stuff? Oh, that's right, we were bashing Microsoft.

Besides, if you mean "past year" as 2005, then this means Linux is first out of the gate.

Re:Typical biased Slashdotter numbers

[Libor Vanek]

Show me some user-space program in Linux, which could gain you root? THAT's the main reason, why UN*X are generally more secured then Windows - absolutely clear separation of user rights. In Windows there lot of SW has to run at insanely high priorities so any bug in them leads in machine hacked. In Linux if there is bug e.g. in Mozilla, all it can do, is delete your documents but can never "attack" any other installed SW. Of course - there are some setuid SW in Linux, but there are only very few and they d

Linux is not invulnerable

[Azureflare]

Linux is not invulnerable to exploits, as we all know. Therefore, why are people making such a big deal out of it?

It is important to know about, in my opinion. But that's just so we know we need to patch our kernels. Simply the fact that a root exploit has been found does not mean we should go about reposting the same types of stuff that has been posted endlessly before in similar articles on slashdot.

I prefer linux because it's free. It's also pretty stable and secure, which is nice. But I just like

Major Difference

[Tony]

Why is using MS update any different than downloading this new linux fix?

First and foremost, the terms to which you must agree before you download and install. The MS downloads and patches often come with "interesting" end-user license agreements. Meanwhile, with the Linux kernel download, you can do whatever you like, including (*gasp*) fix it yourself, if you have the ability.

Secondly, when you use Microsoft update, you don't know what is getting installed. With many things, like XP service pack 2,

Re:How do universities, etc. deal?

[JonMartin]

Well, it's Friday at 1730 as I type this. I'm about to download 2.4.29-rc1 (which has a fix). Then I'll shoe horn some oddball patchballs into it (they haven't applied cleanly in a few kernel revs), config, make and test. If all goes well I'll be rolling it out and rebooting our ~150 Linux boxes by 1900.

In short, this one is too big (too exploitable, too public) to wait until Monday.

My life would be so much easier if profs didn't have such a hard on for Linux and let us admins install OpenBSD. Good thing I get paid overtime. Oh wait, I don't.