13 ms·

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

346 points by GuardLlama 6y ago

curiousgal 6y ago
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.
- forgotmypw17 6y ago
  To me, seems like informant territory.
- aarong11 6y ago
  But they didn't report it did they? Playing devil's advocate a bit here, but they could have reported it for a bug bounty but they instead chose to use it to create a jailbreak.
  - texasbigdata 6y ago
    Maybe reworded, the value accrues to the explainer of the issue to the code writer. Therefore, this dude did something valuable. Ecosystem works. Perhaps.
- umvi 6y ago
  All this has taught me is that if I find an exploit to unlock <insert DRM'd device> I need to obfuscate the heck out of it to make it as onerous as possible for low-effort bug bounty do-gooders to scoop up a reward from it.
  - saagarjha 6y ago
    I don't think anyone is getting a bug bounty, especially from this one.
  - snazz 6y ago
    Project Zero researchers don’t take bounties, to my knowledge.
    - saagarjha 6y ago
      Nor have they been ever offered one, to my knowledge: https://twitter.com/i41nbeer/status/1027339893335154688 https://twitter.com/i41nbeer/status/1027339893335154688. I'm actually not sure Apple has ever paid a bounty for anything that wasn't a web issue…
      - jlgaddis 6y ago
        If memory serves, they've been offered but the bounties are always been given to charity. I'm guessing that's a policy/requirement of Project Zero as, presumably, the P0 folks are making "enough" already.
- saagarjha 6y ago
  > If anything, the exploit writer should get the credit. They did: https://support.apple.com/en-us/HT211214 https://support.apple.com/en-us/HT211214
- CountHackulus 6y ago
  They did, the article points out that this was caused by a regression. Fixing a memory leak made it such that it reenabled an old bug.
- xuki 6y ago
  The exploit was public, but obfuscated to make it harder for bad actors to make use of. Apple likely didn't need help to identify the vulnerability, but I'm sure they welcomed it.
albntomat0 6y ago
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 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.
- londons_explore 6y ago
  Project Zero has uncovered 2033 issues... The majority of those could be used alone to ruin your life. The rest might require 2 (Eg. one for the sandbox, one for the kernel). Thats a team of ~10 security researchers over many years... Considering how many are being discovered each day/month/year, chances are that there are at least hundreds undiscovered... If it only takes one to ruin your life, and a good security researcher can find one in a few weeks, or months at most, the barrier to someone evil is really really low...
  - Avamander 6y ago
    > good security researcher can find one in a few weeks s/good/extremely good/ This doesn't change the fact that someone evil will still probably find one.
- londons_explore 6y ago
  Most experts have expertise on only one or two different OS's or bits of software. The found issues will strongly depend who happens to be on the Google Project Zero team at the moment.
  - 6y ago
devenblake 6y ago
> 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.
- curiousgal 6y ago
  I 100% agree but then again, people choose to buy those products so..
- bzb3 6y ago
  There are lots of ways apps can run arbitrary code, so stopping them via the app store is not feasible. Myself I'm happy my phone is safer.
- kevin_nisbet 6y ago
  > Apple's probably not going to let an app exploiting this zeroday into its App Store... Are you sure about this? I'm far removed from the app store development world, but a cursory glance at the description and the original lightspeed bug seem to indicate this is a problem within the kernel interface, and as such I assume callable by any application?? Sorry, I could be missing something, just curious why this couldn't occur in the app store.
  - saagarjha 6y ago
    I think the implication was that App Store review would catch such things. Personally, I'm not so sure, considering that Snapchat currently ships a binary with syscall instructions embedded in it.
Jyaif 6y ago
Why is he doing that work? Does Apple not fix every jailbreak exploits by themselves?
- saagarjha 6y ago
  Project Zero makes it their job to find things even if manufacturers don't (I'm sure they were in this case, though). In this case I would assume it was just curiosity.
