[udev]

I don't understand Apple here.

Just put an army of people on fuzzing the shit out of iMessage and all its possible file attachments.

You tried and failed? Fire the bozo who lead the effort. Try again.

You did not even try? Fire the c-level bozo who failed to see it coming and failed to approve such an effort.

But cynically, more and more it feels like some bugs have to stay unfixed, for NSA use, just that NSO is also getting on the game.

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

[hu3]

Cynical reductionist me thinks Apple gets more ROI spending on marketing than in security.

They also spend a ton of engineering resources to prevent customers from using their products as general computing devices with the pretense of hardening security. It works to an extent and the tradeoffs are debatable, at least among tech-savvy folks in HN.

[nssexpression]

This was likely in a codebase that has been fuzzed extremely heavily. There are a lot of bugs that fuzzing cannot possibly reach. I'm guessing NSO group has a lot of talented vulnerability researchers who do code auditing. Companies need to invest in hiring and training these individuals and paying them what they are deserve. Throwing fuzzers at things and calling them secure is part of the problem.

[udev]

What code auditing? Are you claiming NSO has access to iMessage and iOS source code?

NSO seems to be finding more and more bugs by poking a black-box alone, while Apple cannot seem to be able to fix by looking at the source code with all the fuzzing and verification tools, and much more $$$ at their disposal.

[nssexpression]

Sorry I thought it was obvious that I meant reverse engineering the closed source pieces of iMessage and auditing the open source bits. Source code just speeds up the process for vulnerability researchers, so Apple has a leg up in this regard.

"Are you claiming NSO has access to iMessage and iOS source code?"

The last NSO zero-click was in an open-source library reachable from iMessage. This vulnerability is likely no different considering it was in an image decoding library.

NSO group hires many talented security researchers who specialize in reverse engineering and auditing source code. It is hard for people not familiar with security research to understand but there are a lot of very talented code auditors out there who have honed the skill of picking up a new codebase, understanding it better than the developer who wrote it within months, and then finding bugs in it. There are teams of researchers at certain exploit shops who spend their lives focusing on understanding a single target.

Fuzzing is a great tool for finding bugs, but code auditing will always be the best way to find amazing bugs and novel attack surfaces. Researchers who can do both code auditing and fuzzing extremely well (like lokihardt@astr) are even rarer and extremely good because they can both find interesting pieces of code to fuzz through auditing and find amazing bugs while fuzzing.

Apple is and should continue hiring these talented researchers. The point I am making is that they should hire these security researchers even more aggressively and other tech companies should follow. Most of them work at exploit shops like NSO group because they pay a lot better than big tech. One security researcher and one security engineer to every five developers for these critical pieces of code should be the industry standard not 1 security engineer to every 100-1000 devs...

[Obscurity4340]

They also probably use simulation software like Correllium that eerily simulates iOS seemingly to the extent Apple wanted them shut down. If anything, iPhones would be far more secure if everyone could get eyes on their OS and be able to toy with it experimentally. I suspect they aren't the only actor against such radical transparency at the corporate and governmental levels.

[saagarjha]

> exploit shops like NSO group because they pay a lot better than big tech

Ehh…it’s complicated. Often this is not the case.

[itsokimbatman]

You can audit binary code with tools like Ghidra and IDA Pro.

It takes a different mindset to find these type of bugs than it takes to develop software. I won't quite say they're orthogonal skill sets, but pretty close.

If the people finding these bugs don't want to work for Apple, Google Project Zero, etc. there's not really much Apple can do about it.

[beagle3]

It’s not orthogonal, it’s complementary.

Programming mindset is about making sure what’s in the spec works.

Security mindset is about making sure that what isn’t in the spec doesn’t work.

[jbverschoor]

Only requires one corrupt dev