Live data from Hacker News

OS X 10.10.5 kernel local privilege escalation

github.com

131–140 of 143 posts

Re: OS X 10.10.5 kernel local privilege escalation

#131
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…

Telling people about what you have discovered is bad if you can reasonably tell that those people are bad actors who will use the information you are giving them to do harm.

That's why it's responsible to tell the people who can be responsible for mitigating the problem in sufficient time for them to propagate a fix before publicizing the exploit in the knowledge that you are giving it to bad actors.

The fact that the vulnerability existed before and may have even been being exploited does absolutely nothing to change this.

If it was already being exploited but isn't publicly known then irresponsible disclosure simly makes the problem worse by increasing its availability to more bad actors who weren't previously in the know.

Re: OS X 10.10.5 kernel local privilege escalation

#132
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…

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

Your argument that you'd have to be omniscient to make the optimal choice with absolute certainty is true of all human decision making at all times, and therefore doesn't change the argument at all.

You say 'given that we don't know who else had this exploit' there is value in rapidly securing a few people rather than letting them remain vulnerable.

The question here is has the public availability of the exploit secured more users from realistic attack than it has exposed?

The fact that the vulnerability wasn't publicly known before is evidence that it wasn't in widespread use. Not conclusive evidence, but evidence nonetheless. Not knowing who had the exploit before doesn't mean we have no information on which to base the decision, and certainly doesn't mean we should adopt a policy based on the idea that the exploit is currently in widespread use.

Re: OS X 10.10.5 kernel local privilege escalation

#133

Earlier quoted context omitted.

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

Nothing says "hardcore hacker at work" quite like forgetting what day of the week it is.

Nothing says 'irresponsible' like not thinking at all about the impact of releasing information you know people will use for harm. Publishing to github comes after the hacking.

If qwertyoruiop had instead come up with plans for making a suitcase nuke from household ingredients, or for breeding an Ebola analog using a home beer making kit, your argument would imply that you think that posting them on the Internet would not be bad.

I disagree.

Re: OS X 10.10.5 kernel local privilege escalation

#134
post #133

Earlier quoted context omitted.

Nothing says "hardcore hacker at work" quite like forgetting what day of the week it is.

Nothing says 'irresponsible' like not thinking at all about the impact of releasing information you know people will use for harm. Publishing to github comes after the hacking. If qwertyoruiop had instead come up with plans for making a suitcase nuke from household ingredients, or for breeding an Ebola analog using a home beer making kit, your argument would imply that you think that posting them on the Internet woul…

And again with the ridiculous analogies.

It's really difficult to have a serious discussion about computer security vulnerabilities when people keep comparing it to throwing rocks through windows or weapons of mass destruction.

And yes, it's relevant, because the severity of a problem can and does influence how problematic various approaches are.

This is a local root exploit. Those are common and not generally problematic. The barrier to escalating from a normal user to root is at best the absolute last line of defense, and often completely irrelevant. It's a problem that should be fixed, don't get me wrong, but the severity is about 2 out of 10.

The fact that I think it's not a bad thing to release information like this has no bearing on what I would think about releasing information on building a suitcase nuke from household ingredients.

Could we try to keep the conversation grounded, here?

Re: OS X 10.10.5 kernel local privilege escalation

#135
post #133

Earlier quoted context omitted.

Nothing says 'irresponsible' like not thinking at all about the impact of releasing information you know people will use for harm. Publishing to github comes after the hacking. If qwertyoruiop had instead come up with plans for making a suitcase nuke from household ingredients, or for breeding an Ebola analog using a home beer making kit, your argument would imply that you think that posting them on the Internet woul…

And again with the ridiculous analogies. It's really difficult to have a serious discussion about computer security vulnerabilities when people keep comparing it to throwing rocks through windows or weapons of mass destruction. And yes, it's relevant, because the severity of a problem can and does influence how problematic various approaches are. This is a local root exploit. Those are common and not generally proble…

If you had been saying before now that this wasn't a severe bug and so we shouldn't be too concerned about disclosure, then you wouldn't have been presented with these strong counterarguments.

But that isn't what you've been saying - rather, you've been making the general argument that releasing information is not damaging or bad, and that we should only hold the people who exploit vulnerabilities responsible - not those who disclose them. Multiple people have argued against you on this.

Now you have switched your position to 'It's not bad to disclose vulnerabilities unless they are severe'. This seems much more reasonable, and came as the consequence of you being presented with what you are calling 'ridiculous' analogies.

To me this seems like a serious discussion done right.

Re: OS X 10.10.5 kernel local privilege escalation

#136

Earlier quoted context omitted.

Mad props. If osx were s/xnu/minix 3-style, full microkernel/, sploiting Iokit as a least priv'd process, only it would get pwned and be limited to iokit's acls. Still bad, but it likely wouldnt have rights to exec a root shell. XNU kexts have way too much authority, and all the syscalls they each tack on compounds the attack surface to the total codebases of all Apple and third-party kexts. Because once you've found…

while I agree with you on the security benefits of a full microkernel, to be entirely honest, if you had access to just IOKit you could easily use a network card or an hard drive controller to get a physical memory write-what-where, which in turn would allow you to gain access to anything, plus the microkernel performance issues of e.g. having to context switch on interrupts.

