Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IOHIDeous OS X Local Kernel Vulnerability

siguza.github.io

Post reply on HN
Print view View original

71–80 of 121 posts

Re: IOHIDeous OS X Local Kernel Vulnerability

#71

Post by infamouscow »

j1vms wrote: post #52
q3k wrote: post #4

Earlier quoted context omitted.

They don't for macOS. And the iOS one is invite-only.

> They don't for macOS. And the iOS one is invite-only. Which may, unfortunately, speak to what management thinks about the security/quality of the macOS codebase. I wouldn't be surprised the recent and upcoming exploits lead Apple to increase iOS dominance over its future product pipeline.

Apple's financial reports and behavior the last few years make it clear their priorities are not with the Mac, but with iOS. For better or worse, Apple is a smartphone company that happens to make computers on the side.

Re: IOHIDeous OS X Local Kernel Vulnerability

#72

Post by blinkingled »

Siguza wrote: post #68
blinkingled wrote: post #62

Earlier quoted context omitted.

Looks like a Time of Check vs Time of Use (TOCTOU) type vulnerability. User controlled memory is read and used later by kernel space - time in between read and use can be used to overwrite it from user space, typically by exploiting and winning race conditions. I haven't completed reading this one thoroughly but one example like this is kernel performing access checks on user requests asking it to perform some action…

It's actually neither TOCTOU nor double fetch, it's not checking anything at all, it's just write-then-fetch using shared (untrusted) memory to store trusted information. Sure similar in nature, but not really fitting any common name...

I see - I will give it a full read little later - I like your writing style based on what I've glanced over so far!

Re: IOHIDeous OS X Local Kernel Vulnerability

#73

Post by Godel_unicode »

Siguza wrote: post #66
tischler wrote: post #33

Earlier quoted context omitted.

Incredible work. How did you find the bug and how many hours did it take you in total?

I found it by looking through IOHIDFamily's source, hoping to find a low-hanging fruit affecting iOS. In total? A lot, probably way too much... I had found it in February and started to write an exploit in April. Next to my studies, exams, the Phœnix Jailbreak and Apple trying to mitigate tfp0, it took me until August to get a fully working exploit, at which point I figured I'd wait for High Sierra. And that actually…

If Apple doesn't offer you a job they're insane.

Re: IOHIDeous OS X Local Kernel Vulnerability

#74

Post by djrogers »

JohnTHaller wrote: post #38
tensor wrote: 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…

I think "irresponsible disclosure" would involve disclosing it to black hats for money.

Well, it has been disclosed to black hats - just not for money. To end users the result is the same; black hats have an unpatched 0day to play with, and we have no mitigations to deploy.

Re: IOHIDeous OS X Local Kernel Vulnerability

#75

Post by floatingatoll »

dpwm wrote: post #30
tensor wrote: 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…

You imply by framing without explicitly stating that "coordinated disclosure" is "unlimited time", but that's not the time frame under discussion.

I consider 24 hours notice bare minimum responsible disclosure, and 1 business day in the operating timezone of the company as an polite courtesy to the human beings who have to respond to uncoordinated security disclosures with emergency builds of their product.

What do you consider the bare minimum notice sufficient to respect the human beings who use the products we find vulns in? One business day? One hour? Zero seconds?

(Siguza, I'd also love to hear from you on this question, if you're willing to share. I know Apple said they don't need advance notice but if they hadn't, and offered no guidance, what would you have chosen?)

Re: IOHIDeous OS X Local Kernel Vulnerability

#76

Post by Digital-Citizen »

an_account wrote: post #32
dpwm wrote: 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.

Is 3 years considered quickly enough? How about 3 years for a remotely-exploitable problem? According to The" rel="nofollow">http://www.telegraph.co.uk/technology/apple/8912714/Apple-iT... Telegraph, "Apple was informed about the relevant flaw in iTunes in 2008, according to Brian Krebs, a security writer, but did not patch the software until earlier this month [Nov 2011], a delay of more than three years.".

It seems to me that nobody but Apple has a responsibility to its users. The public at large certainly doesn't owe Apple (or any other software proprietor) specific performance regardless of whether they report what they've found publicly or when.

Apple is also not being nice to its users by denying them software freedom: most of MacOS is proprietary and the aforementioned bug concerned iTunes, a proprietary media player. So no matter how technically savvy and willing the user is, they're not allowed to diagnose and fix the problem, prepare a fixed copy of the changed files, and help their community by sharing copies of the improved code.

"Responsible disclosure" is indeed propaganda that benefits the proprietor in a clumsy attempt to divert blame for a product people paid for with their software freedom as well as their money.

Re: IOHIDeous OS X Local Kernel Vulnerability

#77

Post by caf »

Siguza wrote: post #68
blinkingled wrote: post #62

Earlier quoted context omitted.

Looks like a Time of Check vs Time of Use (TOCTOU) type vulnerability. User controlled memory is read and used later by kernel space - time in between read and use can be used to overwrite it from user space, typically by exploiting and winning race conditions. I haven't completed reading this one thoroughly but one example like this is kernel performing access checks on user requests asking it to perform some action…

It's actually neither TOCTOU nor double fetch, it's not checking anything at all, it's just write-then-fetch using shared (untrusted) memory to store trusted information. Sure similar in nature, but not really fitting any common name...

TOWTTOU (with s/check/write)?

Re: IOHIDeous OS X Local Kernel Vulnerability

#78

Post by zbentley »

djrogers wrote: post #74
JohnTHaller wrote: post #38

Earlier quoted context omitted.

I think "irresponsible disclosure" would involve disclosing it to black hats for money.

Well, it has been disclosed to black hats - just not for money. To end users the result is the same; black hats have an unpatched 0day to play with, and we have no mitigations to deploy.

Well, we do have mitigations. They're not good ones, but they're mitigations:

- Be more paranoid about allowing r/w direct access to your computer.

- Be prepared to power off or otherwise halt your machine if (on 10.13.12) you see unexpected logouts or similar.

- Safeguard your data and/or consider moving it off of the machine or not using it in some situations.

None of those are great things to rely on or to have to do. A real working patch or detection mechanism would definitely be better. But that's not the same as "no mitigations" whatsoever.

Re: IOHIDeous OS X Local Kernel Vulnerability

#79

Post by floatingatoll »

gok wrote: post #5
mappu wrote: post #2

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

Why do that when you can wreck a security engineer’s vacation?

Why would your security engineer take CVE-2008-0001 as a holiday?

Re: IOHIDeous OS X Local Kernel Vulnerability

#80

Post by floatingatoll »

Godel_unicode wrote: post #65
stevemk14ebr wrote: post #15

Oh my I feel so sorry for apple security engineer's right now. I'm curious the motivations to release such a serious, and complex, 0day on new years eve!? Makes me wonder who brushed this guy the wrong way, or if he just wants to watch the world burn. That said, seriously impressive work and I give him props.

> I'm curious the motivations to release such a serious, and complex, 0day on new years eve!? CVE 2018-0001, it's all about namespaces.

Bonus points if they issue it as CVE-2018-65536 (pen-test the world, so to speak)

EDIT: "No one would ever store the CVE incrementing fragment as a 16-bit unsigned int!"

Post reply on HN