That's where I think Rust could be a game changer, if all those deserialization libraries used in phone would be written in safe Rust it woudn't be an issue.
Now, there are certainly advantages different languages have in ease of writing tests and things like that. There's also formal verification. But unlike memory errors, it's impossible to know if you told the computer to do something you didn't intend.
It's true you'll never be able to catch all logic errors automatically, partly because you need full correctness specifications for that.
But languages like Rust with powerful static type systems can catch lots more important logic errors than C, or C++ --- e.g. using typestate (catches bugs with operations on values in incorrect states), affine types (catches bugs with operations on "dead" values), newtypes (e.g. lets you distinguish sanitized vs unsanitized strings), sum types (avoids bugs where "magic values" (e.g. errors) are treated as "normal values").
Also modern languages like Swift, and Rust to a lesser extent, are treating integer overflow as an error instead of just allowing it (or worse, treating it as UB).
Eventually it was removed. https://pcwalton.github.io/2012/12/26/typestate-is-dead.html
> The reason was that “in practice, it found little use”
And of course the proof is only for those properties that you write down, and you could also have a bug in the spec for those properties.
The best hope for legacy C and C++ code right now is a combination of extensive fuzzing and dynamic analysis to detect as many memory corruption bugs as you can, plus mitigations in CPUs and compilers to make it harder to turn memory corruption bugs into malicious execution, plus sandboxing to limit the damage of malicious execution. This exploit chain demonstrates techniques to bypass that entire mitigation stage (and also shows that Apple severely bungled their sandbox design).
This doesn't bode well for the mitigation approach. They add significant complexity to the silicon and software stack, which has a cost in performance, but also ultimately security --- at some point we will see these mitigations themselves contributing to attack vectors. In return they make exploitation a lot more difficult, but mitigation bypass techniques can often be packaged and reused. For example stack overflow techniques have been effectively mitigated but that doesn't matter to attackers these days, who are now very good at using heap overflow and UAF. Meanwhile those stack overflow mitigations (stack cookies etc) still have to remain in place, making our systems more complex and slower.
The WUFFS code to do this sort of stuff (parse file data, turn it into an array of RGB pixel values) is not only inherently safe, it's also typically faster than you'd write in C or C++ because the safety gives programmers that fearlessness Rust talks about for concurrency. The language is going to catch you every single time you fall, so, you get completely comfortable doing ludicrous acrobatics knowing worst case is a compiler diagnostic or a unit test fails and try again. When you have a hidden array overflow in C++ it's Undefined Behaviour, when you have a hidden array overflow in (safe) Rust it's a runtime Panic, when you have a hidden array overflow in WUFFS that's not a valid WUFFS program, it will not compile now it's not so hidden any more.
So you're right, this doesn't bode well for mitigation - the answer isn't "more complex and slower" but "use the correct tools".
Unlike Rust, WUFFS isn't a general purpose language it can only express a subset of possible programs. For example, WUFFS can't express the program NSO wanted here ("Provide a way to escape from this sandbox") whereas of course in a general purpose language that would feel annoyingly restrictive. What if you want to escape from the sandbox?
WUFFS is exactly the right tool for, say, parsing a file you received to turn it into an image for display on the iPhone's screen.
Except, of course, if your focus is on features at all costs. If you don't care about security then it sucks that WUFFS can't take a file and maybe overwrite the operating system or whatever.
> By sending a .gif iMessage attachment (which was really a PDF) NSO were able to remotely trigger a heap buffer overflow in the ImageIO JBIG2 decoder.
While rewritting the world is not possible, all these attacks show that definitely new systems should probably not be written in memory unsafe languages.
> Late last year we published a writeup of the initial remote code execution stage of FORCEDENTRY, the zero-click iMessage exploit attributed by Citizen Lab to NSO.
The sandbox escape only uses logic bugs:
> In this post we'll take a look at that sandbox escape. It's notable for using only logic bugs.