[olliej]

Given all the major tech companies aggressively fuzz everything maybe, just maybe, you're missing the additional possibility: fuzzing is still random and extensive fuzzing does not mean you will encounter the same code paths as anyone else.

You need to understand "do fuzzing" is not a magic trick to find all bugs in software.

Similarly: definitionally you will only ever see the bugs that are not found prior to shipping - any bugs that are found prior to software shipping will have been fixed.

[udev]

Fuzzing is not a magic trick, in the same way as invariants are not, and unit tests are not, and debugging is not.

All these techniques have degrees of mastery, and if applied carefully, and in combination, can save you a lot of grief.

Dumb fuzzing will not get you anywhere, same as dumb unit testing, and dumb debugging.

In this case, iMessage is particularly well suited for some smart fuzzing because all the attack vectors seem to involve smallish malicious attachment files.

[olliej]

You're missing the point: It is possible fro multiple distinct groups to all fuzz the same code and find different non-overlapping bugs.

You are erroneously saying "one group of people found a bug that could be found by fuzzing therefore apple is not fuzzing".

LibJPEG is decades old at this point and is still getting around 10 CVEs a year, despite being one of the projects I believe google constantly fuzzes.

zlib is getting a few a year despite being a vastly more constrained format than anything else imaginable, and again being a heavily fuzzed library.

If "do lots of fuzzing" caught every bug, then you'd get a big release that fixed all of them, and you'd never see any more.

> In this case, iMessage is particularly well suited for some smart fuzzing because all the attack vectors seem to involve smallish malicious attachment files.

I chose to include libjpeg above specifically to rebut this comment. That there are still CVEs coming in for libjpeg this year, despite years of fuzzing should be sufficient to show that even small attachments aren't magically invulnerable due to fuzzing.

Fuzzing is a useful tool but pretending that some project or software is going to be secure because it's been fuzzed a lot is nonsense, and pretending that fuzzing will find all the bugs is complete fiction.

Even software written in memory safe languages benefits from fuzzing: a memory safe language simply means your code will not continue if doing so would result in a memory safety violation, but for most memory safe languages that means at best an exception, but in most cases it means termination - that's what you get in Rust, Swift, or even functional languages like Haskell - and program termination can mean user data loss, or at least a bad user experience, so fuzzing is helpful even if bugs don't cause "security" issues.

[saagarjha]

Fuzzing the space of smallish attachment files is nowhere near a solved or even an easy problem.