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

101–110 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#101

Post by evandrix »

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…

use `clang`, not `gcc`.

clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-apple-darwin14.4.0 Thread model: posix

<-- can confirm it works out-of-the-box on OSX 10.10.4

Re: OS X 10.10.5 kernel local privilege escalation

#102

Post by mikeash »

gress wrote: post #98
scintill76 wrote: post #91

Earlier quoted context omitted.

I'm counting on the press and community to distribute the information about the no_shared_cr3 workaround and any kext that comes out, just as Apple's fix is most effective when everyone's being told they should be sure it gets applied. There are people in this thread more secure today than they were yesterday, and they owe it to this "irresponsible disclosure." Do they have less of a right to security than the "uneli…

This argument is a general argument for is irresponsible disclosure of 0-days. You don't need omnicience to determine whether the downsides outweigh the potential benefits to a tiny number of jumpy elite who would have to be constantly following and applying patches. Notably those patches couldn't be applied blindly - so all of those 'elite' in parallel would have to fully understand the exploit and patches lest thes…

Malware that uses this exploit to cause damage is a straight up attack on users. Merely revealing a vulnerability isn't an attack. The vulnerability was there all along, and there's no guarantee that this person is the only one who could find it, or even the first.

I'm all for responsible disclosure. But I think we need to clarify good and bad here. Responsible disclosure is better than just announcing findings to the world, but telling people about what you've discovered is not bad.

Re: OS X 10.10.5 kernel local privilege escalation

#103

Post by pacquiao882 »

MagerValp wrote: post #78
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

The DYLD_PRINT_TO_FILE exploit was fixed in 10.10.5.

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

Re: OS X 10.10.5 kernel local privilege escalation

#104

Post by MagerValp »

pacquiao882 wrote: post #103
MagerValp wrote: post #78

Earlier quoted context omitted.

The DYLD_PRINT_TO_FILE exploit was fixed in 10.10.5.

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

That 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

Re: OS X 10.10.5 kernel local privilege escalation

#105

Post by lisper »

Anyone 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

Re: OS X 10.10.5 kernel local privilege escalation

#106

Post by MagerValp »

mikeash wrote: post #102
gress wrote: post #98

Earlier quoted context omitted.

This argument is a general argument for is irresponsible disclosure of 0-days. You don't need omnicience to determine whether the downsides outweigh the potential benefits to a tiny number of jumpy elite who would have to be constantly following and applying patches. Notably those patches couldn't be applied blindly - so all of those 'elite' in parallel would have to fully understand the exploit and patches lest thes…

Malware that uses this exploit to cause damage is a straight up attack on users. Merely revealing a vulnerability isn't an attack. The vulnerability was there all along, and there's no guarantee that this person is the only one who could find it, or even the first. I'm all for responsible disclosure. But I think we need to clarify good and bad here. Responsible disclosure is better than just announcing findings to th…

There's writing a nicely worded letter, and sending it in a rose scented envelope. And then there's scribbling a note, tying it to a rock, and throwing it through the window.

Telling the world via a fully working exploit causes a ton of collateral damage, and the author made no effort at all to reduce the impact. Waiting for 10.10.5 and releasing it on a Saturday afternoon makes it seem like the point was to cause as big a mess as possible.

Re: OS X 10.10.5 kernel local privilege escalation

#107

Post by fit2rule »

D4AHNGM wrote: post #99
fit2rule wrote: post #89

Earlier quoted context omitted.

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

Not sure why you're looking at Homebrew. If you're feeling jumpy about binary packages, just set `HOMEBREW_BUILD_FROM_SOURCE="1"` in your shell profile. Nobody's forcing binaries onto you.

True, but I don't have all the time in the world to read the sources, either ..

Re: OS X 10.10.5 kernel local privilege escalation

#108

Post by fit2rule »

evandrix wrote: post #101
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…

use `clang`, not `gcc`. clang version 3.6.1 (tags/RELEASE_361/final) Target: x86_64-apple-darwin14.4.0 Thread model: posix <-- can confirm it works out-of-the-box on OSX 10.10.4

Cool, thanks for pointing that out. I was pretty glib about my attempt to check it out ..

Re: OS X 10.10.5 kernel local privilege escalation

#109

Post by ams6110 »

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…

easily exploitable in the mode of many project "installers" these days which is something like:

  curl  | bash

Re: OS X 10.10.5 kernel local privilege escalation

#110

Post by mikeash »

MagerValp wrote: post #106
mikeash wrote: post #102

Earlier quoted context omitted.

Malware that uses this exploit to cause damage is a straight up attack on users. Merely revealing a vulnerability isn't an attack. The vulnerability was there all along, and there's no guarantee that this person is the only one who could find it, or even the first. I'm all for responsible disclosure. But I think we need to clarify good and bad here. Responsible disclosure is better than just announcing findings to th…

There's writing a nicely worded letter, and sending it in a rose scented envelope. And then there's scribbling a note, tying it to a rock, and throwing it through the window. Telling the world via a fully working exploit causes a ton of collateral damage, and the author made no effort at all to reduce the impact. Waiting for 10.10.5 and releasing it on a Saturday afternoon makes it seem like the point was to cause as…

Maybe Saturday afternoon just happened to be when he finished.

And no, it's not like throwing a rock through somebody's window. The information may be used by other people to cause damage, but the mere act of releasing it is not by itself damaging. Let's put blame where it belongs: on the people actually using exploits for bad purposes. If you want to encourage responsible disclosure, don't lead with bad analogies about what happens when you announce a vulnerability to the world, because it just reduces your credibility.

Post reply on HN