It’s not just the lack of sandboxing — iMessage uses language-level serialization of object graphs. This design is never suitable for sending across privilege boundaries. Apple should replace the format with a reasonable wire format. If this requires updates to apps that integrate with iMessage or breaks interoperability with older iOS versions, so be it.

Can you explain a bit? Are you saying they send messages as Swift objects/structures directly? Instead of a serialization like JSON/CBOR/Proto/Proprietary/etc?

Search through https://googleprojectzero.blogspot.com/2019/08/the-fully-rem... for NSKeyedUnarchiver.

This seems to be functionally much like Python’s pickle, Boost.Serialization, Java’s object serialization, etc. These techniques seem clever, and they are genuinely useful for prototyping and for certain applications that inherently have no security concerns, but they are not at all suitable for network use. Fundamentally, for network use, one should define a data format, an API, etc and implement it. Using object serialization is backwards — it’s writing the code and then asking a framework to magically network it, and the result is that it networks it too much.

(There are a few systems for writing code and a network protocol simultaneously that treat security as a first-class consideration. The E language comes to mind. I still wouldn’t use E objects to represent data for interoperability reasons if nothing else. But ObjC is not E, and Apple’s design is inexcusable in 2020.)

I don’t expect anything as old and critical as iMessage is written on Swift. Chances are it’s all Objective C underneath.

I hear that parts of the app have been rewritten in Swift: https://twitter.com/5aelo/status/1340995243320205313

It’s not clear if this was involved in the exploits mentioned here.

It has been proven to be a weak point in their implementation with previous exploits, and it's likely to be the case here - it's a good guess at least.

Will be interesting to read a write-up.

Apple has been hardening their software to use NSSecureCoding and similar since then, so I would be surprised if this would still be a problem (since this is fairly easy to check for and fix). My guess is that this is probably a run-of-the-mill overflow or corruption.

That’s like saying one can harden pickle by specifying magic options and trying to limit the supported classes to a very large list instead of an effectively infinite list. Sure, you can make the the blatantly insecure mechanism harder to exploit, but it’s still a horrible design.

I think Apple could address this for real is one of two ways. They could replace the protocol entirely, or they could treat the existing baroque protocol like any other network protocol and write a grammar and parser for it.

As an analogy, suppose you had a wire format like XML, and you had the clever idea to process it in a dynamic language like Python or ObjC by looking up each tag in a list of all known types and trying to instantiate it. Sure, it would work, and you would be exploited all the time. NSSecureCoding limits the available types to a large and apparently still open ended list instead of literally every type that the deserializer can make sense of.

This is why no amount of "but apple cares about privacy" will ever make me drop the "Trust but verify" I try to live by (money allowing), even if I believe they care more than most.

I look at the “Apple cares about privacy” as a qualified “more than them other OS &mobile firms”, not “enough that you should blindly trust us”. No one’s security is perfect

Including your own! A big part of opsec is putting systems in place that mitigate dangerous but unavoidable human behaviour.

Apples security model seems to mostly be based on fixing issues fast and pushing them out to almost all users. That means the only people at risk are those worth burning a brand new exploit on. The average consumer is pretty safe.

When it come to security (and literally everything else), don't even both with with the "trust" part and skip directly to "verify".

iMessage is not being attacked because it's not as sandboxed as other apps. It's being attacked because it's accessible with zero clicks.

For an attack like this you need to chain an iMessage exploit with an LPE, and the LPE can be launched from any other app.

LPE. What is an LPE?

Not sure, but it might mean Local Privilege Escalation. It’s one thing to take control of the iMessage process, it’s another to then gain kernel level access.

Yes, it means local privilege escalation.

In this case it might not be necessary to escalate privileges, as iMessage itself may have been the target.

Apple has never devoted enough care, resources, or money to cybersecurity. It’s just a fact.

They’ve also never devoted enough care, resources, or money to network architecture and how important availability is (with fairness, they have improved in this area in the last couple of years due to the major iCloud outages they had).

Apple doesn’t hire mainstream IT people and cybersecurity people from the enterprise realms. There is a vast amount of talented people and knowledge they simply ignore because the Apple culture is too hip and cool for that.

Steve Jobs is primarily the blame for all the above. He treated the departments and any person that cared about enterprise like dirt. Steve Jobs always said Apple is a consumer company. This philosophy has obviously carried on.

Every Apple security developer I've interacted with has been astonishingly competent. Unfortunately Apple's corporate policies mean they're very rarely in a position to publicly discuss things they're working on, so their visibility is significantly diminished (one of the reasons I wouldn't work there)

They absolutely do hire cybersecurity folks from enterprise companies. Source: I know them.

That is wonderful news. Thanks for the update.

Some of my most competent security friends work or used to work for Apple.

They are, indeed, not "IT people and cybersecurity people from the enterprise realms", because those would be wholly unqualified to work on iOS security. The people actually working on iOS security are hackers and embedded security experts. As they should be. The enterprise cybersecurity world has approximately nothing to do with something like security of a mobile device (e.g. the people in that field wouldn't know the slightest thing about cutting edge exploit mitigations or hardware assisted countermeasures like pointer authentication, memory protection and IOMMUs, etc).

Apple has some of the top security people in the business. If “enterprise” experience is your bar, they have former Microsoft, Amazon, Google people ranging from junior engineers to VPs, including their current CISO. They have also hired non-enterprise people who wrote exploits like the one NSO used, as well as other prominent hackers.

but which tech companies do devote enough care, resources and money to cybersecurity?

I always figured the industry never really rewarded those things over aspects (e.g. time to market).

"Cybersecurity" is a meaningless buzzword, but I can give you more specific statement.

Which tech companies devote enough care and have competent personnel working on embedded consumer device security?

Answer: Apple and Microsoft (Xbox group).

(Google is nowhere close because they don't design their own silicon, and the OEMs they rely on are incompetent in this field, so their efforts can only go so far, no amount of hiring competent sec folks will fix that problem).

I wonder if this weakens their "security" argument in the appstore walled garden case.

It seems like a fairly slam dunk argument that at very least they can't be trusted to do it of their own accord.

iOS and macOS don’t allow to delete many of their apps. Why on earth I have to have iMessage if I don’t use it?

It is hard to read and impossible to send an SMS on iPad without activating iMessage. I don't understand why this hasn't been considered anti-competitive behavior already. It is completely normal to send and receive SMS messages on Android tablets...