11 ms·
OS X 10.10.5 kernel local privilege escalation
- edude03 11y agoSo for anyone who hasn't tried it but is wondering about it - it works on 10.10.4 and 10.10.5, running the tpwn binary does drop you to a root shell. Looks like a weakness in the address randomization in OS X
- gizmo686 11y agoI haven't look into this vulnerability, but how could it be a weakness in address randomization? Isn't address randomization supposed to be a mitigation, to make it more difficult to exploit other vulnerabilities.
- qwertyoruiop 11y agoThere is no weakness in address randomization I relied on for exploitation. It relies on two distinct bugs, an info-leak to obtain a pointer to an allocation in the kalloc.1024 zone and a memory corruption primitive (deriving from a NULL pointer dfr. in IOKit) allowing me to OR 0x10 anywhere in kernel memory. To break kASLR I corrupt the size of a vm_map_copy struct, which allows me to read the adjacent allocation to the struct, which is a C++ object. First 8 bytes of said C++ object is a pointer to the vtable, which resides in __TEXT of some kernel extension. Since I can calculate the unslid address from userland without any issue, by subtracting what gets leaked with what gets calculated you get to know the kASLR slide. Just to clarify: The code execution part has 100% reliability rate. The kASLR leaking part does have some chance in it, however empirical evidence indicates that the failure rate is extremely low.
- XMPPwocky 11y agoSo you can bail out cleanly and go around for another run if the infoleak fails, yeah? Or do bad things happen up in kernelspace?
- qwertyoruiop 11y agoIf the heap info leak fails, I bail out cleanly. If the kASLR leak fails, it is usually because instead of hitting a vm_map_copy (the intended structure I need to corrupt), something completely unrelated is hit instead. If it happens to hit something different than expected, that's undefined behaviour usually ending up in a panic.
- bro-stick 11y agoMad props. If osx were s/xnu/minix 3-style, full microkernel/, sploiting Iokit as a least priv'd process, only it would get pwned and be limited to iokit's acls. Still bad, but it likely wouldnt have rights to exec a root shell. XNU kexts have way too much authority, and all the syscalls they each tack on compounds the attack surface to the total codebases of all Apple and third-party kexts. Because once you've found and symbolicated the not-really-hidden call table, you're pretty much able to do whatever. And with a mutating mem kext bug ...
- qwertyoruiop 11y agowhile I agree with you on the security benefits of a full microkernel, to be entirely honest, if you had access to just IOKit you could easily use a network card or an hard drive controller to get a physical memory write-what-where, which in turn would allow you to gain access to anything, plus the microkernel performance issues of e.g. having to context switch on interrupts.
- bro-stick 11y agoThat things may be broken is no argument against defense-in-depth and least privilege. By having smaller codebases and smaller system components, the attack surface is far, far smaller than say Linux. IOKit is shit as is, and a full microkernel would break it up into processes based on areas of responsibility. Also, that shows the hardware needs better bus- and command-level security to prevent such attacks. (Don't even get me started on closed firmware blobs or unverifiability of commercial cores.) Expecting a finished product of a new project would be unreasonable. Minix 3 is early on and not the only full microkernel out there. They will probably find an approach to reduce context switches if it's a mature optimization to make. An Android-like mobile/embedded platform would make a sensible research -> real use-case, minus Java.
- albertoleal 11y agoWhat about 10.10.3?
- qwertyoruiop 11y ago> tpwn has been tested from 10.9 to 10.10.5, but of course, your mileage may vary. 10.10.3 was actually the first version it was tested on.
- mbilker 11y agoAt least 10.11 isn't vulnerable
- landr0id 11y agoFor what it's worth I believe he also has a 0day for bypassing rootless. Check his Twitter.
- chatmasta 11y agoAnd here I was pressing "update later tonight." Thanks for the heads up!
- gargarplex 11y agoUnless you manually update to 10.11 you are still vulnerable
- deleted 11y ago[deleted]
- benwilber0 11y ago$ git clone https://github.com/kpwn/tpwn.git https://github.com/kpwn/tpwn.git Cloning into 'tpwn'... remote: Counting objects: 16, done. remote: Compressing objects: 100% (11/11), done. remote: Total 16 (delta 3), reused 16 (delta 3), pack-reused 0 Unpacking objects: 100% (16/16), done. Checking connectivity... done. $ cd tpwn $ make gcc *.m -o tpwn -framework IOKit -framework Foundation -m32 -Wl,-pagezero_size,0 -O3 strip tpwn $ ./tpwn leaked kaslr slide, @ 0x0000000008e00000 sh-3.2# whoami root sh-3.2# Shit's real. Edit: for those of you wondering, no, I didn't just run this willy-nilly. I read the code thoroughly and determined there were no side-effects aside from just the PoC dropping to a root shell.
- mmaunder 11y agoNice to see a 100% working widely exploitable 0day without any caveats that make it not real-world applicable. Local, so you need a non-admin account on the box which is kinda hard.
- benwilber0 11y agoI don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.
- brazzledazzle 11y agoYou can also use it to build malware that would normally be defeated by an unprivileged account right?
- benwilber0 11y agoA java applet could exploit this. With a little work, a Flash load in Safari (or really any browser) could probably exploit it. This is a real 0day.
- honest_joe 11y ago
- pit 11y agoI'm running 10.10.4, and it just crashed my Mac -- the "A problem has occurred" screen -- followed by a forced restart.
- ivank 11y agoIf I run echo '' | ./tpwn in a loop on 10.10.4, I get a kernel panic about 0.5% of the time, so you might have just gotten really unlucky.
- readme 11y agoYep, same result here on 10.10.4 heh.
- qwertyoruiop 11y agoInteresting. I am on 10.10.4 myself, and that's the OS I tested it on. tpwn has been tested from 10.9 to 10.10.5, but of course, your mileage may vary. the KASLR leak part is not 100% reliable, unlike the actual code execution which is. I'd be interested in panic logs to sort the issue out, if you could share.
- pit 11y agoHere's mine: https://gist.github.com/dad0731fc0373a9db858 https://gist.github.com/dad0731fc0373a9db858
- qwertyoruiop 11y agoYou are not vulnerable since you have SMAP!
- devy 11y ago10.10.5 kernel panic too. https://gist.github.com/anonymous/6a76b0793607c890c3ea https://gist.github.com/anonymous/6a76b0793607c890c3ea
- 11y ago
- thought_alarm 11y agoDoes it work on 10.11 with "rootless" mode disabled?
- kibibyte 11y agoI just tested on 10.11 with rootless being disabled, and it prints out "not vulnerable". I assume that if it doesn't work on 10.11, then rootless being enabled or disabled shouldn't make a difference. You still have a root user either way, it's just that if rootless is enabled, then the root user wouldn't be able to modify certain system directories, which could mitigate the consequences of such an attack if it did work.
- mbilker 11y agoIn the README it states the vulnerability is not present in 10.11.
- thrownaway2424 11y agoInteresting. This prompted me to look at my Mac and it's running 10.10.3, I never got a prompt to update to 10.10.4 or 10.10.5, but when I open App Store it tells me there's an upgrade to 10.10.5. I guess Apple managed to break the automatic update mechanism in 10.10.3. I wonder if this is related to the behavior where my iMac wakes up every minute starting every morning at 2AM. This is so obnoxious that I now turn my iMac off at night instead of putting it to sleep.
- DiabloD3 11y agoDid you try turning off Power Nap? Might have broken for you.
- joao 11y agoDo happen to have Adobe software installed? Perhaps something from Creative Cloud. It usually checks for updates at 2am, might be what its turning on your Mac from sleep. You will have to disabling automatic updates for that not to occur.
- gregwtmtno 11y agoAny way to protect a machine until apple publishes an update?
- qwertyoruiop 11y agoadd -no_shared_cr3 to your boot-args. it will have an hefty performance penalty, but if you value security over performance, it'll also protect you against a lot of (even 0day!) exploits.
- clebio 11y agoCould you provide some context for that? What does that flag do? How do you even set boot args for OSX? I have little context to OSX boot process, and would like to understand this better.
- facetube 11y agoI did `sudo nvram boot-args="-no_shared_cr3"`, and I think I see the (seemingly minor, at this point) performance hit. There's an explanatory comment in http://opensource.apple.com/source/xnu/xnu-2782.1.97/osfmk/x86_64/copyio.c http://opensource.apple.com/source/xnu/xnu-2782.1.97/osfmk/x... that seems to explain the feature, though not in detail.
- x0rg 11y agoWhat do you mean by "minor performance hit"? Could you provide some data?
- qwertyoruiop 11y ago'sudo nvram boot-args=-no_shared_cr3' will do the trick. The flag essentially prevents kernel from accessing userland memory unless special routines are used. Since the bug is a NULL pointer deference (which requires a read to userland memory in order to be exploited), exploitation becomes impossible. Due to this flag, however, your kernel will have to context switch every time a system call is done, which does have a noticeable performance impact. I will be releasing a KEXT to fix the bug soon.
- abhv 11y agoJust curious when you disclosed this to apple? I'm impressed by your skill in finding this, but not sure it is a good idea to make it so easy for people to weaponize like this.
- koenigdavidmj 11y agoApple traditionally has a poor record of responding to delayed disclosures. They burned that bridge a long time ago.
- Jerry2 11y agoNo they did not. Provide some evidence please. They've responded to hundreds of security issues and have credited people in security updates. About the only incident that I can recall is the Google one when Google automatically disclosed vuln's after Apple asked them for more time since it affected a very deep kernel issue.
- scintill76 11y agoMy vague recollections of past vulns (and admitted dislike for Apple) leads me to believe the parent comment, so I did some Googling. "A prominent security researcher warned Apple about this dangerous vulnerability in mid-2008, yet the company waited more than 1,200 days to fix the flaw."[1] But hey, they did credit him in the release notes! Granted, it's been several years now, but the parent did say "has a poor record", and a 3 year patch delay fits that description. More recently, there was the 4-day gap[2] between patching "goto fail" on iOS vs. OS X. While not really the same point as the parent comment, it reflects poorly on their commitment to rapidly fixing things. [1] http://krebsonsecurity.com/2011/11/apple-took-3-years-to-fix-finfisher-trojan-hole/ http://krebsonsecurity.com/2011/11/apple-took-3-years-to-fix... [2] http://www.cnet.com/news/apple-finally-fixes-gotofail-os-x-security-hole/ http://www.cnet.com/news/apple-finally-fixes-gotofail-os-x-s...
- MagerValp 11y agoApple fixes hundreds of vulnerabilities every year, and while they do drop the ball on one or two, those are exceptions, not typical. Reports to product-security@apple.com are responded to by a human within a few hours, and issues are typically patched in the next point release or the next after. I can see why you'd drop a 0-day if you were somehow ignored or they were stalling for years, but dropping it without even trying is just irresponsible. There's a lot of room for improvement in Apple's handling of vulnerabilities, especially with regards to response time and proactive work, but I don't see how deliberately waiting until 10.10.5 and then releasing a 0-day is helping anyone.
- facetube 11y agoDoes anyone know if 10.9.5 is vulnerable?
- qwertyoruiop 11y agoYes, it is.
- facetube 11y agoThanks.
- x0 11y agoOkay, this is really weird... after rooting, and pressing ^D or typing exit, I stay root ~/code/tpwn % id -u 503 ~/code/tpwn % ./tpwn leaked kaslr slide, @ 0x0000000005600000 sh-3.2# exit exit ~/code/tpwn # id -u 0 Edit: and it crashes iTerm2 after the last `id -u`. Managed to get a screenshot of what I'm talking about: http://i.imgur.com/foWgTBN.png http://i.imgur.com/foWgTBN.png
- jake223 11y agoThis does not happen for me. bash-3.2$ ./tpwn leaked kaslr slide, @ 0x000000000f800000 sh-3.2# exit bash-3.2$ id -u 501
- benwilber0 11y agoI replaces your user shell with a root shell. You're not "root" in that terminal.
- abhv 11y ago(1) Can I also ask how you found this? Were you fuzzing Iokit? (2) I'm trying to work through your ROP. Can you explain a bit more? Thanks.
- qwertyoruiop 11y ago1) I cannot really discuss specifics, but this particular bug would have been hard to find via a traditional IOKit fuzz, since it requires an invalid 'task' port passed over to IOServiceOpen. Most fuzzers use mach_task_self for that, and fuzz method calls/traps/properties/etc. 2) When IOServiceRelease is called, vtable+0x20 is called. the vtable pointer is controlled, at +0x20 I place a stack pivot, which sets RSP = RAX and pops 3 times. At 0x20 I place a POP RAX;RET gadget to let the chain begin after 0x28. Payload then locates the credentials structure, sets UID to 0 by bzero()ing, cleans up the memory corruption, decreases the task count for current user and increases task count for root. It then unlocks locks held by IOAudioEngine to prevent your audio from freezing up, and then returns to the userland context.
- qwertyoruiop 11y agofor the record: "At 0x20 I place a POP RAX;RET gadget" should be "At 0x18 I place a POP RAX;RET gadget".
- Mojah 11y agoSo we currently have 2 local privilege escalation exploits [1] available for Mac OSX. Apple appears to be in no rush to fix the first one, I wouldn't bet my money on this vulnerability getting a fix any time soon, either ... [1] http://bit.ly/1MrsdID http://bit.ly/1MrsdID
- MagerValp 11y agoThe DYLD_PRINT_TO_FILE exploit was fixed in 10.10.5.
- pacquiao882 11y agoIt was not fixed. There are currently no plans to fix it in 10.10. https://blog.malwarebytes.org/mac/2015/08/dyld_print_to_file-exploit-found-in-the-wild/ https://blog.malwarebytes.org/mac/2015/08/dyld_print_to_file...
- MagerValp 11y agoThat article is two weeks old. 10.10.5 was released 3 days ago, and the fix is mentioned in the release notes (under dyld): https://support.apple.com/en-us/HT205031 https://support.apple.com/en-us/HT205031
- klapinat0r 11y agoOne of the vulns in this exploit is fixed, rendering the exploit "useless" in 10.11. But start the mac hate train regardless - if facts don't count :)
- klapinat0r 11y agoWhy the massive downvotes when contributing to the issue he raises? > Apple appears to be in no rush to fix the first one, I wouldn't bet my money on this vulnerability getting a fix any time soon, either ... As it was clearly stated, there is a fix. Whether or not they'll release a 10.10 patch remains to be shown, and "no rush" is speculation. I'll never understand the HN crowd, but I guess providing additional information to clear up a false statement, while correcting OPs assumptions is against the rules.
- lisper 11y agoAnyone who is worried about privilege escalation on OSX should be aware that Apple ships sudo with requiretty disabled. This means that sudo authentication is not bound to the TTY in which the authentication occurred, and so using sudo for anything is tantamount to giving root to all of your processes. UPDATE: https://news.ycombinator.com/item?id=10069706 https://news.ycombinator.com/item?id=10069706