How are image parsing exploits still a thing in 2021? Can Apple not use Rust? I struggle to understand why Apple is still relying on C/C++ in such a well known security hotspot.
...This blog post discussed three improvements in iOS 14 affecting iMessage security: the BlastDoor service, resliding of the shared cache, and exponential throttling. Overall, these changes are probably very close to the best that could’ve been done given the need for backwards compatibility, and they should have a significant impact on the security of iMessage and the platform as a whole.
https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
"It also indicates that Apple has a MAJOR blinking red five-alarm-fire problem with iMessage security that their BlastDoor Framework (introduced in iOS 14 to make zero-click exploitation more difficult) ain't solving."
And:
"BlastDoor is a great step, to be sure, but it's pretty lame to just slap sandboxing on iMessage and hope for the best. How about: "don't automatically run extremely complex and buggy parsing on data that strangers push to your phone?!"
Only run the known dodgy parsing code on stuff coming from people in your contact list, not just on any random image that comes in.
On incoming message, check one thing and one thing only: is the sender in the contact list? If YES...
+ Run the message through BlastDoor and continue as normal.
If NOT…
- Stop all non-essential parsing immediately.
- Continue with a flow similar to modern e-mail clients (To increase your privacy, we have blocked some elements of this message).
- Only continue normal message parsing if the user explicitly consents.The key to user satisfaction isn't security, it's consistent marketing reminders of "security".
Apple users here are often forced into the ecosystem due to iOS or safari dev, but the majority of Apple users care more about the name of the iPhone than performance. This is the nature of Veblen goods.
On the business end, sure.
But https://support.apple.com/en-us/HT201222#:~:text=the%20previ...
The assumption has to be that Apple quietly fixes minimum a hundred times more security bugs in their products, than the ones the occasional Project Zero blog post highlights.
Consider any long-lived complex library. Count the bugs fixed since initial release. That’s your baseline — you can expect that order of magnitude of bugs in the initial release of your rewrite. Perhaps a new language will eliminate some classes of bugs, so maybe you can cut that number in half or even to a quarter. But you need to come to terms with that number. Now add on the number of bugs due to compatibility. Image formats generally are not tightly spec’ed, meaning the de facto standard libraries become the de facto standard — that is, the library being rewritten.
Rewrites are a long road that starts off one step forward and three steps back. It could sill be worth it, depending on the case. But an effort to “rewrite in rust” that doesn’t account for this will fail.
My point was that the test suite you start with for your rewrite will be (or at least should be) a lot better than the test suite you had when you started writing the original code.
The spec will likely be better too. Also, you can learn a lot from the previous iteration.
These effects, plus the benefits of the new language, have the potential to reduce the bug count dramatically. Maybe even by an order of magnitude.
Having said that, you're certainly right that there are some steps back and the net cost or benefit is likely highly context-dependent.
It would be great to have more data on projects that have done this, to help people estimate the costs and benefits in their context.
Writing image decoders for several formats is hard but it's not so hard that a trillion dollar company can't write a good one.
Anyway, Apple's safe language is Swift, which they are clearly pushing and using more of as time goes by.
But also missing the point that you can't implement a subclass or what have you in rust, and if every interface you have is C then you have an exercise in mass unsafe code.
> doesn't have a path to interact with any language other than C
> so new code in existing libraries may not be feasibly written in rust
Not sure exactly what you mean here.
I remain highly skeptical of any messaging app or communication chat program, email client that lets people "embed" arbitrary content in it.
For example, Java is also memory-safe, but Java doesn't have first-class array slices.
What part of scanning through some immutable array of bytes to-be-parsed would be so definitively better in Rust?
Any sensibly written parser code would result in the compiler optimizing away all reference count operations. Only the most naive ARC implementations mutate the count for every reference pass implied by the source.
So again... why would it be a sensible choice to use Rust at Apple, where they created and use Swift heavily? Where the problem is that they're using some old unsafe parsing library instead of one written in a safer language?
We know that they are because they've posted job descriptions for Rust-specific jobs.
Unfortunately it means there are always performance cliffs: you make some change to your code that looks innocuous and suddenly your performance collapses (e.g. because a function is now too big to be automatically inlined, so certain optimizations don't work anymore) --- and you don't understand why.
In this vein, both Swift and Rust performance will succumb to any number of their IL-level (and LLVM's IR-level) optimizations being disabled by some seemingly orthogonal change to the source code.
Either way, I hope Apple (and others) can squash this entire category of bugs soon!