We've seen numerous iMessage bugs over the years inc. full OS take-overs (often used for jailbreak), soft bricking (endless restarts due to corrupt notifications/requiring a factory reset), crashes that reboot the phone (once), and a bunch of potential for escalation/code execution.
None of this is possible with apps in the normal iOS sandbox. The apps themselves would crash, but they're context confined, they cannot bring down the underlying OS, write invalid notifications, or cause a kernel panic.
But they've designed iMessage to act like a part of the underlying OS for no real reason. You could very easily hand off the most hazardous parts of iMessage's inner workings into the app's context, or even another user space/context confined service, and just let them crash like normal apps do.
Ten years ago it was common for font processing to happen in the kernel. This was problematic because front processing is hard, and bugs occur. Since then we've seen many migrate fonts into userland. Why is iMessage's security model so far behind the times, it is a lot less critical/performance impacted than fonts, but yet has worse security than most font systems in 2019?
These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created.
You made my day thanks !
Can we be friends? This is incredible.
2002 called.
1. must display over whatever the user is doing (sort of like a Windows elevation prompt) and
2. must not be handed to userland in a way that it could be automatically recorded or persisted, other than by the user's explicit action.
Giving SpringBoard the ability to render SMSes is really the only way to implement Flash SMS in a way that adheres to its semantics.
There are other types of SMSes as well—WAP Push messages, for example, or WMI (voicemail indicator) Activation messages. Heck, your carrier can even use SMSes to directly write data to your SIM card. These aren't so clearly a layering violation as Flash SMS, as they are just pure OS-layer concerns; but if you're already implementing a kernel library for "SMSes triggering OS-level functionality" for Flash SMS and the like, you may as well put the code to handle these cases in there as well.
Non-techies take a lot of the core infrastructure and tooling for granted, not realising just what a heap of technical debt and accrued complexity it all is, and therefore just how hard it is to keep secure, despite the large security budgets and talents of the big FAANG companies.
It’s only by these lower levels being attacked and yielding bad PR for their parent companies will we eventually see less of a focus on new features for core ecosystem platforms and more of a focus on reducing the technical complexity and improving the security of what we have.
This will however need to be combined with technology journalism that’s more focussed on putting such vulnerabilities into accessible stories for the layperson and less focussed on being the unofficial marketing wing of technology companies on announcements.
The real kicker here is that someone was clearly trying to do the correct thing (see mentions of secure coding), but the way secure coding works meant that arbitrary subclasses of any type that declared itself as supporting secure coding could be instantiated. Because the subclasses don't necessarily actually support secure coding you get much sadness.
There are things that could be done to make deserialization safer, but the core problem will remain that the untrusted content gets to specify the classes that will be instantiated.
iMessage also predates MessagePack, BSON, and many of the other now "common" and "obvious" serialization formats, so you're (kind of) saying "why didn't it use a format that didn't exist".
The reality of course is that in addition to everything else NSCoding is the language supported serialization system, and not using it would have been an example of "reinventing the wheel". The reality is that the engineers using NSCoding + NSSecureCoding quite reasonably expected it to actually be secure (it's right in the title).
All those things aside it irks me that any of the message processing happens in the springboard process rather than a separate sandboxed process that doesn't have essentially complete access to everything that exists.
The problem is that the core design of NSCodable (and NSSEcureCoding) is that the serialized data get to specify the type to instantiate, and the way supportsSecureCoding is exposed means that the claim to secure coding is inherited.
The former is a fairly common problem in serialization systems, and the security flaws in that approach resulted in the subsequent NSSecureCoding APIs.
The latter is a byproduct of how secure coding is implemented, and it results in any user of NSSecureCoding needing to be aware of all classes that may be transitively pulled into their address space. The subclassing semantics means that even the explicit list of allowed classes is not sufficiently robust - e.g '@interface ArbitraryInsecureClass : NSData' means ArbitraryInsecureClass can be instantiated if you allow NSData in the secure coding list, and ArbitraryInsecureClass could be declared in some transitively included framework, and is generally leaked implementation details.
These are all "fixable" for some value of fixable constrained by binary compatibility (though some of it could be mitigated by Darwin's linked-on-or-after mechanisms). There are a variety of steps that Apple could take that would make the entire NSCoding mechanism much more safe/secure without (afaict) necessarily breaking anything, though obviously I don't have access to the compatibility information they probably have.
Things I would do (if I were king?):
* Compiler warning when you subclass a class that declared supportsSecureCoding
* Make the allowed classes restrict to explicit classes rather than just conforming classes (e.g. if you say NSData you can't instantiate a subclass of NSData) - I would give good odds of this breaking things
* Rather than just checking the value of TargetClass.supportsSecureCoding I'd query the runtime to require supportsSecureCoding being a direct class member of TargetClass
* I would consider adding a "+property secureClass: Class" (or whatever the syntax is) that is instantiated, so even if you aren't using secure coding you end up instantiating a sane type - though it would be "optional" due to existing code and objects not having the property. But then at least Apple could go through the core types in Foundation (Array, Data, String, etc) and make it so you would only ever instantiate understood classes.
This would make the API slightly less footgun heavy.
Serialization bugs are the worst, since receiving weird, untrusted data happens all the time. People think this is about Java and class names and stuff, but it's really about receiving multimedia and decoding it in a performant way.
When will people discover all the vulnerabilities in video codecs, fonts and shaders?
This bug reminded me a bit of Heartbleed actually; it’s pretty different but has that one similarity of two payload lengths, one reported and one actual, disagreeing and not being reconciled, causing memory bugs.
Even with memory safe languages, when you go beyond basic serialisation and look at libraries like Jackson for Java, you discover _very_ questionable designs such as providing an API that makes it all too convenient to switch on a feature which allows user-provided strings to control which classes to instantiate. They solve this using a blacklist of “known bad classes”, which seems to be a workaround rather than acknowledging that many features of common serialisation libraries are a fully loaded uzi pointing at the developer’s foot.
It seems common implementations of serialisation and deserialisation have prioritised ease of use for the developer over declaring clear, bounded intent, and this seems to apply from ad hoc C parsing of network payloads all the way up to automatic serialisation in memory-safe languages.
Perhaps this should have been "the contents of an immutable string can't change" ;)
A typical sms is 140 bytes...
At 40B messages
Thats 57 terabytes a day
But imessage isnt limited to 160 characters
So lets double that.
And about 100 TB a day as of 2014 - so lets triple that.
And assume 300 TB per day in messaging
And lets divide that in two for between iMessage and sms
But since android tops ios in global qty of devices..
Lets double it. And where in the past the Philippines was known to be the top users of sms, but with ayala scaling up over the last years... lets quadruple that number and so i would estimate 600 TB a day in just iMessage and sms alone.
If this was submitted to apples $1M bounty program, would it qualify for the whole amount?
