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.'"

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:*sits back*

[BobPaul]

Well, it's only a local exploit for one thing, so good like getting rampant Blaster style viruses based on it..

Second, it'll probably be patched rather quickly.

Third, it's one of a few holes, compared to the one of many holes found in windows...

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?!?

[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 more to exploit. If you look at something like Redhat, which is a distribution, you have more of a comparison, and you will find remote exploits.

Re:dude

[Anonymous Coward]

Summary for the lazy ones: These are four of the probably uncounted bugs which are known for months (if not years), reported to the maintainers but are still unfixed. Yes, we're speaking about the Linux kernel.

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:Copyright Poo Poo

[Anonymous Coward]

"Did I violate you buy hitting ctrl-c and ctrl-v?"

Not copyright. Because you copied a mere part of the work, and you did so for the purposes of criticism, and you aren't making any money off it. Almost anybody would classify that as "fair use". Copyright has limits. It does not give the author absolute control in all circumstances and forms.

Re:Failed on RHEL

[Anonymous Coward]

$ gcc -o exploit exploit.c -I/usr/src/linux/include/
exploit.c: In function `scan_mm_start':
exploit.c:425: error: storage size of 'l' isn't known
exploit.c:425: error: storage size of `l' isn't known
exploit.c: In function `check_vma_flags':
exploit.c:545: error: label at end of compound statement

gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)

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!

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

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.

Re:what's that sound I hear?

[DiscoOnTheSide]

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

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 exploit somewhere, it is still not possible to access other parts of the system. (B-class and A-class OS' do not "need" a system admin account, since you can define specialised pseudo users that can do exactly what is needed for a given task and no more.)

Then, there are systems like OpenBSD which have been audited to hell and back. OpenBSD has had one provably-usable exploit in living memory.

Then, you've various security software that's out there. eg: Using OTPs w/ S/Key or OPIE for passwords, enforcement of strong passwords, IPSec w/ strong host authentication on all network connections, etc.

In theory, there is nothing to prevent someone from combining all of these elements to produce a hardened OS that is impervious to both physical and logical attacks, both locally and remotely.

In practice, nobody would spend the time and/or money on that level of security for normal use. Ok, the NSA might, but that's not strictly "normal use". It's also unlikely they'd make such an OS readily available. (They've done wonders with SE-Linux, and the declassifying of Skipjack and SHA has made a world of difference in cryptography, but that's not quite the same as Open Sourcing a bullet-proof system.)

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.

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?

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.

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

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 it properly.

Re:Local Access is always a trump card

[jonadab]

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

In the phrase "local root exploit", the word "local" doesn't mean local in
the sense of physically present, but in the sense of needing to already have
user-level access. If you combine it with a non-root remote exploit, the
two together add up to the equivalent of a remote root exploit.

In other words, this is definitely something we want to fix.

As far as securing a system against physical access, that's a whole nother
kind of hard. At bare minimum you need an encrypted filesystem with a key
that isn't stored and so has to be entered by an authorized user every time
the filesystem is mounted, and then on top of that if you make sure that the
machine, if left unattended, suspends running processes to disk and then
unmounts the filesystem, and if you're both paranoid, obsessive, and tireless
when it comes to bughunting, you potentially could develop a system that has
a reasonable degree of security against an attacker with physical access --
but "a reasonable degree" does not mean "impenetrable" -- there are still
hidden cameras, keyboard logging devices, and the like, to say nothing of
rubber hose cryptanalysis.

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 exploit, it would need to be a bug in the keyboard driver, the input layer, or possibly a user-space program that uses raw keyboard entry. I don't think screwdriver level access counts, since you can lock your machine up. Filesystem bugs could be exploitable via usb drives, floppy disks, cf drives, etc... Those are physical exploits rather than local.

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, task_size=0xc0000000, map_base=0xbf800000
[+] vmalloc area 0xcbc00000 - 0xd77c0000
Wait... \
[+] race won maps=40880
VMAs reversed
expanded VMA (0xbfffc000-0xffffe000)
[!] try to exploit 0xcc98c000
[+] gate modified ( 0xffec90b0 0x0804ec00 )
[+] exploited, uid=0

sh-2.05b$ whoami
micheal
sh-2.05b$ cd /root/
sh: cd: /root/: Permission denied
sh-2.05b$

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: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: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 the solution is to break the environment into sandboxes. Inside each sandbox, however, there is no security; all the security is at the front door.

So why, when security flaws are caused by applications doing something that the Windows API documentation specifically instructs them not to do, is this considered a flaw in Windows?

It's not, but that doesn't stop some people from blaming Windows anyway. It also doesn't prevent 3rd party developers from writing insecure apps, that (when trusted by an admin) can break the system. Notice that Microsoft threatens to stop supporting interactive services in the docs, to try and get developers to clean up their act, but they will never do it, as Microsoft has compatibility as too high a priority.

Exploit uses deprecated GCC extension

[Anonymous Coward]

The exploit has label at the end of a compound expression and doesn't compile in ISO compliant compilers like gcc 3.4.x. Change

__asm__("movl %0, %%esp" : :"m"(old_esp) );
goto out;
}
signal(SIGSEGV, vreversed);
val = * (unsigned*)(lib_addr + PAGE_SIZE);
out:
}

to

__asm__("movl %0, %%esp" : :"m"(old_esp) );
return;
}
signal(SIGSEGV, vreversed);
val = * (unsigned*)(lib_addr + PAGE_SIZE);
}