- jchw 6y ago
  In this case, it looks like there is a point to it: > My goal in trying to identify the bug used by unc0ver was to demonstrate that obfuscation does not block attackers from quickly weaponizing the exploited vulnerability.
  - saurik 6y ago
    We all know obfuscation isn't some magic "no one knows how this works now" trick: the goal is to buy time while people are forced to work though your defense and to slow down the proliferation. Now, the "problem" with this is that some people are just really good at pulling things apart, and so one person can spend four hours attacking it and then tell the world how it worked. But then it is more a matter of incentives, and it still isn't the case that there is much universal incentive for it to both be reverse engineered and then documented for others so quickly (even in the world of piracy; the incentives there are fascinating, but still selfish). And in fact, I will argue that this looks like it worked great: yes, someone--and of course, likely many people working in shadowy areas of organized crime, arms dealers, and government contractors--figured it out in hours, and they could have been malicious and used it to attack others. But the real question is then how many such attackers you enable and what their goals are. If you publish an exploit as open source code along with the tool (which some people have done in the past :/), you allow almost any idiot "end" developer to become an attacker: millions of people at low effort instead of thousands or hopefully even only hundreds (when combined with incentives, not just ability). If you publish a closed source binary with obfuscation--one which is restricted to a limited usage profile (like if nothing else it isn't in the right UI form to "trick" someone into triggering it, or where what it ostensibly "does" is too blatantly noticeable) you limit the number of people who both have the time and incentives to work out the vulnerability and then rebuild a stable exploit for it (which is hard) down to a small number of people, almost none of whom (including the attackers) who are then incentivized to publish a blog post (or certainly code) until at least months after it gets fixed (as was the case here). And so, as someone who had been sitting in the core of this community--where everyone is wearing a grey hat, the vendors are the "bad guys", and "responsible disclosure" is being complicit in a dystopia--and dealing with these ethical challenges for a decade, my personal opinion is "please never ever drop a zero day on the world without it being a closed source obfuscated binary" unless you want to drop the barrier to entry so low that you have creepy software engineers quickly using the exploit against their ex-spouse as opposed to "merely" advanced attackers using the vulnerability for corporate or government espionage.
saagarjha 6y ago
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-9859-and-the-lightspeed-vulnerability.html https://www.synacktiv.com/posts/exploit/the-fix-for-cve-2020...
PragmaticPulp 6y ago
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.
thierryzoller 6y ago
So proud to have reverse engineered an 0day. Ok, move on. Nothing to see.
staycoolboy 6y ago
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!
- userbinator 6y ago
  ...or the more interesting and perhaps less plausible explanation: someone who doesn't toe the line, someone who was trying to "take down the system from within"... I often wonder what goes through the minds of those whose work helps companies exert more control over their customers. Maybe some of them are not so "obedient" after all...
  - pcwalton 6y ago
    Hanlon's Razor suggests otherwise. People said that the Windows Metafile bug in 2005 was a backdoor, which was obviously wrong.
- ehsankia 6y ago
  Reguardless of how bad the original fix was, this is why testing is important. The original person should've added tests to make sure that specific issue doesn't come up again, and it would've caught the regression. > Thus, this is another case of a reintroduced bug that could have been identified by simple regression tests.
  - deleted 6y ago
    [deleted]
- thomaslkjeldsen 6y ago
  > Talk about running in circles. So maybe writing and reading useful commit logs is not such a bad idea after all :) Reminds me of this quote: "Those who don't know their history are doomed to repeat it."
MaxLeiter 6y ago
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 https://iokit.racing/oneweirdtrick.pdf (The One Weird Trick SecureROM Hates)
- vanshg 6y ago
  Which just goes to show how useful it is to have these kind of exploits. Imagine if there was a way to fix Checkra1n, and it was fixed a while back. Then, figuring out the details of this exploit would have taken much longer.
