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

81–90 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#81

Post by fit2rule »

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…

Add malware to valued homebrew tool, profit.

Re: OS X 10.10.5 kernel local privilege escalation

#82

Post by matthewmacleod »

akerl_ wrote: post #64
devy wrote: post #60

Earlier quoted context omitted.

I did the same, didn't get the root shell but instead got a standard OS X kernel panic screen and system reboot twice before it came back to life. And wtf @qwertyoruiop this is how you "responsibly" release zero day?! I just upgraded to 10.10.5 yesterday!

You have quotes around "responsibly", is that a quote from somewhere in this disclosure? You're welcome to point out that you prefer that vulns be disclosed to vendors before public release, but to chastise someone for not subscribing to your preferred methodology seems a bit off base

chastise someone for not subscribing to your preferred methodology seems a bit off base

No - chastising someone for performing an act you consider to be harmful to the public is totally legitimate.

Re: OS X 10.10.5 kernel local privilege escalation

#83

Post by arielb1 »

nnx wrote: post #54
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…

Intriguing. Thanks for sharing. Doesn't Linux perform this "context switch at every syscall" ? How does it get away with the performance penalty?

All operating systems with separate user and kernel modes have a privilege-level round-trip on every syscall (typically `sysenter`/`sysexit`, on older systems the classic `int $0x80`/`iret`). This is just a controlled jump that changes the privilege level, and is what is bypassed by vsyscall.

Non-shared-cr3 Macs (and IIRC some versions of PaX) also change `%cr3`, which means user-space and kernel-space have completely different address spaces (rather than a shared kernel-space and per-process user-space). This is much more expensive.

Re: OS X 10.10.5 kernel local privilege escalation

#84

Post by klapinat0r »

fit2rule wrote: post #80
benwilber0 wrote: post #6

$ git clone 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…

Phew, didn't work for me out of the box: $ make gcc *.m -o tpwn -framework IOKit -framework Foundation -m32 -Wl,-pagezero_size,0 -O3 In file included from /usr/include/dispatch/dispatch.h:51:0, from /System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:56, from import.h:13, from lsym.h:5, from lsym.m:1: /usr/include/dispatch/object.h:143:15: error: expected identifier or '(' before '^' token typedef void (^di…

Just to clearify: that's just means you couldn't compile it. It doesn't imply your system is/isn't vulnerable.

Re: OS X 10.10.5 kernel local privilege escalation

#85

Post by fit2rule »

klapinat0r wrote: post #84
fit2rule wrote: post #80

Earlier quoted context omitted.

Phew, didn't work for me out of the box: $ make gcc *.m -o tpwn -framework IOKit -framework Foundation -m32 -Wl,-pagezero_size,0 -O3 In file included from /usr/include/dispatch/dispatch.h:51:0, from /System/Library/Frameworks/IOKit.framework/Headers/IOKitLib.h:56, from import.h:13, from lsym.h:5, from lsym.m:1: /usr/include/dispatch/object.h:143:15: error: expected identifier or '(' before '^' token typedef void (^di…

Just to clearify: that's just means you couldn't compile it. It doesn't imply your system is/isn't vulnerable.

Sure, but its somehow satisfying to know that its broken for those who don't make the effort to fix it. ;) (It happened to me because I'm using a different compiler than the exploit needs..)

Re: OS X 10.10.5 kernel local privilege escalation

#86

Post by klapinat0r »

Mojah wrote: post #75

So 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

One 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 :)

Re: OS X 10.10.5 kernel local privilege escalation

#87

Post by Osmium »

Mojah wrote: post #75

So 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

They've released a fix for the DYLD bug, and it didn't effect El Capitan anyway. Point of interest, but I had manually changed my sudoers file when I was running Yosemite. I'm now running the El Capitan beta. The sudoers file had been happily unchanged up until the most recent update, when it was reset... I don't know if it's related to concerns over the DYLD bug, but I'm guessing it is.

It's encouraging that of these two major bugs, both didn't work in El Capitan. Not claiming that it's going to be some sort of panacea; I'm sure it's just a matter of time before it gets exploited too. But it's still encouraging.

Re: OS X 10.10.5 kernel local privilege escalation

#88

Post by MagerValp »

fit2rule wrote: post #85
klapinat0r wrote: post #84

Earlier quoted context omitted.

Just to clearify: that's just means you couldn't compile it. It doesn't imply your system is/isn't vulnerable.

Sure, but its somehow satisfying to know that its broken for those who don't make the effort to fix it. ;) (It happened to me because I'm using a different compiler than the exploit needs..)

Malware comes precompiled and ready to run, it doesn't depend on you having a compiler installed.

Re: OS X 10.10.5 kernel local privilege escalation

#89

Post by fit2rule »

MagerValp wrote: post #88
fit2rule wrote: post #85

Earlier quoted context omitted.

Sure, but its somehow satisfying to know that its broken for those who don't make the effort to fix it. ;) (It happened to me because I'm using a different compiler than the exploit needs..)

Malware comes precompiled and ready to run, it doesn't depend on you having a compiler installed.

True that! I'm looking at you, homebrew ..

Re: OS X 10.10.5 kernel local privilege escalation

#90

Post by x0rg »

facetube wrote: post #41
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.

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.

What do you mean by "minor performance hit"? Could you provide some data?
Post reply on HN