Live data from Hacker News

IOHIDeous OS X Local Kernel Vulnerability

siguza.github.io

41–50 of 121 posts

Re: IOHIDeous OS X Local Kernel Vulnerability

#41
post #30

Earlier quoted context omitted.

The problem is that allowing the vendor to define what is responsible, which seems these days to be expanding into giving them unlimited time to fix it, is to allow them to take unlimited time to fix it. Cooperation or even coordination takes willingness from both parties. Let's look at the actual page apple has on reporting security issues [0] "When we receive your email, we send an automatic email as acknowledgment…

> in addition to the spelling of acknowledgement "acknowledgment" is the English US form: https://en.oxforddictionaries.com/definition/acknowledgement

Thanks. I thought I was aware of most differences, but clearly there is always more to learn with respect to the differences between the two localizations.

Re: IOHIDeous OS X Local Kernel Vulnerability

#43
post #10
post #2

Responsible disclosure would have been to product-security@apple.com. Do apple have a bug-bounty program?

"Responsible Disclosure" is an Orwellian term concocted by vendors to control the actions of independent vulnerability researchers who work without real compensation, using information freely available to consumers, in competition with malicious attackers. The term you're looking for is "Coordinated Disclosure". Yes, Coordinated Disclosure would involve sending the bug to Apple and waiting for them to publish it. If…

You're correct, but I think it's worth going into a bit more detail about some of the tradeoffs involved in the concept of "Responsibility" as it applies to security research and exploit discovery, because there are a few clashing objectives that shape what the right choice is each time if we're considering how to minimize harm to all parties (if someone just wants to sell it to the highest bidder none of this applies). On the one hand, a vendor provided, well tested full patch is of course the ultimately desired permanent fix.

But what I think many people forget when they get "responsible disclosure" in their minds is that there are often bandaids users can do to protect themselves immediately regardless of whether a patch is ready, so long as they know about it. And since it's always possible and generally unknowable as to whether someone else might have already found the exploit and be using it, there is extra hard to calculate risk. Releasing it without a patch may lead to some users getting exploited, but it could also actually protect some users from being exploited or at least allow them to minimize the harm. Once it's known about in the wider community, it is also easier to check whether it's been selectively deployed anywhere. The lag time between notification and vendor patching is itself a risk (and of course there is lots of room for perverse incentives in all this).

So the real core issue with Coordinated Disclosure is that there is not in fact a Right Answer in general, any choice may help one group at the expense of another. Many researchers and organizations try to split the difference with standardized policies that seem to strike the balance, perhaps with occasional exceptions if it's serious enough. But ultimately it really is up to the discoverer and it's wrong to insist they conform to what the vendor finds desirable, particularly since ultimately the responsibility for the blunder lies with the vendor. It's a hard area and researchers should be respected for the work they do on their own terms.

Re: IOHIDeous OS X Local Kernel Vulnerability

#45
post #39
post #23

Earlier quoted context omitted.

I had actually submitted to the ZDI, but had written the exploit & write-up in the first place mainly because I like hacking rather than for money. I figured I'd see what offers I'd get anyway, but once I had spent all the time on the write-up, I mainly wanted people to see that, and the amount offered wasn't enough to convince me otherwise. I might've published this earlier even, but my December was kinda busy, firs…

You say you submitted it to the ZDI, but did you try sending it to Apple product security?

No, their bug bounty only extends to iOS.

Re: IOHIDeous OS X Local Kernel Vulnerability

#46
post #16

Earlier quoted context omitted.

I don't understand why Apple doesn't have a well-funded bug bounty program. You would think that companies would welcome people finding bugs in their software. Hell, they could give away free MacBook Pro laptops, phones, and IPads along with CASH!!!

They do have a well-funded and well-publicized bounty program for security exploits.

Apple's bug bounty program does not cover macOS.

Re: IOHIDeous OS X Local Kernel Vulnerability

#47
post #45
post #39

Earlier quoted context omitted.

You say you submitted it to the ZDI, but did you try sending it to Apple product security?

No, their bug bounty only extends to iOS.

Doesn't mean you can't email product-security@apple.com with your bug anyway.

Re: IOHIDeous OS X Local Kernel Vulnerability

#48
post #42

To all the kernel programmers out there, can we get a HN-level ELI5 for this? It looks like a total system compromise is possible. Under what conditions? Any ways to ensure we don't get pwned?

Needs to be running on the host already (nothing remote), achieves full system compromise by itself, but logs you out in the process. Can wait for logout though and is fast enough to run on shutdown/reboot until 10.13.1. On 10.13.2 it takes a fair bit longer (maybe half a minute) after logging out, so if your OS logs you out unexpectedly... maybe pull the plug? And maybe don't download & run untrusted software until the bug is patched (or, you know, ever)? Also, any decent antivirus shouldn't take long to add this to their malware definitions.

Not sure if this is HN-level, but... I hope it's understandable.

Re: IOHIDeous OS X Local Kernel Vulnerability

#49
post #30

Earlier quoted context omitted.

The problem is that allowing the vendor to define what is responsible, which seems these days to be expanding into giving them unlimited time to fix it, is to allow them to take unlimited time to fix it. Cooperation or even coordination takes willingness from both parties. Let's look at the actual page apple has on reporting security issues [0] "When we receive your email, we send an automatic email as acknowledgment…

As a Mac user, I feel it’s irresponsible. I don’t want zero days published before Apple has a chance to fix. I also think that the vendor has a responsibility to fix the exploit quickly, and if not the researcher should publish and shame the vendor.

[deleted]

Re: IOHIDeous OS X Local Kernel Vulnerability

#50
post #30
post #14

Earlier quoted context omitted.

I don't like the term you made up. But fine, I think this is "Irresponsible Disclosure." Is that better? Did anything change? Vendors and non-vendors alike are all responsible for good security, and that includes working together to make this happen. If you are working against vendors because of some preconceived notion that they are "evil," that's not a good thing. If it turns out that the author did submit to the v…

The problem is that allowing the vendor to define what is responsible, which seems these days to be expanding into giving them unlimited time to fix it, is to allow them to take unlimited time to fix it. Cooperation or even coordination takes willingness from both parties. Let's look at the actual page apple has on reporting security issues [0] "When we receive your email, we send an automatic email as acknowledgment…

Since when did the term "responsible disclosure" mean allowing the vendor unlimited time to fix it?
Post reply on HN