- doublerabbit 6y ago
  Interesting, from that slide I should always null my variables after I'm finished with them.
  - sfink 6y ago
    If they're globals, then yes you should. Having dangling pointers anywhere, even in supposedly unused areas, tends to come back and bite you. For locals, why bother? The optimizer will probably discard the writes, and worrying about stack addresses being reused is a waste of mental space and clutters the code.
akersten 6y ago
> 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.
- TwoBit 6y ago
  Isn't the root cause that two entities can free the given memory and have no high level coordination of it? It basically states this in the article.
  - akersten 6y ago
    That's the category of bug (use after free), but that's not the root cause. The root cause would be found from an analysis of the kernel design to understand why it was possible to get into this scenario in the first place. Uncoordinated mechanisms accessing the same data structure (like you mention) might be the root cause, but it didn't feel like this article explored it (not that they need to, since P0 is focused on the exploit itself - I'm just really curious what 'went wrong' with respect to the architecture here).
    - Hackbraten 6y ago
      (I’m trying to recall the Lightspeed bug from memory so I may have some of it wrong.) It all boils down to poor state management in a single algorithm. The algorithm allocates a kernel object, then sends off a subroutine to do some work. (The subroutine happens to run in another thread but that’s not really relevant to the bug.) As part of its job duty, the subroutine is supposed to free the object after its work is done, but only if condition A is true. If A is false, the subroutine won’t free the memory, and it’s implied that the main routine is supposed to free the memory instead. Now the issue is that there’s no common code that checks condition A. Instead, the main routine and the subroutine have slightly different ideas about whether condition A is true or not. The condition’s logic is pretty simple so it’s understandable that the kernel developer decided to write the same condition in two different places and two different forms (instead of e. g. factoring it out into a macro). Still, they managed to get it wrong. The result is that in one particular case, the subroutine thinks A is true. So it frees the object. When the main routine gets back control, it thinks A is false (due to the duplicated, slightly wrong logic), and frees the object, too. There’s only a small time window between those two frees. But the window is large enough that a userspace thread, if it tries often enough, can force its own object into the place where the kernel object used to be, just in time before the double free happens.
etaioinshrdlu 6y ago
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.
Dolores12 6y ago
There is nothing to brag about. I want to own my device. I want to install on it whatever i like.
appybois 6y ago
Working for the wrong side snitchy snitch

346 points by GuardLlama 6y ago

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.

forgotmypw17 6y ago
To me, seems like informant territory.
aarong11 6y ago
But they didn't report it did they? Playing devil's advocate a bit here, but they could have reported it for a bug bounty but they instead chose to use it to create a jailbreak.
- texasbigdata 6y ago
  Maybe reworded, the value accrues to the explainer of the issue to the code writer. Therefore, this dude did something valuable. Ecosystem works. Perhaps.
umvi 6y ago
All this has taught me is that if I find an exploit to unlock <insert DRM'd device> I need to obfuscate the heck out of it to make it as onerous as possible for low-effort bug bounty do-gooders to scoop up a reward from it.
- saagarjha 6y ago
  I don't think anyone is getting a bug bounty, especially from this one.
- snazz 6y ago
  Project Zero researchers don’t take bounties, to my knowledge.
  - saagarjha 6y ago
    Nor have they been ever offered one, to my knowledge: https://twitter.com/i41nbeer/status/1027339893335154688 https://twitter.com/i41nbeer/status/1027339893335154688. I'm actually not sure Apple has ever paid a bounty for anything that wasn't a web issue…
    - jlgaddis 6y ago
      If memory serves, they've been offered but the bounties are always been given to charity. I'm guessing that's a policy/requirement of Project Zero as, presumably, the P0 folks are making "enough" already.
saagarjha 6y ago
> If anything, the exploit writer should get the credit. They did: https://support.apple.com/en-us/HT211214 https://support.apple.com/en-us/HT211214
CountHackulus 6y ago
They did, the article points out that this was caused by a regression. Fixing a memory leak made it such that it reenabled an old bug.
xuki 6y ago
The exploit was public, but obfuscated to make it harder for bad actors to make use of. Apple likely didn't need help to identify the vulnerability, but I'm sure they welcomed it.

