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

Comments

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

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: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:What, no remote exploit?!?

[Foolhardy]

Shatter attack

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 and window station 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 will prevent messages from leaving the job.
MS guidelines specifically forbid 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 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...

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.