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

21–30 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#21

Post by benwilber0 »

mmaunder wrote: post #17
benwilber0 wrote: post #15

Earlier quoted context omitted.

I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.

Go ahead and give us an example.

What user does your web browser run as? Do you use chrome? Any Chrome extensions use the NDK?

Re: OS X 10.10.5 kernel local privilege escalation

#22

Post by jsprogrammer »

mmaunder wrote: post #17
benwilber0 wrote: post #15

Earlier quoted context omitted.

I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.

Go ahead and give us an example.

Shell script in a git repo?

Re: OS X 10.10.5 kernel local privilege escalation

#23

Post by mmaunder »

benwilber0 wrote: post #15
mmaunder wrote: post #12

Earlier quoted context omitted.

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

I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.

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, you'd need two major vulnerabilities to do what you want to do. That's why I posted a reply saying 'tell us how'. It's important to understand that to exploit this you need a local unprivileged account on the box.

Re: OS X 10.10.5 kernel local privilege escalation

#24

Post by mbilker »

kibibyte wrote: post #19
thought_alarm wrote: post #8

Does it work on 10.11 with "rootless" mode disabled?

I 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 w…

In the README it states the vulnerability is not present in 10.11.

Re: OS X 10.10.5 kernel local privilege escalation

#27

Post by ossreality »

benwilber0 wrote: post #21
mmaunder wrote: post #17

Earlier quoted context omitted.

Go ahead and give us an example.

What user does your web browser run as? Do you use chrome? Any Chrome extensions use the NDK?

lmao, something running under the NDK is massively sandboxed and would not be exploitable like this.

Re: OS X 10.10.5 kernel local privilege escalation

#28

Post by qwertyoruiop »

albertoleal wrote: post #25
edude03 wrote: post #2

So 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

What about 10.10.3?

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

Re: OS X 10.10.5 kernel local privilege escalation

#29

Post by benwilber0 »

mmaunder wrote: post #23
benwilber0 wrote: post #15

Earlier quoted context omitted.

I don't understand what you're implying. This is a 0day that could be exploited from any number of outside channels.

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 reply on HN