Linux Local Privilege Escalation via SUID /proc/pid/mem Write

http://blog.zx2c4.com/749

by zx2c4 • 15 years ago

199 55 15 years ago

blog.zx2c4.com

Neat. I updated one of my VMs running debian Sid from 2.6.32 kernel to 3.2.0-1-686-pae just to see if it would work. It works on the 3.2 kernel. Kind of scary. I checked to see if I had access to any 'real world' servers running and exploitable kernel and none of them seemed to.

zx2c45• 15 years ago

Yulp >=2.6.39 :-)

daniellockard2• 15 years ago

Strangely, it doesn't work inside of screen. I'd bet that it's because of the parent ID?

tptacek• 15 years ago

Clever. Reminds me of OpenBSD's rfork bug:

http://www.openbsd.org/advisories/rfork.txt

zx2c45• 15 years ago

I hadn't read about this oldie (97) before. Awesome! Good read.

hartror• 15 years ago

The use of goto[1] in this code surprises me. Isn't use of it still generally shunned?

Appearing in the Linux kernel makes me reconsider my avoidance of it[2]. A quick google throws up a discussion with Linus in 2003[3] which can be summarised as: don't blame the tool, blame the programmer and as a tool goto has a place.

[1] XKCD comic on the subject http://xkcd.com/292/

[2] On my infrequent visits to C++ land, I generally live in Python land where goto doesn't exist.

[3] http://kerneltrap.org/node/553/2131

zx2c45• 15 years ago

Goto is common for error out code in C. The code that uses that mentioned in the blog code is from the linux kernel, not any exploit code.

But please, for the love of god, can we not make this discussion thread an extended conversation on the merits or horrors of goto? Pretty please?

yew• 15 years ago

Goto is actually relatively common in C code. As in this case, it's usually used for error handling in much the same manner as exceptions might be. The document "/usr/src/linux/Documentation/CodingStyle" actually recommends such usage.

fhars• 15 years ago

Read the classics http://scholar.google.com/scholar?cluster=171471433276813964...

zokier• 15 years ago

I addition what others have said, I'd emphasise that goto for error handling is fine in C, but in C++ it is usually unnecessary because C++ has exceptions and RAII.

VMG2• 15 years ago

meta: I don't see why it is necessary to downvote newbie questions on HN

exDM69• 15 years ago

Gotos are common in C for error handling because the other alternative of doing an if/then/else with all the error handling is so verbose. It's used to work around the lack of exceptions in C.

You still should not use gotos for regular control flow. And jumping backwards with goto is bad practice in most cases.

chalst• 15 years ago

The reason why Linus Torvalds and others prefer to handle errors using goto is that it avoids the main branch of the code receiving an additional indentation, as it would if it were wrapped in a conditional. Not to do so would make the code less readable.

Note that these gotos are always local jumps (that is, they are in the same code block), at the same indentation level, and they are forward jumps (so the control flow is much the same as for a conditional). They are easy to understand and audit, and not similar to the goto examples that Dijkstra criticised for making code hard to reason about.

arnnr• 15 years ago

This. Also python's execeptions can be treated as limited goto's: http://docs.python.org/faq/design.html#why-is-there-no-goto

shanemhansen• 15 years ago

Just tried this out on my ubuntu laptop (3.0.0-15-generic) and it worked like a charm. Scary.

jon6• 15 years ago

Tried this on 2.6.31.1 but it hung while waiting for the fd from the child.

  [+] Executing child from child fork.
  [+] Opening parent mem /proc/11045/mem in child.
  [+] Sending fd 3 to parent.
  [+] Waiting for transferred fd in parent.

I waited 2-3 minutes.

<edit> Argh, I need 2.6.39, sorry.

adulau2• 15 years ago

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...

The commit message (10 months ago) when the vulnerability has been introduced is quite interesting:

"With recent changes there is no longer a security hazard with writing to /proc/pid/mem. Remove the #ifdef."

I'm wondering how long it will take in a proprietary software without any good commit messages to discover such bug...

jronkone• 15 years ago

What makes you think that proprietary software doesn't have good commit messages?

adulau2• 15 years ago

I mean commit messages accessible to a large potential audience that could review them.

a1k0n• 15 years ago

Well, that's mind-bending. I couldn't figure out how/where the actual exploitation of su happened since it seemed to require some careful synchronization, until it hit me: His exploit essentially starts up a process which, when it writes to stderr, is writing to its own memory. Then, it lseeks to the correct position which would cause su, when writing its error message, to overwrite its own exit() with shellcode. And then it just exec()s su with these preconditions, and it works. Dang.

Animus7• 15 years ago

Makes sense.

But this strategy for me begs an important question: why the <bleep> is it even possible to write directly to memory over an fd? I get that "everything is a file", sure, but you've already got ptrace for insane use cases that require trashing another other process's memory (i.e. a dev toolchain).

I've been twiddling bits in C(++) almost every day for over a decade and I've never once felt the need for such a feature, except when theorizing about exploits. Alas.

forgotusername• 15 years ago

ptrace() lets you read a word at a time per syscall (slowwww), presumably /proc/pid/mem allows mmap'ing full regions in a single syscall.

seclorum• 15 years ago

I have used the ability to write to /proc/pid/mem to TEST safety-critical software intended for deployment on Linux systems. The apps I wrote were designed to ensure that altered binaries were not being run on the target system - in order to test the effectiveness of this "TEXT Segment check", I wrote many test cases to overwrite memory using this mechanism. Its useful in that context.

gcb• 15 years ago

I'm still clueless how su gets the same pid as his exploit...

