
The Many Possibilities of iMessage File Vulnerability - jakejarvis
https://googleprojectzero.blogspot.com/2019/08/the-many-possibilities-of-cve-2019-8646.html?m=1
======
Someone1234
To me the key question is: Why is iMessage not a normal iOS app?

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?

~~~
csande17
I suspect it's because historically, iOS didn't have a way to embed views from
one app into another app. When Apple wanted to let you view iMessages from the
lock screen, or expose iMessage via Share buttons in third-party apps, they
accomplished that by shoving most of iMessage into the operating system
itself.

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.

~~~
devin
>small indie company that does not have the resources.

Can we be friends? This is incredible.

~~~
ludamad
"small indie company" is a frequent meme by disgruntled gamers

~~~
zapzupnz
Especially fans of Pokémon who aren't fans of Game Freak, lately.

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

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.

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

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.

~~~
vesinisa
What's so wrong with MessagePack, BSON etc.? Apart from de-serializing
arbitrary classes from untrusted inputs being obviously insane, it's almost
always an overkill as well. Why not simply stick to a binary format that
doesn't even have a way of expressing data outside of a few well-defined
primitive types?

~~~
olliej
iMessage has a _large_ base of existing users that need to be able to continue
to use messages, and presumably it was thought that by restricting with the
NSSecureCoding API it would be safe, but as you say any API where the remote
specifies the class to instantiate is going to be something of a footgun.

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.

------
doctorpangloss
Pretty wild!

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?

~~~
java-man
I am afraid never - security is never a design goal, even when security is the
main purpose of the software (OpenSSL/ heartbleed).

~~~
miloignis
That's why I think formally verified implementations are so critical, and why
Project Everest (formally verified TLS) is so cool: [https://project-
everest.github.io/](https://project-everest.github.io/)

~~~
johnisgood
Also:
[https://github.com/Componolit/libsparkcrypto](https://github.com/Componolit/libsparkcrypto)

~~~
java-man
Not an ADA guy, just curious:

1\. does this library provide a way to clear secrets from memory?

2\. does it provide means to ensure that the secrets will not be swapped to
disk on page fault or copied in memory?

3\. does it bignum implementation provide a way to clear the internal buffer?

thank you.

~~~
johnisgood
Hey! I only found
[https://github.com/Componolit/libsparkcrypto/blob/0a3a3c5ed7...](https://github.com/Componolit/libsparkcrypto/blob/0a3a3c5ed74f483e5d8539e2d84bf988547bf5b4/src/shared/generic/lsc-
internal-pad64.adb). I hope someone who is more acquainted will help us out.

In any case, you should read:

\-
[https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/ae...](https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/ae2017_chapman.pdf)

\-
[https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/Ha...](https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/Hardware-
based-data-protection-in-Ada.pdf)

\- [https://dwheeler.com/secure-programs/Secure-Programs-
HOWTO/p...](https://dwheeler.com/secure-programs/Secure-Programs-
HOWTO/protect-secrets.html)

\-
[https://dwheeler.com/lovelace/s17s5.htm](https://dwheeler.com/lovelace/s17s5.htm)

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

[https://www.openbsd.org/security.html](https://www.openbsd.org/security.html)

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

Perhaps this should have been "the contents of an _im_ mutable string can't
change" ;)

------
Sniffnoy
Non-mobile link: [https://googleprojectzero.blogspot.com/2019/08/the-many-
poss...](https://googleprojectzero.blogspot.com/2019/08/the-many-
possibilities-of-cve-2019-8646.html)

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

~~~
saagarjha
This number way about 40 billion in 2014:
[https://www.macrumors.com/2014/02/28/apple-40-billion-
imessa...](https://www.macrumors.com/2014/02/28/apple-40-billion-imessages/)

~~~
samstave
If my calculations are correct;

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.

~~~
airstrike
I love this. Reminded me of one time some 15+ years ago I did some back-of-
the-envelope math like yours but on people using colored characters on every
message on IRC w/ scripts and how much meaningless data that generated... it's
astonishing how quickly you can get to the PB scale

~~~
samstave
Ok so there are 8 trillion messges ent per N

Im building a formula for that cost... gimme a sec

~~~
samstave
I need help with some math... any stats/bi/experts out there willing to
converse on this?

------
panpanna
Possibly dumb question:

If this was submitted to apples $1M bounty program, would it qualify for the
whole amount?

~~~
saagarjha
I can’t see this getting more than $500,000.

