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

CVE 2018-0002: Flaw in CVE numbering procedure incentivizes dropping zero days on New Year’s Eve.

I remember waiting to report a security issue with some trivial setuid application until January, back a few years, specifically so I could claim the first CVE of the year.

I was unlucky and it didn't work out, but come December time I do wonder if I should dedicate more time to audits ..

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!"

Or in the pattern CVE-dddd-dddd ...

For additional fun, find a buffer overrun based on the CVE ID.

You yourself clearly do not. (-:

Looks like that number was already reserved for a still unpublished vuln. We’re already up to > 3000 in 2018!

> Siguza, 01. Dec 2017 (published 31. Dec 2017)

If I had to guess, he waited a month, got blown off, and said, "Fuck it."

Also -- I feel like the underlying bug, ie relying on values in a volatile variable that is shared -- are the sort of thing that source code could be systematically tested for, both mechanically and by humans. But my strong impression is that Apple doesn't care about MacOS and definitely doesn't put the A team on it. Or even the B team.

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, first with the v0rtex exploit and then with 34C3.

And an engineer from Apple's security team contacted me a bit after releasing - they had found the bug a while ago, but hadn't verified the subsequent patch which actually didn't fix it. And a while ago I tweeted this https://twitter.com/s1guza/status/921889566549831680 (try diff'ing sources to find it :P). So they do have people on it. I also told that person to extend my condolences to whoever has to come in and fix that now, but they basically said that there's nothing to apologise for and that they (the team) really like such write-ups. So... I guess I'm not that evil?

And I neither wanna watch the world burn nor did anyone brush me the wrong way - I didn't publish this out of hate, but out of love for hacking. If you're concerned about skids hacking you now, they need to get code execution first on your machine. If you're concerned about people who can do that, then those can also get kernel r/w without me, so... nothing really changed for the average user.

PS: Yes, it's really me. Will add keybase proof if my karma gets >= 2. Edit: done, see my profile.

The write-up you did on this vulnerability (not to mention the discovery of the vulnerability and coming up with a working exploit) is really top notch. Thanks for taking the time to compose such a high-quality explanation and walk-through.

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 broke a bunch of stuff (heap layout assumptions, ROP gadgets, kernel symbols, ...) so I had to fix these. In October I started working on the write-up, but when I got to the part about the info leak, I had written that it's most likely possible, but I had no demo for that. I didn't wanna leave an empty claim stand there like that, so I ended up taking another month to get the "leak" binary working and basically write a second exploit. By that time it was early November - the write-up with its graphs took some time and before I knew it, December had started (at which point I was finally done). All in all probably 200-250h - but it was a hard-to-exploit bug (IMO), I've done way more than necessary, and when I started I had still rather little knowledge of XNU and required a lot of time to learn how most stuff worked. Especially everything from the "leak" part was later really useful for v0rtex, whose initial version took me just one and a half days then - without that work, it would've taken me a couple of weeks at least.

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

That was my thought too. As an apple customer (5+ macs and 10+ i-Devices), I'd feel way better knowing that apple cares about macOS security enough to hire skilled engineers.

I'm a total non-engineer/developer, but I'm increasingly interested in what guys like you think about software QA as it relates to security.

Today's Apple does a lot of security posturing in hardware/platform architecture, like full disk encryption, the iOS device secure enclave thingie, the secure enclave's subsequent inclusion on touchbar Macbook Pros to control the webcam, iOS defaulting to non-networked sandboxing for third party keyboards, etc.

Do you think macOS/iOS development perhaps should slow down from a yearly release cycle to delay releases with continuous big reworking starting with XNU?

With a very rudimentary outsider perspective on QA, it just seems insane to keep pushing big OS changes yearly.

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 [email protected] with your bug anyway.

Why, if they clearly place no [monetary] value on security of OSX?

I suggest contact Google's Project Zero. I think those guys would love to help you...

MacOS 10.13.2 (which fixes this) has already been out for almost a month so likely nobody will care. Patch your shit people.

Nah, it doesn't fix the actual vuln - it's just that my exploit doesn't work out of the box because the "hid" binary uses a hardware info leak which doesn't work anymore the way I was doing it. If you patched the "leak" and "hid" binaries together, you'd still get kernel r/w on 10.13.2.

Ah dang, you are right, wow.