Maybe i will get it when it's not 4am

caf2• 15 years ago

PID does not change on execve().

_b8r0• 15 years ago

This type of clever problem with confused trust relationships is remarkably common in OS Kernels. If you'd like to know more about finding, exploiting and fixing kernel bugs then I'd highly recommend Attacking the Core[1] as an introductory book.

[1] http://www.attackingthecore.com/

static_cast5• 15 years ago

Is a grsecurity[1] patched kernel safe? I only have a machine with a 2.6.32-grsec kernel, so I can't test the exploit.

In the features list they state:

    /proc/pid filedescriptor/memory protection

But I'm unaware how they implemented that.

1: http://grsecurity.net/features.php

lloeki2• 15 years ago

it affects only 2.6.39 and up.

EDIT: sorry, misread the parent.

static_cast5• 15 years ago

I know. I want to know if someone with a kernel >=2.6.39 and applied grsecurity patch can successfully use this exploit or if grsecurity protects from this exploit.

VMG2• 15 years ago

Arch Linux, 3.2.1

    ....
    [+] Executing su with shellcode.
    [1]    18663 segmentation fault  ./a.out

lloeki2• 15 years ago

No workie here on ArchLinux:

    $ uname -a
    Linux sekhmet 3.2.1-1-ARCH #1 SMP PREEMPT Fri Jan 13 06:50:31 CET 2012 x86_64 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux
    $ ./mempodipper
    ===============================
    =          Mempodipper        =
    =           by zx2c4          =
    =         Jan 21, 2012        =
    ===============================
    
    [+] Waiting for transferred fd in parent.
    [+] Executing child from child fork.
    [+] Opening parent mem /proc/3196/mem in child.
    [+] Sending fd 3 to parent.
    [+] Received fd at 5.
    [+] Assigning fd 5 to stderr.
    [+] Reading su for exit@plt.
    [+] Resolved exit@plt to 0x401a60.
    [+] Calculating su padding.
    [+] Seeking to offset 0x401a57.
    [+] Executing su with shellcode.
    zsh: segmentation fault  ./mempodipper

caf2• 15 years ago

Have you checked if Arch's su uses a relocatable text segment?

ahv2• 15 years ago

Also works on Arch with minor modifications.

Had to change 'exit@plt' to '<exit@plt' where it searches for the relevant function and change the program run from /bin/su to /bin/mount.

zx2c45• 15 years ago

Thanks for the improvement. I've made the < modification in this commit: http://git.zx2c4.com/CVE-2012-0056/commit/?id=49174152d57ffc...

And made a separate branch for /bin/mount: http://git.zx2c4.com/CVE-2012-0056/commit/?h=mount

asomiv2• 15 years ago

There are a lot of local root exploits in Linux the past few years. But ever since Linux dropped the stable-unstable version numbering scheme, different distributions ship a wide variety of kernels + their own patches instead of "the latest kernel" because the latest may not necessarily be stable. How do I find out which local root exploits my distribution's kernel is vulnerable against, and how do I find out how quickly they get fixed? I'm on Debian 6 right now.

splidge• 15 years ago

If you read the article it says that only versions >=2.6.39 are vulnerable.

gioele2• 15 years ago

The presented vulnerabilities is so easy to exploit mostly because distros do not compile `su` with PIE and lose the ability to hide memory addresses with ASLR. Just few days ago there has been a discussion about how PIC/PIE is only a performance loss and should not be present in modern Unix systems.

[1] https://news.ycombinator.com/item?id=3472618 [2] https://news.ycombinator.com/item?id=3473068

foobarbazetc• 15 years ago

"because distros do not compile `su` with PIE"

Really? Every single distro I've tested has su compiled with PIE.

gioele2• 15 years ago

From the article:

> It turns out that su on the vast majority of distros is not compiled with PIE, disabling ASLR for the .text section of the binary!

I tested on Ubuntu 10.04 LTS, likely to be installed on many servers, and 11.04. On these two versions `su` has not been compiled with PIE.

Edit: just to make things clear: in these Ubuntu versions su is compiled without PIE, but are not vulnerable because they have kernels < 2.6.39.

mikeash• 15 years ago

How long would it take to brute-force ASLR for this exploit, given that execution is under control of the exploiter, and can thus be tried many times in quick succession? I recall that some OSes only have a small number of different ASLR permutations, but I don't know the details, and especially not the details of Linux's implementation.

rzhou2• 15 years ago

On 32-bit systems, it's feasible to brute force, as there are only about 12 bits of entropy. There are a lot more random bits on 64-bit systems, so I don't consider it brute force to be that practical there.

joshbaptiste• 15 years ago

Very good read.. this post is actually "Hacker News", Seems my Fedora hosts are not susceptible as they compiled with -pie and the kernels at work haven't been updated in sometime.

zx2c45• 15 years ago

This version works on Fedora: http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c?h=fedo...

kmm2• 15 years ago

On my system, all SUID binaries are executable yet not readable, e.g.

  $ ls -l /bin/su
  -rws--x--x 1 root root 52144 Mar  5  2011 /bin/su

Doesn't this effectively stop the exploit? It still works when I insert the <exit@plt> function address, but I don't think it's possible to trace this without root rights, which kind of defeats the purpose.

rzhou2• 15 years ago

It doesn't stop the exploit, as it is still possible to use ptrace to essentially dump the binary, even though it's not readable.

ahv2• 15 years ago

Or if you know the distro, it is trivial to get the package containing the su executable and locate the address.

Linux Local Privilege Escalation via SUID /proc/pid/mem Write

Related Stories