OS X 10.10.5 kernel local privilege escalation

Post by bro-stick » Sun, Aug 16, 2015, 4:13 AM UTC

benwilber0 wrote: post #29

mmaunder wrote: post #23

Earlier quoted context omitted.

I can't reply to your post lower in the thread, but saying a java applet and flash app can exploit this? It's a C program that requires a local account on the box. You would need to break out of the java sandbox into local unprivileged shell access before you could exploit this via java. Same with flash - you would need a flash exploit that breaks you out of the sandbox before you can exploit this. In other words, yo…

Java applet and Flash 0days exist in the wild whether they're published or not. I am confident that 0days for them exist and are actively used right now. So you're going to tell me that this is a non-issue because it's "unexploitable"?

Post by clebio » Sun, Aug 16, 2015, 4:15 AM UTC

qwertyoruiop wrote: post #44

clebio wrote: post #39

Earlier quoted context omitted.

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…

Post by Jerry2 » Sun, Aug 16, 2015, 4:31 AM UTC

koenigdavidmj wrote: post #43

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.

Post by bro-stick » Sun, Aug 16, 2015, 4:43 AM UTC

qwertyoruiop wrote: post #50

XMPPwocky wrote: post #48

Earlier quoted context omitted.

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 by [deleted] » Sun, Aug 16, 2015, 5:03 AM UTC

clebio wrote: post #53

qwertyoruiop wrote: post #44

Earlier quoted context omitted.

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

Well, I was more looking for an explanation of what "no shared CR3" means. What is CR3, how do I know to go to that option as a way to disable this exploit. And, coming from a Grub/ubuntu perspective, when you say "boot args", I think of the boot loader, which for Grub is configured with config files (text files) or else at boot-time, via the Grub menu. I know OSX has a single-user mode, but don't know of a way to ed…