albntomat0 6y ago

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

londons_explore 6y ago
Project Zero has uncovered 2033 issues... The majority of those could be used alone to ruin your life. The rest might require 2 (Eg. one for the sandbox, one for the kernel). Thats a team of ~10 security researchers over many years... Considering how many are being discovered each day/month/year, chances are that there are at least hundreds undiscovered... If it only takes one to ruin your life, and a good security researcher can find one in a few weeks, or months at most, the barrier to someone evil is really really low...
- Avamander 6y ago
  > good security researcher can find one in a few weeks s/good/extremely good/ This doesn't change the fact that someone evil will still probably find one.
londons_explore 6y ago
Most experts have expertise on only one or two different OS's or bits of software. The found issues will strongly depend who happens to be on the Google Project Zero team at the moment.
- 6y ago

devenblake 6y ago

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

curiousgal 6y ago
I 100% agree but then again, people choose to buy those products so..
bzb3 6y ago
There are lots of ways apps can run arbitrary code, so stopping them via the app store is not feasible. Myself I'm happy my phone is safer.
kevin_nisbet 6y ago
> Apple's probably not going to let an app exploiting this zeroday into its App Store... Are you sure about this? I'm far removed from the app store development world, but a cursory glance at the description and the original lightspeed bug seem to indicate this is a problem within the kernel interface, and as such I assume callable by any application?? Sorry, I could be missing something, just curious why this couldn't occur in the app store.
- saagarjha 6y ago
  I think the implication was that App Store review would catch such things. Personally, I'm not so sure, considering that Snapchat currently ships a binary with syscall instructions embedded in it.

Jyaif 6y ago

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

saagarjha 6y ago
Project Zero makes it their job to find things even if manufacturers don't (I'm sure they were in this case, though). In this case I would assume it was just curiosity.
jchw 6y ago
In this case, it looks like there is a point to it: > My goal in trying to identify the bug used by unc0ver was to demonstrate that obfuscation does not block attackers from quickly weaponizing the exploited vulnerability.
- saurik 6y ago
  We all know obfuscation isn't some magic "no one knows how this works now" trick: the goal is to buy time while people are forced to work though your defense and to slow down the proliferation. Now, the "problem" with this is that some people are just really good at pulling things apart, and so one person can spend four hours attacking it and then tell the world how it worked. But then it is more a matter of incentives, and it still isn't the case that there is much universal incentive for it to both be reverse engineered and then documented for others so quickly (even in the world of piracy; the incentives there are fascinating, but still selfish). And in fact, I will argue that this looks like it worked great: yes, someone--and of course, likely many people working in shadowy areas of organized crime, arms dealers, and government contractors--figured it out in hours, and they could have been malicious and used it to attack others. But the real question is then how many such attackers you enable and what their goals are. If you publish an exploit as open source code along with the tool (which some people have done in the past :/), you allow almost any idiot "end" developer to become an attacker: millions of people at low effort instead of thousands or hopefully even only hundreds (when combined with incentives, not just ability). If you publish a closed source binary with obfuscation--one which is restricted to a limited usage profile (like if nothing else it isn't in the right UI form to "trick" someone into triggering it, or where what it ostensibly "does" is too blatantly noticeable) you limit the number of people who both have the time and incentives to work out the vulnerability and then rebuild a stable exploit for it (which is hard) down to a small number of people, almost none of whom (including the attackers) who are then incentivized to publish a blog post (or certainly code) until at least months after it gets fixed (as was the case here). And so, as someone who had been sitting in the core of this community--where everyone is wearing a grey hat, the vendors are the "bad guys", and "responsible disclosure" is being complicit in a dystopia--and dealing with these ethical challenges for a decade, my personal opinion is "please never ever drop a zero day on the world without it being a closed source obfuscated binary" unless you want to drop the barrier to entry so low that you have creepy software engineers quickly using the exploit against their ex-spouse as opposed to "merely" advanced attackers using the vulnerability for corporate or government espionage.

saagarjha 6y ago

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-9859-and-the-lightspeed-vulnerability.html https://www.synacktiv.com/posts/exploit/the-fix-for-cve-2020...

PragmaticPulp 6y ago

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.

thierryzoller 6y ago

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

staycoolboy 6y ago

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!

userbinator 6y ago
...or the more interesting and perhaps less plausible explanation: someone who doesn't toe the line, someone who was trying to "take down the system from within"... I often wonder what goes through the minds of those whose work helps companies exert more control over their customers. Maybe some of them are not so "obedient" after all...
- pcwalton 6y ago
  Hanlon's Razor suggests otherwise. People said that the Windows Metafile bug in 2005 was a backdoor, which was obviously wrong.
ehsankia 6y ago
Reguardless of how bad the original fix was, this is why testing is important. The original person should've added tests to make sure that specific issue doesn't come up again, and it would've caught the regression. > Thus, this is another case of a reintroduced bug that could have been identified by simple regression tests.
- deleted 6y ago
  [deleted]
thomaslkjeldsen 6y ago
> Talk about running in circles. So maybe writing and reading useful commit logs is not such a bad idea after all :) Reminds me of this quote: "Those who don't know their history are doomed to repeat it."

