9 ms·
Linux Local Privilege Escalation via SUID /proc/pid/mem Write
- VMG 15y agoArch Linux, 3.2.1 .... [+] Executing su with shellcode. [1] 18663 segmentation fault ./a.out
- daniellockard 15y agoNeat. 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.
- zx2c4 15y agoYulp >=2.6.39 :-)
- daniellockard 15y agoStrangely, it doesn't work inside of screen. I'd bet that it's because of the parent ID?
- tptacek 15y agoClever. Reminds me of OpenBSD's rfork bug: http://www.openbsd.org/advisories/rfork.txt http://www.openbsd.org/advisories/rfork.txt
- zx2c4 15y agoI hadn't read about this oldie (97) before. Awesome! Good read.
- hartror 15y agoThe 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/ 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 http://kerneltrap.org/node/553/2131
- zx2c4 15y agoGoto 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?
- VMG 15y agometa: I don't see why it is necessary to downvote newbie questions on HN
- yew 15y agoGoto 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 15y agoRead the classics http://scholar.google.com/scholar?cluster=17147143327681396418 http://scholar.google.com/scholar?cluster=171471433276813964...
- zokier 15y agoI 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.
- exDM69 15y agoGotos 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 15y agoThe 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.
- adulau 15y agohttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=198214a7ee50375fa71a65e518341980cfd4b2f0 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...
- a1k0n 15y agoWell, 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 15y agoMakes 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 15y agoptrace() 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 15y agoI 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 15y agoI'm still clueless how su gets the same pid as his exploit... Maybe i will get it when it's not 4am
- 15y ago
- iuguy 15y agoThis 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/ http://www.attackingthecore.com/
- static_cast 15y agoIs 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 http://grsecurity.net/features.php
- lloeki 15y agoit affects only 2.6.39 and up. EDIT: sorry, misread the parent.
- static_cast 15y agoI 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.
- pferde 15y agoJust tried it on 3.0.4 with grsecurity enabled, and it didn't work, so there.
- static_cast 15y agoThanks. I guess It's finally time for me to move every machine to a grsecurity kernel.
- ColdAsIce 15y agoWould you be interested in a grsecurity distro?
- static_cast 15y agoI'd love to see up to date stable grsecurity kernel repositories for the major distributions (ubuntu, debian, rhel/centos) that provide patched versions of the distribution kernel. You can configure most of grsecurity via the sysctl interface. At the moment it is always a bit of hassle to patch & compile a kernel from hand even with the great debian/ubuntu kernel-package. I don't think I'll use an extra distribution. But something like a hardened LAMP/LAPP stack for shared hosting out of the box in a distribution would be great (I think in terms of easy chrooting of users and php, secure permissions, etc.pp) However, I guess everyone has different needs and there is no one size that fits for all.
- shanemhansen 15y agoJust tried this out on my ubuntu laptop (3.0.0-15-generic) and it worked like a charm. Scary.
- idonthack 15y agoI just tried this on someone's home server, but he's running such an old kernel that it didn't work at all. Scary.
- jon6 15y agoTried 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.
- lloeki 15y agoNo 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
- caf 15y agoHave you checked if Arch's su uses a relocatable text segment?
- ahv 15y agoAlso 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.
- zx2c4 15y agoThanks for the improvement. I've made the < modification in this commit: http://git.zx2c4.com/CVE-2012-0056/commit/?id=49174152d57ffc2fb7ab56b91211a3a0f78fbabb 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 http://git.zx2c4.com/CVE-2012-0056/commit/?h=mount
- asomiv 15y agoThere 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 15y agoIf you read the article it says that only versions >=2.6.39 are vulnerable.
- gioele 15y agoThe 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 https://news.ycombinator.com/item?id=3472618 [2] https://news.ycombinator.com/item?id=3473068 https://news.ycombinator.com/item?id=3473068
- foobarbazetc 15y ago"because distros do not compile `su` with PIE" Really? Every single distro I've tested has su compiled with PIE.
- gioele 15y agoFrom 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 15y agoHow 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.
- rzhou 15y agoOn 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 15y agoVery 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.
- zx2c4 15y agoThis version works on Fedora: http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c?h=fedora http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c?h=fedo...
- kmm 15y agoOn 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.
- rzhou 15y agoIt doesn't stop the exploit, as it is still possible to use ptrace to essentially dump the binary, even though it's not readable.
- ahv 15y agoOr if you know the distro, it is trivial to get the package containing the su executable and locate the address.
- kmm 15y agoI compiled it myself, so that is not an option.
- burgerbrain 15y agoPresumably they only need to guess the flags you used then. There is really not all that much entropy there. And I suspect doing so is fairly uncommon in production environments anyway.