The Many Possibilities of iMessage File Vulnerability

To me the key question is: Why is iMessage not a normal iOS app?<p>We&#x27;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&#x2F;requiring a factory reset), crashes that reboot the phone (once), and a bunch of potential for escalation&#x2F;code execution.<p>None of this is possible with apps in the normal iOS sandbox. The apps themselves would crash, but they&#x27;re context confined, they cannot bring down the underlying OS, write invalid notifications, or cause a kernel panic.<p>But they&#x27;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&#x27;s inner workings into the app&#x27;s context, or even another user space&#x2F;context confined service, and just let them crash like normal apps do.<p>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&#x27;ve seen many migrate fonts into userland. Why is iMessage&#x27;s security model so far behind the times, it is a lot less critical&#x2F;performance impacted than fonts, but yet has worse security than most font systems in 2019?

I’m glad we’re seeing so many security vulnerabilities being exposed in the lower-level parts of the consumer OSes whose security we all take for granted. Doing writeups of compromised webapps is also great of course, but selling the importance of security to laypeople is easier as “the root of trust of your digital life was compromised in a certain way” than “a webapp for that service that only 2% of your country uses was compromised, so be sure to reset your passwords if you’re one of the unlucky ones”.<p>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.<p>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.<p>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 core problem is deserialization formats where the serialized content specifies that class that should be instantiated. See the yaml, pickle, Java, etc serialization bugs over the years.<p>The real kicker here is that someone was clearly <i>trying</i> 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&#x27;t necessarily actually support secure coding you get much sadness.<p>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.

Pretty wild!<p>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&#x27;s really about receiving multimedia and decoding it in a performant way.<p>When will people discover all the vulnerabilities in video codecs, fonts and shaders?

&quot;The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better. &quot;<p><a href="https:&#x2F;&#x2F;www.openbsd.org&#x2F;security.html" rel="nofollow">https:&#x2F;&#x2F;www.openbsd.org&#x2F;security.html</a>

&gt; For a non-mutable string, it sometimes just increases the retain count on the string, but that also shouldn’t be a problem, because the contents of a mutable string can’t change.<p>Perhaps this should have been &quot;the contents of an <i>im</i>mutable string can&#x27;t change&quot; ;)

Non-mobile link: <a href="https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2019&#x2F;08&#x2F;the-many-possibilities-of-cve-2019-8646.html" rel="nofollow">https:&#x2F;&#x2F;googleprojectzero.blogspot.com&#x2F;2019&#x2F;08&#x2F;the-many-poss...</a>

Is there any guestimation on nust the sheer volume of data sent each day wit iMessage (blue messages, not green sms ones)

Possibly dumb question:<p>If this was submitted to apples $1M bounty program, would it qualify for the whole amount?