5 ms·

One thing I like about this post is how it enumerates all of the dead ends that involved a lot of investment but produced no fruit. This is what is difficult ab

One thing I like about this post is how it enumerates all of the dead ends that involved a lot of investment but produced no fruit. This is what is difficult about exploiting hard targets. What the general public doesn’t see is the massive amounts of “wasted” time involved in bug hunting. Instead, they see the headline about how some wunderkind exploited X in a matter of seconds or minutes, conveniently omitting the part where that person spent the last year staring at code, writing tools, fuzzers, test harnesses, and finding nothing at all - not knowing if they would ever find anything, or if there is even a bug to be found.

jchw 7y ago
There is something to be said though, and that is that there is always something to be found somewhere. Lacking toolchains that can fully eliminate bugs, there will always be bugs. And even if there were legitimately no bugs, that doesn’t mean there won’t be bugs introduced in future releases, or bugs even outside the software itself. The low hanging fruit has definitely been thoroughly picked these days, at least in software like iOS. But yet with pretty much near certainty, exploits find a way. Perhaps even more fascinating, is that closing off one class of exploits always seems be followed by new kinds of exploits, like clockwork. You’d think eventually this would stop happening, but so far it hasn’t. CPU side channel attacks may not be completely new, but they’ve emerged as one of the new big targets as of late. I really know little about security personally and obviously the amount of work that goes into serious security research should never be underestimated but I’m impressed at the inevitability of security bugs. Very few large programs escape a regular cycle of bugs. Maybe OpenBSD is the best example of Pretty Secure software.
- wahern 7y ago
  > The low hanging fruit has definitely been thoroughly picked these days The problem is that vendors aren't in the business of perfecting existing software. They're in the business of pushing out big, bold, feature-rich changes and additions. There's always new low hanging fruit.
  - panic 7y ago
    The vulnerabilities found in the article support your argument: SMS and MMS, which barely ever change or get new features, were much more secure than iMessage, which constantly gets new features and architectural changes.
    - wahern 7y ago
      There was a Microsoft Research paper several years ago which looked at the relationship of exploits to age of code in BSD kernels. The number of exploits in older code diminished over time, but that was often offset by the higher prevalence of exploits in newer code. That much is intuitive, but it's good that there's some well researched empirical evidence showing that that's the case. We can hypothesize that better languages and better mitigations (e.g. ASLR) can improve the situation across the board, and I don't doubt that that's the case, but I haven't yet seen the evidence. (Maybe I missed it?) It's probably too early as it's difficult to make apples-to-apples comparisons across those aspects.
  - ianamartin 7y ago
    Are you totally and completely unaware that Apple actually does dedicate some annual cycles to bug fixes, performance improvements, and stability? And that they've done this many times in the last 20 years? Your generalization seems a bit broad.
    - jamez1 7y ago
      So what does the software look like up until those 'annual cycles'? It's pretty clear from the economic incentives of the companies producing the software, the sheer quantity of exploits found, and the surprisingly low amount of QA that would be needed to catch most bugs that the aforementioned view is correct.
- fulafel 7y ago
  There are tiers of low-hanging. I think we're just seeing the end of the infosec stone age. It's still plain that OS vendors continue to make big compromises, by eg continuing to use C/C++ to handle untrusted data for decades after the risks became obvious, and we're constantly seeing C-caused vulnerabilities like Windows RDP server remote root, WhatsApp remote root, Broadcomm and Qualcomm Wlan RCEs, etc. The memory safety laissez faire attitude has also held back the state of the art in other fronts besides memory safety, because it's not so interesting to eliminate other classes of bugs while the elephant remains loose in the room.
taf2 7y ago
Sounds like fishing
snowwrestler 7y ago
This might also be useful to counter the sometimes line of complaint that Google only runs Project Zero to make their competitors look bad. While they found some exploitable bugs on the iPhone here, they also found (and reported) that quite a few systems did not seem currently exploitable. It seems clear this is not a hit job, at least to me.
- luch 7y ago
  Sorry but it will take more than a blogpost for me to believe it. When P0 recruits two prominent Chrome hackers (Ned Williamson & Samuel Gross) and make them work directly on iOS, it look like a hit team to me.
  - dmortin 7y ago
    Only if the guys working on other systems are less talented. If equally talented guys work on other systems then it's not a hit job, and I'm sure google puts its best guys to find holes in google products.
  - kbenson 7y ago
    If Google's idea of a hit squad is to pay a few hundred thousand dollars worth of salary to have people do your own bug searching for you and give you a few months to fix it before letting anyone know (or until after you've fixed it, if sooner), then sign any company I'm working for up, and I'm sure there are plenty of other companies that would love the attention too. Apple gets attention from them because a lot of people have apple hardware and software. That means problems there have a higher impact than on some less used product. Apple is more than welcome to respond with its own researchers finding Android and other software bugs, and we'd all be better off if they did.
    - close04 7y ago
      I don't think Apple has a problem with this unless it's irresponsible disclosure. They get a service from P0 and they're quite fast at fixing the issue which works to their advantage. When an exploit is published it will always say "Apple already fixed the issue" which works just great for their image with customers.

