from Hacker News

How to unc0ver a 0-day in 4 hours or less

by GuardLlama on 7/9/20, 4:06 PM with 116 comments

• by akersten on 7/9/20, 8:45 PM

  > So, to summarize: the LightSpeed bug was fixed in iOS 12 with a patch that didn't address the root cause and instead just turned the race condition double-free into a memory leak. Then, in iOS 13, this memory leak was identified as a bug and "fixed" by reintroducing the original bug, again without addressing the root cause of the issue. And this security regression could have been found trivially by running the original POC from the blog post.

  Yikes. Especially looking at the diff of the original problematic fix, it seems like they slapped a quick patch on there and called it a day, instead of investigating to find the underlying architectural issue. Doesn't really inspire a lot of confidence that the resolution for unc0ver is any more thought-through. I wonder if they've identified the root-cause? That'd be the real interesting piece to me.

• by devenblake on 7/9/20, 6:33 PM

  > By 1 AM, I had sent Apple a POC and my analysis.

  > Still, I'm very happy that Apple patched this issue in a timely manner once the exploit became public.

  Sh- should we be happy Apple fixed this so quickly? unc0ver allows consumers to get more out of their Apple devices, and Apple's fix isn't really optional (unless you disable auto-updates and tap "Later" on every update notification). Is this exploit even an issue? Apple's probably not going to let an app exploiting this zeroday into its App Store and sideloading is difficult; it's very unlikely someone malicious is going to trick people into installing malware that uses this exploit. It sounds to me like Apple is purposefully limiting consumer freedom by actively trying to prevent jailbreaking.

• by PragmaticPulp on 7/9/20, 7:21 PM

  Fantastic write-up. It's great to see this level of information sharing, complete with a walkthrough of the author's thought process and strategy for confirming the exploit. It's also interesting that this was a regression of a previously-fixed bug rather than a new exploit.

  As a side note, it's disappointing to see so much unfounded criticism here in the comments. Apple was going to find and fix this bug quickly, regardless of the author's efforts. In this case we get a peek into the inner workings of the exploit discovery process that would otherwise remain secret. The author and Apple both clearly noted that unc0ver was the source of the exploit, and the author made no attempts to hide that fact. Calling the author of this blog post "lazy" or an "informant" is out of touch and uncalled for.

• by curiousgal on 7/9/20, 6:35 PM

  TL;DR: reverse engineer a jailbreak exploit.

  > By 7 PM, I had identified the vulnerability and informed Apple

  I don't know why this rubbed me the wrong way. Like, it feels "lazy" (for lack of a better way) to disassemble an exploit and run off to tell the vendor. If anything, the exploit writer should get the credit. I don't know.

• by MaxLeiter on 7/9/20, 8:19 PM

  Checkra1n, another iOS exploit (although it's more impressively a bootrom exploit), is mentioned. You can see slides on it from 2019 here: https://iokit.racing/oneweirdtrick.pdf (The One Weird Trick SecureROM Hates)

• by albntomat0 on 7/9/20, 4:18 PM

  Since this always comes up, here's an overview I made several weeks ago about where Project Zero focuses their efforts:

  All counts are rough numbers. Project zero posts:

  Google: 24

  Apple: 28

  Microsoft: 36

  I was curious, so I poked around the project zero bug tracker to try to find ground truth about their bug reporting: https://bugs.chromium.org/p/project-zero/issues/list For all issues, including closed:

  product=Android returns 81 results

  product=iOS returns 58

  vendor=Apple returns 380

  vendor=Google returns 145 (bugs in Samsung's Android kernel,etc. are tracked separately)

  vendor=Linux return 54

  To be fair, a huge number of things make this not an even comparison, including the underlying bug rate, different products and downstream Android vendors being tracked separately. Also, # bugs found != which ones they choose to write about.

• by etaioinshrdlu on 7/9/20, 10:07 PM

  I have nothing to add but the author of this was my best friend in elementary school. Interests included robots, crazy science experiments, dinosaurs, general mischief, and Perl programming.

• by saagarjha on 7/9/20, 7:09 PM

  TL;DR background for this one: there existed a zero day bug in iOS 11 related to how the kernel processed the lio_listio call. Apple fixed it then but introduced a memory leak. In iOS 13 Apple fixed the memory leak but reintroduced the vulnerability. The regression was found and packaged in a obfuscated jailbreaking tool (unc0ver); this post explains how the tool was deobfuscated. This resulted in an "emergency" iOS 13.5.1 update to fix the issue. Interestingly this fix still does not fully fix the memory leak: https://www.synacktiv.com/posts/exploit/the-fix-for-cve-2020...

• by Jyaif on 7/9/20, 7:03 PM

  Why is he doing that work? Does Apple not fix every jailbreak exploits by themselves?

• by Dolores12 on 7/10/20, 4:41 AM

  There is nothing to brag about. I want to own my device. I want to install on it whatever i like.

• by appybois on 7/10/20, 5:24 AM

  Working for the wrong side snitchy snitch

• by staycoolboy on 7/9/20, 7:46 PM

  FTA: "...the LightSpeed bug was fixed in iOS 12 with a patch that didn't address the root cause and instead just turned the race condition double-free into a memory leak. Then, in iOS 13, this memory leak was identified as a bug and "fixed" by reintroducing the original bug, again without addressing the root cause of the issue..."

  Ooof. Talk about running in circles. Either this was someone who is swamped with work and spaced out, or a new programmer who wasn't familiar with the original. Oddly, I feel bad for both of them!

• by thierryzoller on 7/9/20, 7:43 PM

  So proud to have reverse engineered an 0day. Ok, move on. Nothing to see.