>One of the major changes in iOS 14 is the introduction of a new, tightly sandboxed “BlastDoor” service which is now responsible for almost all parsing of untrusted data in iMessages (for example, NSKeyedArchiver payloads). Furthermore, this service is written in Swift, a (mostly) memory safe language which makes it significantly harder to introduce classic memory corruption vulnerabilities into the code base.

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

From later in that Twitter thread:

"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?!"

That tweet doesn't make a lot of sense, because it's essentially saying "don't let people send you images".

To the my inner armchair security enthusiast, a good solution looks like this:

  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.

to me it says:

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.

All part of the ad model

This sounds interesting, but there’s not enough detail for me to understand what you mean. Care to elaborate?

I'd expect so, but the exploits we're talking about are post-BlastDoor, so something clearly isn't working.

Or fuzzing? Why is it that Google's Project Zero has to point out their mistakes for them? Apple's complacency on security is infuriating.

Apple doesn't admit wrong doing. Take their multi year long denial of butterfly keyboard issues.

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.

> Apple doesn't admit wrong doing.

On the business end, sure.

But https://support.apple.com/en-us/HT201222#:~:text=the%20previ...

That’s a bit of a weird framing. Project Zero point out mistakes in Google’s products too. It’s just that they’re visible.

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.

Given their lackadaisical approach to bug reports filed by external researchers, and their grudging payments on their own bug bounty program, I think you are giving them far more credit than they deserve.

"Rewrite everything in rust" is not useful advice, and many of the decoders in ImageIO are open source libraries, that presumably have the same flaws (so you get "why isn't project X using rust" as well)

"Rewrite everything in Rust" is not that useful, but "write new code in Rust so you're not digging deeper holes" and "rewrite your most sensitive code in Rust" is pretty good advice.

Define "new" code - rust has no ABI stability story, and 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.

Anyway, Apple's safe language is Swift, which they are clearly pushing and using more of as time goes by.

You can expose a C ABI, and so it’s a drop-in replacement for things that used to talk to C code. Which is virtually everything.

not on Mac/I/watch/tvOS where much of the core platform API is objective-c (Which swift has first class support for), and C++ (because of poor 90s decisions).

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.

Both Objective C and C++ can call things that use the C ABI. Rust code ships in real products on those platforms.

Apple is using Rust too. We don't know how much, because Apple.

> doesn't have a path to interact with any language other than C

https://crates.io/crates/cxx

> so new code in existing libraries may not be feasibly written in rust

Not sure exactly what you mean here.

And you run the risk or introducing new bugs as memory bugs aren't the only bugs there are plus rust doesn't catch all of them.

When your entire platform is plagued by security issues in one component for years. Issues that at the end of the day are causing huge personal harm to your customers. Perhaps it is time to suck it up and rewrite the damn thing in a memory safe language.

A great line in a great movie "It is not economicly viable"

In other word the 'cost' reputational or monetary of a few dead journalists/activists is less than that it would take to make it safe.

There is a bit of a risk of new bugs that Rust doesn't catch, but if your development process is at least modestly competent you'll have a large suite of automated tests for the bugs you found in the previous iteration of the software, which you can reapply to the new Rust code.

It’s the new bugs that didn’t exist in the original code that you need to be concerned about.

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.

> That’s your baseline — you can expect that order of magnitude of bugs in the initial release of your rewrite.

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.

Your cost benefit analysis is off. Which would you rather have, a broken jpeg once in a blue moon or a hacked phone?

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.

Anyone remember about 20 years ago, there was a remote code execution possible by simply getting outlook express (internet explorer) to load a custom crafted jpeg? Things haven't changed much.

I remain highly skeptical of any messaging app or communication chat program, email client that lets people "embed" arbitrary content in it.

Things haven't change because there is a god like mindset in SW development. "I want my program to do everything". And the web browsers and messaging apps are the worst. They use a miriad of libraries to parse untrusted code and they have components which sometimes run with elevated privileges. What can go wrong ?

What makes Rust especially good at protecting against parser vulnerabilities?

It's memory-safe (assuming you avoid the use of the 'unsafe' keyword) and it's performant. In particular, for fast parsing of large objects you want to avoid copying data as much as possible, and Rust's lifetime machinery lets you do that without introducing memory safety issues.

For example, Java is also memory-safe, but Java doesn't have first-class array slices.

Swift has all of these things. It also has the exact same performance ceiling as Rust.

Nope. Swift manages memory via reference counting, which turns read-only workloads into read-write workloads, which is inherently problematic.

Yep. It's the same performance ceiling. Borrow checking is not the panacea its made out to be. It's just enforcing single ownership.

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?

"A sufficiently advanced compiler will optimize all the overhead away" is the standard line for all high-level languages with automatic memory management. It works for tracing GC too, you just need "sufficiently advanced" escape analysis.

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.

I agree that could happen, but a parser would have to be coded pretty strangely to disable these basic ARC optimizations. I don't imagine a parser needing to hold and release references beyond the call stack.

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!

If Apple were a less secretive company, you could ask the teams that are using Rust about why, but I doubt they'll directly answer.

We know that they are because they've posted job descriptions for Rust-specific jobs.

Even harder to understand why it's so important for Messages to have special functionality so that has to be integrated with the OS instead of run in user space.

Messages code does run in userspace.

Oh, then I stand corrected. The last time a vulnerability in Messages was making the rounds, I thought that I learned it was possible because Messages is part of the OS and not just a pre-installed app, though I can't remember where I read it. I'd be glad to hear that I'm wrong about that though.

This is a case where using Wuffs would be a better idea than Rust: You get more safety than Rust and you can incrementally convert the codebase.

Apple is using Rust, but not for this. Or at least, I haven’t heard of it.

I don't think any Rust ships on iOS (but would be very interested in hearing corrections!)

If by “on iOS” you mean apps, it’s not super popular but it does. Cloudflare’s 1.1.1.1 app is probably the biggest. If you mean “as part of” then I don’t believe so, yes.