MaxLeiter 6y ago

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 https://iokit.racing/oneweirdtrick.pdf (The One Weird Trick SecureROM Hates)

vanshg 6y ago
Which just goes to show how useful it is to have these kind of exploits. Imagine if there was a way to fix Checkra1n, and it was fixed a while back. Then, figuring out the details of this exploit would have taken much longer.
doublerabbit 6y ago
Interesting, from that slide I should always null my variables after I'm finished with them.
- sfink 6y ago
  If they're globals, then yes you should. Having dangling pointers anywhere, even in supposedly unused areas, tends to come back and bite you. For locals, why bother? The optimizer will probably discard the writes, and worrying about stack addresses being reused is a waste of mental space and clutters the code.

akersten 6y ago

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

TwoBit 6y ago
Isn't the root cause that two entities can free the given memory and have no high level coordination of it? It basically states this in the article.
- akersten 6y ago
  That's the category of bug (use after free), but that's not the root cause. The root cause would be found from an analysis of the kernel design to understand why it was possible to get into this scenario in the first place. Uncoordinated mechanisms accessing the same data structure (like you mention) might be the root cause, but it didn't feel like this article explored it (not that they need to, since P0 is focused on the exploit itself - I'm just really curious what 'went wrong' with respect to the architecture here).
  - Hackbraten 6y ago
    (I’m trying to recall the Lightspeed bug from memory so I may have some of it wrong.) It all boils down to poor state management in a single algorithm. The algorithm allocates a kernel object, then sends off a subroutine to do some work. (The subroutine happens to run in another thread but that’s not really relevant to the bug.) As part of its job duty, the subroutine is supposed to free the object after its work is done, but only if condition A is true. If A is false, the subroutine won’t free the memory, and it’s implied that the main routine is supposed to free the memory instead. Now the issue is that there’s no common code that checks condition A. Instead, the main routine and the subroutine have slightly different ideas about whether condition A is true or not. The condition’s logic is pretty simple so it’s understandable that the kernel developer decided to write the same condition in two different places and two different forms (instead of e. g. factoring it out into a macro). Still, they managed to get it wrong. The result is that in one particular case, the subroutine thinks A is true. So it frees the object. When the main routine gets back control, it thinks A is false (due to the duplicated, slightly wrong logic), and frees the object, too. There’s only a small time window between those two frees. But the window is large enough that a userspace thread, if it tries often enough, can force its own object into the place where the kernel object used to be, just in time before the double free happens.

etaioinshrdlu 6y ago

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.

Dolores12 6y ago

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

appybois 6y ago

Working for the wrong side snitchy snitch