jchw 7y ago

There is something to be said though, and that is that there is always something to be found somewhere. Lacking toolchains that can fully eliminate bugs, there will always be bugs. And even if there were legitimately no bugs, that doesn’t mean there won’t be bugs introduced in future releases, or bugs even outside the software itself. The low hanging fruit has definitely been thoroughly picked these days, at least in software like iOS. But yet with pretty much near certainty, exploits find a way. Perhaps even more fascinating, is that closing off one class of exploits always seems be followed by new kinds of exploits, like clockwork. You’d think eventually this would stop happening, but so far it hasn’t. CPU side channel attacks may not be completely new, but they’ve emerged as one of the new big targets as of late. I really know little about security personally and obviously the amount of work that goes into serious security research should never be underestimated but I’m impressed at the inevitability of security bugs. Very few large programs escape a regular cycle of bugs. Maybe OpenBSD is the best example of Pretty Secure software.

wahern 7y ago
> The low hanging fruit has definitely been thoroughly picked these days The problem is that vendors aren't in the business of perfecting existing software. They're in the business of pushing out big, bold, feature-rich changes and additions. There's always new low hanging fruit.
- panic 7y ago
  The vulnerabilities found in the article support your argument: SMS and MMS, which barely ever change or get new features, were much more secure than iMessage, which constantly gets new features and architectural changes.
  - wahern 7y ago
    There was a Microsoft Research paper several years ago which looked at the relationship of exploits to age of code in BSD kernels. The number of exploits in older code diminished over time, but that was often offset by the higher prevalence of exploits in newer code. That much is intuitive, but it's good that there's some well researched empirical evidence showing that that's the case. We can hypothesize that better languages and better mitigations (e.g. ASLR) can improve the situation across the board, and I don't doubt that that's the case, but I haven't yet seen the evidence. (Maybe I missed it?) It's probably too early as it's difficult to make apples-to-apples comparisons across those aspects.
- ianamartin 7y ago
  Are you totally and completely unaware that Apple actually does dedicate some annual cycles to bug fixes, performance improvements, and stability? And that they've done this many times in the last 20 years? Your generalization seems a bit broad.
  - jamez1 7y ago
    So what does the software look like up until those 'annual cycles'? It's pretty clear from the economic incentives of the companies producing the software, the sheer quantity of exploits found, and the surprisingly low amount of QA that would be needed to catch most bugs that the aforementioned view is correct.
fulafel 7y ago
There are tiers of low-hanging. I think we're just seeing the end of the infosec stone age. It's still plain that OS vendors continue to make big compromises, by eg continuing to use C/C++ to handle untrusted data for decades after the risks became obvious, and we're constantly seeing C-caused vulnerabilities like Windows RDP server remote root, WhatsApp remote root, Broadcomm and Qualcomm Wlan RCEs, etc. The memory safety laissez faire attitude has also held back the state of the art in other fronts besides memory safety, because it's not so interesting to eliminate other classes of bugs while the elephant remains loose in the room.

taf2 7y ago

Sounds like fishing

snowwrestler 7y ago

This might also be useful to counter the sometimes line of complaint that Google only runs Project Zero to make their competitors look bad. While they found some exploitable bugs on the iPhone here, they also found (and reported) that quite a few systems did not seem currently exploitable. It seems clear this is not a hit job, at least to me.

luch 7y ago
Sorry but it will take more than a blogpost for me to believe it. When P0 recruits two prominent Chrome hackers (Ned Williamson & Samuel Gross) and make them work directly on iOS, it look like a hit team to me.
- dmortin 7y ago
  Only if the guys working on other systems are less talented. If equally talented guys work on other systems then it's not a hit job, and I'm sure google puts its best guys to find holes in google products.
- kbenson 7y ago
  If Google's idea of a hit squad is to pay a few hundred thousand dollars worth of salary to have people do your own bug searching for you and give you a few months to fix it before letting anyone know (or until after you've fixed it, if sooner), then sign any company I'm working for up, and I'm sure there are plenty of other companies that would love the attention too. Apple gets attention from them because a lot of people have apple hardware and software. That means problems there have a higher impact than on some less used product. Apple is more than welcome to respond with its own researchers finding Android and other software bugs, and we'd all be better off if they did.
  - close04 7y ago
    I don't think Apple has a problem with this unless it's irresponsible disclosure. They get a service from P0 and they're quite fast at fixing the issue which works to their advantage. When an exploit is published it will always say "Apple already fixed the issue" which works just great for their image with customers.