Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X 10.10.5 kernel local privilege escalation

github.com

Post reply on HN
Print view View original

41–50 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#41

Post by facetube »

clebio wrote: post #39
qwertyoruiop wrote: post #34

Earlier quoted context omitted.

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

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

I 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/x... that seems to explain the feature, though not in detail.

Re: OS X 10.10.5 kernel local privilege escalation

#42

Post by facetube »

qwertyoruiop wrote: post #34
gregwtmtno wrote: post #30

Any way to protect a machine until apple publishes an update?

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

Thanks for the tip, applied.

Re: OS X 10.10.5 kernel local privilege escalation

#43

Post by koenigdavidmj »

abhv wrote: post #31

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

Apple traditionally has a poor record of responding to delayed disclosures. They burned that bridge a long time ago.

Re: OS X 10.10.5 kernel local privilege escalation

#44

Post by qwertyoruiop »

clebio wrote: post #39
qwertyoruiop wrote: post #34

Earlier quoted context omitted.

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

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

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

Re: OS X 10.10.5 kernel local privilege escalation

#45

Post by DiabloD3 »

thrownaway2424 wrote: post #20

Interesting. 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 m…

Did you try turning off Power Nap? Might have broken for you.

Re: OS X 10.10.5 kernel local privilege escalation

#46

Post by qwertyoruiop »

abhv wrote: post #40

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

1) 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.

Re: OS X 10.10.5 kernel local privilege escalation

#48

Post by XMPPwocky »

qwertyoruiop wrote: post #14
gizmo686 wrote: post #10

Earlier quoted context omitted.

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

There 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…

So you can bail out cleanly and go around for another run if the infoleak fails, yeah? Or do bad things happen up in kernelspace?

Re: OS X 10.10.5 kernel local privilege escalation

#50

Post by qwertyoruiop »

XMPPwocky wrote: post #48
qwertyoruiop wrote: post #14

Earlier quoted context omitted.

There 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…

So you can bail out cleanly and go around for another run if the infoleak fails, yeah? Or do bad things happen up in kernelspace?

If 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.
Post reply on HN