6 ms·

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

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.

x0x0 9y ago
> 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.
- Siguza 9y ago
  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 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.
  - tischler 9y ago
    Incredible work. How did you find the bug and how many hours did it take you in total?
    - Siguza 9y ago
      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.
      - Godel_unicode 9y ago
        If Apple doesn't offer you a job they're insane.
        atmosx 9y ago
        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.
      - 9y ago
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
Godel_unicode 9y ago
> 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.
- floatingatoll 9y ago
  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!"
  - jacquesm 9y ago
    Or in the pattern CVE-dddd-dddd ... For additional fun, find a buffer overrun based on the CVE ID.
  - JdeBP 9y ago
    You yourself clearly do not. (-:
- tlrobinson 9y ago
  CVE 2018-0002: Flaw in CVE numbering procedure incentivizes dropping zero days on New Year’s Eve.
  - stevekemp 9y ago
    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 ..
- codezero 9y ago
  Looks like that number was already reserved for a still unpublished vuln. We’re already up to > 3000 in 2018!
tbrock 9y ago
MacOS 10.13.2 (which fixes this) has already been out for almost a month so likely nobody will care. Patch your shit people.
- Siguza 9y ago
  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.
  - tbrock 9y ago
    Ah dang, you are right, wow.

x0x0 9y ago

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

Siguza 9y ago
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 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.
- tischler 9y ago
  Incredible work. How did you find the bug and how many hours did it take you in total?
  - Siguza 9y ago
    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.
    - Godel_unicode 9y ago
      If Apple doesn't offer you a job they're insane.
      - atmosx 9y ago
        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.
    - 9y ago

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

Godel_unicode 9y ago

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

floatingatoll 9y ago
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!"
- jacquesm 9y ago
  Or in the pattern CVE-dddd-dddd ... For additional fun, find a buffer overrun based on the CVE ID.
- JdeBP 9y ago
  You yourself clearly do not. (-:
tlrobinson 9y ago
CVE 2018-0002: Flaw in CVE numbering procedure incentivizes dropping zero days on New Year’s Eve.
- stevekemp 9y ago
  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 ..
codezero 9y ago
Looks like that number was already reserved for a still unpublished vuln. We’re already up to > 3000 in 2018!

tbrock 9y ago

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

Siguza 9y ago
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.
- tbrock 9y ago
  Ah dang, you are right, wow.