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

111–120 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#111

Post by qwertyoruiop »

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…

> and the author made no effort at all to reduce the impact

http://github.com/kpwn/NULLGuard

Re: OS X 10.10.5 kernel local privilege escalation

#112

Post by MagerValp »

qwertyoruiop wrote: post #111
MagerValp wrote: post #106

Earlier quoted context omitted.

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…

> and the author made no effort at all to reduce the impact http://github.com/kpwn/NULLGuard

Thank you. Any particular reason you decided to lead with the exploit and not this patch?

Re: OS X 10.10.5 kernel local privilege escalation

#113

Post by m1keil »

qwertyoruiop wrote: post #94
devy wrote: post #62

Earlier quoted context omitted.

10.10.5 kernel panic too. https://gist.github.com/anonymous/6a76b0793607c890c3ea

You are not vulnerable since you have SMAP!

what's SMAP? can't find info anywhere. edit: ok, found, cpu security feature. so it's possible this issue is mitigated on newer CPUs?

Re: OS X 10.10.5 kernel local privilege escalation

#114

Post by not_with_retard »

MagerValp wrote: post #67
scintill76 wrote: post #65

Earlier quoted context omitted.

My vague recollections of past vulns (and admitted dislike for Apple) leads me to believe the parent comment, so I did some Googling. "A prominent security researcher warned Apple about this dangerous vulnerability in mid-2008, yet the company waited more than 1,200 days to fix the flaw ."[1] But hey, they did credit him in the release notes! Granted, it's been several years now, but the parent did say "has a poor re…

Apple fixes hundreds of vulnerabilities every year, and while they do drop the ball on one or two, those are exceptions, not typical. Reports to product-security@apple.com are responded to by a human within a few hours, and issues are typically patched in the next point release or the next after. I can see why you'd drop a 0-day if you were somehow ignored or they were stalling for years, but dropping it without even…

That's the way he decided to do it, your opinion of it doesn't matter.

Re: OS X 10.10.5 kernel local privilege escalation

#115

Post by scintill76 »

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…

> You don't need omnicience to determine whether the downsides outweigh the potential benefits

I mean you'd have to be omniscient to make the optimal choice with absolute certainty. What if somebody with the most sensitive data you can imagine, gets infected and the data exfiltrated if they have to wait for Apple to patch this, but is safe after applying one of the suggested fixes from the exploiter? If you were omniscient you could tally up the total harm (or whatever metric you want to use) from various choices and choose the best one.

I recognize the mainstream-accepted calculus is more along the lines you are arguing for, and of course it makes sense to use probabilities and percentages since nobody's omniscient. But, given we don't know who else had this exploit, I still see some value in rapidly securing a few people rather than letting them remain vulnerable.

Re: OS X 10.10.5 kernel local privilege escalation

#116

Post by qwertyoruiop »

MagerValp wrote: post #112
qwertyoruiop wrote: post #111

Earlier quoted context omitted.

> and the author made no effort at all to reduce the impact http://github.com/kpwn/NULLGuard

Thank you. Any particular reason you decided to lead with the exploit and not this patch?

I did not have the patch ready when the exploit was published, that's the only reason why. I had my reasons to publish the exploit in public yesterday, but all I can say is "no comment".

Just for the record: I did inform Apple beforehand. Not so much before, but before.

I do not consider this to be their fault in any way as someone in this thread seems to be implying. Again, I had my reasons to drop such a thing publicly. I've had this for months, and I did not intend on disclosing at all. Proof of my "for months" assertion: https://www.youtube.com/watch?v=8arPid8GtFk

> As a bare minimum Apple needs a few hours to analyze the bug

Again, for the record: Apple has full details of the underlying bug. They won't even need to check my github at all.

Re: OS X 10.10.5 kernel local privilege escalation

#117

Post by qwertyoruiop »

mikeash wrote: post #110
MagerValp wrote: post #106

Earlier quoted context omitted.

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

for the record: i had no idea yesterday was saturday at the time I dropped the code.

Re: OS X 10.10.5 kernel local privilege escalation

#118

Post by qwertyoruiop »

qwertyoruiop wrote: post #46
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 =…

for the record: "At 0x20 I place a POP RAX;RET gadget" should be "At 0x18 I place a POP RAX;RET gadget".

Re: OS X 10.10.5 kernel local privilege escalation

#119

Post by qwertyoruiop »

fit2rule wrote: post #107
D4AHNGM wrote: post #99

Earlier quoted context omitted.

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

Then you should not install them on a machine with confidential data at all, source or binary. It's that simple!

Re: OS X 10.10.5 kernel local privilege escalation

#120

Post by qwertyoruiop »

m1keil wrote: post #113
qwertyoruiop wrote: post #94

Earlier quoted context omitted.

You are not vulnerable since you have SMAP!

what's SMAP? can't find info anywhere. edit: ok, found, cpu security feature. so it's possible this issue is mitigated on newer CPUs?

well, this bug is a null pointer deference. smap is like -no_shared_cr3, but without the performance loss.
Post reply on HN