How to unc0ver a 0-day in 4 hours or less (opens in new tab)

A friend at Apple told me that the testing story for iOS is complete shit, and they actually rely on hundreds of humans to test their software to make up for poor automated testing.

Apple takes the approach of throwing humans instead of automation at a problem quite frequently [1]:

> The press release mentions RMSI, an India-based, geospatial data firm that creates vegetation and 3D building datasets. And the office’s large headcount (now near 5,000) [used to create Apple Maps]

The lack of automated testing is something Apple is working on fixing, but they're a ways away from having anything substantial. The terrible iOS 13 release quite significantly bumped up the internal priority of stability and testing. iOS 14 is likely to be far less buggy than iOS 13 because of this culture change.

[1]: https://www.justinobeirne.com/new-apple-maps

Don't worry, the exploits are being used only against oppressed minorities[1].

[1]https://arstechnica.com/information-technology/2019/09/apple...

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

That's a bit like saying the root cause of an automobile accident is that two people were driving without a physical barrier between them.

The statement is true but is not a root or a cause. Its a high level description of what happened.

This raises the question, who will come up with Apple product features when all the 0days have been patched?

Or you could just buy an android and not worry about it.

Not even to fan boy, but half of those are things that android did from the go and the rest have been added or are generally easy to do.

In other words:

The current model fails to protect people anyway while providing an extremely strong incentive for the community to publish software that undermines the “security” of the device.

Of course, removing the need to jailbreak for such control would mean that this dichotomy would not have to exist…

> Look at the attacks on various human rights activists

I believe all these begin with browser or existing-app based exploits.

None of them seem to rely on tricking the user into installing a new app. That would be too suspicious for the user, and would entail the attacker uploading their exploit code to apple, and giving apple a full list of users who they exploited...

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.

Maybe this should read "that obfuscating an exploit does little to prevent the bug from winding up in the hands of a talented full time security researcher".

Of course if he was this talented, surely he would routinely diff new kernel versions and realize the old bug had been reintroduced before having to rediscover it in a jailbreak?

It always depends on which side of "security" we're talking about. You could argue that not having access to security tweaks & not being able to see what's going on because the OS is so locked down is a security issue in itself which can be solved by jailbreaking.

Currently, sharing security issues with Apple is a guaranteed that the tooling you are using to get access to your device won't work anymore, there's definitely an bad incentive to not report security flaws at the moment.

This is how it works on Android. Generally on a rooted phone you have a 'manager' like Magisk or Superuser. The first time an application tries to use root, the manager makes a popup and allows you to grant permission temporarily or forever.

Maybe reworded, the value accrues to the explainer of the issue to the code writer. Therefore, this dude did something valuable. Ecosystem works. Perhaps.

Project Zero researchers don’t take bounties, to my knowledge.

I don't think anyone is getting a bug bounty, especially from this one.

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.

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

I generally agree, although I think from what I’ve seen, their researchers are pretty flexible.

My post was to counter folks thinking P0 is a Google hit job, which seems to come up frequently on HN.

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.

Or comments in code. They are very useful when pointing out gotchas.

Hanlon's Razor suggests otherwise. People said that the Windows Metafile bug in 2005 was a backdoor, which was obviously wrong.