That things may be broken is no argument against defense-in-depth and least privilege. By having smaller codebases and smaller system components, the attack surface is far, far smaller than say Linux. IOKit is shit as is, and a full microkernel would break it up into processes based on areas of responsibility. Also, that shows the hardware needs better bus- and command-level security to prevent such attacks. (Don't even get me started on closed firmware blobs or unverifiability of commercial cores.)

Expecting a finished product of a new project would be unreasonable. Minix 3 is early on and not the only full microkernel out there. They will probably find an approach to reduce context switches if it's a mature optimization to make. An Android-like mobile/embedded platform would make a sensible research -> real use-case, minus Java.

Re: OS X 10.10.5 kernel local privilege escalation

#137
post #132

Earlier quoted context omitted.

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

Your argument that you'd have to be omniscient to make the optimal choice with absolute certainty is true of all human decision making at all times, and therefore doesn't change the argument at all. You say 'given that we don't know who else had this exploit' there is value in rapidly securing a few people rather than letting them remain vulnerable. The question here is has the public availability of the exploit secu…

You are right that my argument is sort of philosophical and not practical.

> The question here is has the public availability of the exploit secured more users from realistic attack than it has exposed?

It probably has exposed more. But, it could depend on whether some OS X servers were patched, or company-managed OS X workstations, or virus-scanner definitions updated, which could simultaneously protect many users.

> certainly doesn't mean we should adopt a policy based on the idea that the exploit is currently in widespread use.

In the current climate, I'm not so sure. Maybe not "widespread" use since, as you say, it doesn't seem to be publicly known. But, if it were only in narrow use and the discloser has determined this was the fastest way to warn people, do those narrow victims deserve security less than everyone else? Some of the discloser's statements make me wonder if he does know of other exploiters. You can question whether he knows enough or has the right to make that call, but if he disclosed responsibly, you'd be trusting Apple in the same way. Are they inherently more capable of making a good decision just because they're a corp?

P.S. It's interesting that you seem to rely on "the community" to notice whether this was being exploited by malware, but are mad at somebody from "the community" reporting it without it having been exploited by malware. Of course I understand the reason this may not be the best way for it to be reported, but maybe we should be glad this was found and reported at all, for free, by someone in "the community." It almost seems entitled, to expect someone else to do you a favor for free, and for you to also dictate the terms.

Re: OS X 10.10.5 kernel local privilege escalation

#138
post #132

Earlier quoted context omitted.

Your argument that you'd have to be omniscient to make the optimal choice with absolute certainty is true of all human decision making at all times, and therefore doesn't change the argument at all. You say 'given that we don't know who else had this exploit' there is value in rapidly securing a few people rather than letting them remain vulnerable. The question here is has the public availability of the exploit secu…

You are right that my argument is sort of philosophical and not practical. > The question here is has the public availability of the exploit secured more users from realistic attack than it has exposed? It probably has exposed more. But, it could depend on whether some OS X servers were patched, or company-managed OS X workstations, or virus-scanner definitions updated, which could simultaneously protect many users.…

Warning people isn't the issue. Apple is without question in a position to distribute a patch more rapidly and more widely than anyone else. It has nothing to do with trusting them because they are a 'corp'.

There is nothing 'entitled' about the opinion that it's wrong to distribute information about malware publicly where it can be used by bad actors, without first giving vendors a chance to distribute a fix.

Re: OS X 10.10.5 kernel local privilege escalation

#139
post #138

Earlier quoted context omitted.

You are right that my argument is sort of philosophical and not practical. > The question here is has the public availability of the exploit secured more users from realistic attack than it has exposed? It probably has exposed more. But, it could depend on whether some OS X servers were patched, or company-managed OS X workstations, or virus-scanner definitions updated, which could simultaneously protect many users.…

Warning people isn't the issue. Apple is without question in a position to distribute a patch more rapidly and more widely than anyone else. It has nothing to do with trusting them because they are a 'corp'. There is nothing 'entitled' about the opinion that it's wrong to distribute information about malware publicly where it can be used by bad actors, without first giving vendors a chance to distribute a fix.

Technically in this case, Apple was given advance notice: https://news.ycombinator.com/item?id=10070799 . I'm guessing we'd all agree it was not a reasonable amount of time to actually fix it... but then who gets to decide what that is? If I'm counting right, it took over a month for Apple to patch DYLD_PRINT_TO_FILE, which was disclosed in a similar way.

IMO's it's naive to think nobody else knew about these relatively simple exploits, so I don't blame the reporter too badly for deciding they don't want to wait weeks for Apple to fix it, if they can fix it themselves in hours. It's useless for Apple to be "in a position to distribute a patch more rapidly and more widely than anyone else" if they don't actually distribute a patch rapidly. I guess we'll have to wait and see how rapid they are this time.

I guess we'll have to agree to disagree. I'm at least glad to read around a bit that it's a controversial topic, so we're both in good company in our respective opinions.

Re: OS X 10.10.5 kernel local privilege escalation

#140
post #138

Earlier quoted context omitted.

Warning people isn't the issue. Apple is without question in a position to distribute a patch more rapidly and more widely than anyone else. It has nothing to do with trusting them because they are a 'corp'. There is nothing 'entitled' about the opinion that it's wrong to distribute information about malware publicly where it can be used by bad actors, without first giving vendors a chance to distribute a fix.

Technically in this case, Apple was given advance notice: https://news.ycombinator.com/item?id=10070799 . I'm guessing we'd all agree it was not a reasonable amount of time to actually fix it... but then who gets to decide what that is? If I'm counting right, it took over a month for Apple to patch DYLD_PRINT_TO_FILE, which was disclosed in a similar way. IMO's it's naive to think nobody else knew about these relativ…

You keep saying things like 'who is to decide?'. If you really believed that, you would cease posting your opinions here.

The point about people not wanting to wait for Apple is valid in that certain people can protect themselves ahead of apple distributing a fix.

However it clearly doesn't change the calculus since the number of people who can protect themselves is miniscule compared to the number of people made vulnerable. Even if it takes a month, that is going to distribute the patch far faster than this.

There is nothing controversial about this. It's a matter of statistics.

Post reply on HN