
iMessage: Malformed Message Bricks iPhone - appwiz
https://bugs.chromium.org/p/project-zero/issues/detail?id=1826
======
rixrax
This brings back old memories from hardening the sms/text parsers of feature
phones of yesteryear.

There it wasn’t entirely uncommon that when you sent a malformed sms-deliver
PDU (e.g. text message) to the phone and crashed parser that tried to decode
it, it took also the phone down before it could ack the message back to SMSC.
Which of course meant that as soon as phone was turned on and it registered to
network, that same message was redelivered (crashing it again) for as far as
the network was concerned, it was never received by the mobile. Until the time
that message either expired in the SMSC in few days, or you switched you sim
to a non-vulnerable mobile to receive the message. Good times.

~~~
pcdoodle
Back in the day AOL parsed HTML for it's instant messages, a <font
size=9999999999999999999999> would blue screen any client running windows. It
was quite easy to empty chat room(s) using this.

~~~
pts_
Hahaha on Yahoo we called it booting.

~~~
marpstar
On AOL we called it "punting", and the apps that facilitated it were the first
reason I ever wanted to code.

~~~
module0000
Strange nostalgic memories of "AOHell" and "LuciferX" come to mind... If I
remember, a lot of them were visual basic apps that would use SendKeys() to
control AOL via keyboard shortcuts. A little like the wild west back then...

~~~
andrew_
Anyone recall the "SubZer0" proggie? (and who else recalls calling apps
"proggies" in our kitchy chat rooms?)

~~~
LinuxBender
I remember Sub-7 and its modules, including those that forced the user to play
(and win) a game of tic-tac-toe, could melt the screen, flip the screen upside
down and misc destructive things.

------
arkadiyt
This is fixed in iOS 12.3 [1] and macOS 10.14.5 [2], both released on May
13th. As Natalie noted on the ticket, turning off iMessage will also prevent
the bug.

[1]: [https://support.apple.com/en-us/HT210118](https://support.apple.com/en-
us/HT210118)

[2]: [https://support.apple.com/en-us/HT210119](https://support.apple.com/en-
us/HT210119)

~~~
IloveHN84
Turning off iMessage to prevent the bug is like turning off a car to prevent
to consume petrol.. what a solution

~~~
martius
Turning off (and stop using) a car sounds like a great solution to prevent
petrol consumption, IMHO.

~~~
0xcafecafe
Not if you have a diesel car.

------
ValentineC
For those with jailbroken iPhones, a community member has released the tweak
BrickFix:
[https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...](https://www.reddit.com/r/jailbreak/comments/c9616j/release_brickfix_fix_for_imessage_bug_that_can/)

~~~
s3arch
[https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...](https://www.reddit.com/r/jailbreak/comments/c9616j/release_brickfix_fix_for_imessage_bug_that_can/esu7afe?utm_source=share&utm_medium=web2x)

------
romaaeterna
Speaking as an ex-Apple employee, I'll just point out that a really malicious
actor could have used this to harm some significant percentage of the
installed iOS infrastructure, and done critical damage to Apple as a company
with it. In fact, I don't know the percentage of users still on <12.3, but
maybe they still could. A band-aid fix for this one bug should not be where
they stop here.

~~~
saagarjha
> A band-aid fix for this one bug should not be where they stop here.

What do you suggest they do?

~~~
swalsh
Would it not be possible to detect malformed messages, and prevent them from
being sent to a phone in the first place?

~~~
saagarjha
No idea; it might be that Apple can't detect these because they're encrypted.

~~~
applecrazy
Yes, they're encrypted in transit.

------
tjmc
What about older 32 bit iOS devices that can't be updated past iOS 10? Will
they issue an update for them or do you just have to turn off iMessage? Still
have a perfectly functional Series 4 iPad

~~~
oarsinsync
Given that jailbreaks exist and can be exploited by malicious actors,
deploying them as the user and applying the jailbreak community supplied fix
may be the best approach:

> For those with jailbroken iPhones, a community member has released the tweak
> BrickFix:
> [https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...](https://www.reddit.com/r/jailbreak/comments/c9616j/release_brickfix_fix_for_imessage_bug_that_can/)

(source:
[https://news.ycombinator.com/item?id=20379779](https://news.ycombinator.com/item?id=20379779))

------
microcolonel
The degree of coupling in iOS has always puzzled me. In 2016 I was developing
a WebGL program and I stumbled upon shaders which would cause iOS to reboot,
on more than one occasion.

~~~
johncolanduoni
That's not really a coupling issue, but a matter of GPU drivers not generally
being hardened against shader/usage bugs. Similar issues have existed on
Windows, Linux, etc. browsers with WebGL support.

~~~
microcolonel
> _That 's not really a coupling issue, but a matter of GPU drivers not
> generally being hardened against shader/usage bugs._

You shouldn't be able to crash the whole operating system (not just the
display server, display driver, etc.) with an ordinary shader, even if it
crashes the shader compiler or causes the GPU not to halt. It's not as though
I wrote these shaders in an attempt to crash iOS.

~~~
0x0
That's not unique to iOS, though. It seems a lot of display drivers on a lot
of platforms were developed without ever considering hostile shaders coming in
over the network, in an era where mostly only game developers would catch
crashes during development? For example
[https://chromium.googlesource.com/chromium/src/gpu/+/master/...](https://chromium.googlesource.com/chromium/src/gpu/+/master/config/software_rendering_list.json)

~~~
microcolonel
Most of the software rendering list in Chromium is about more general bad
behaviour, lack of features, or redundant behaviour (i.e. a GL driver is
available, but it's a software renderer anyway, so might as well use Skia's
software renderer), not security/full system DoS.

For example, the one at _id: 3_ is for renderers with the lowercase word
"software" in their name; _id: 1_ is a GPU which does not have enough features
on its mac driver to run ANGLE for GLES 2.0 (and in turn WebGL 1); _id: 5_ is
for very old versions of mesa, where the libGL would crash (which in practice
means the application would crash, but not the display/windowing servers or
the display driver, nor other applications).

This behaviour on iOS is especially bad, it is not like other systems. The
piece of code which would cause an issue like that is dramatically smaller on
most Linux and Windows graphics stacks.

------
iscrewyou
Wow, you could actually lose the data with this bug. Glad it was fixed in
12.3. I remember the last time something like this happened (4-5 years ago?)
it would only crash the phone.

~~~
floatingatoll
You only lose data if you’re not backing up your phone - it’s not a corruption
bug that breaks the ability to restore backups (like one of the iOS iOS 11
developer betas did).

~~~
peterkelly
That's like saying that with a faulty hard drive you can only lose data if
you're not backing it up.

~~~
floatingatoll
Close, but imprecise. I’m saying two things:

You can lose data with a faulty hard drive if your backup is silently
corrupted and you don’t realize it. That’s not a risk here, as long as before
restoring from backup you upgrade the phone OS to patch the bug.

Also, you can lose data with a faulty hard drive if you have no backup.

Rooters especially will care about these points since they typically cannot
restore from backups without upgrading the phone away from a rooted version,
due to choices made by Apple in firmware.

~~~
Wowfunhappy
Actually, if an iCloud erase works, it should be possible for Jailbreakers to
recover their phones without updating.

Mind, they will still loose data, including some Jailbreak stuff that isn't
included in iTunes backups.

------
zedgerman
Genuinely curious: What’s the reasoning behind “unrestricting” this ahead of
its 90 day window? (It’s tagged Deadline-90, Reported-2019-Apr-18 On Project
Zero, so that’s July 18th?)

~~~
ascorbic
Because it's now fixed. The window is to allow the vendor to issue a fix.

~~~
Twisell
Yeah but maybe it would be nice for users to keep that extra time in order to
maximize the probability that they have actually updated software at
disclosure time.

Disclosing in advance is a bad policy, it will just incentive good behaving
vendors that update fast to delay full description of their changelog for
security reasons because you put their users at unnecessary risks.

~~~
ehsankia
The reasoning is that once a fix is out, by making it public then users can
know about it and intentionally update their devices if they haven't yet.

~~~
davej
Sounds good in theory. In reality, the vast majority of iPhone users are not
aware that this bug exists and never will be. The best action for user safety
is to wait until the period has elapsed or the exploit has been seen in the
wild already.

Alternatively, they could publish the gist of the exploit without providing
enough detail to actually perform the exploit.

~~~
rocqua
Publishing the gist of the exploit, combined with access to diffs of the patch
should be enough for people to reverse engineer the exploit.

~~~
davej
Where are they going to get access to the diffs of the patch? iOS is closed
source.

~~~
inlined
Reading (dis)assembly is a skill many in our profession are required to learn.
It’s common in OS & security fields. Heck, when developing Windows on ARM we
were told Friday that we’d come to work Monday with a mandatory “no source”
debugging session where we had up to an hour to describe a hanged program’s
intended behavior and why it was hanged. One of my colleagues also refused my
symbols when I asked for help debugging a program. He was more comfortable in
ASM than the latest C++

------
ptlu
As an FYI:

> Unrestricting, as this was fixed in the 12.3 update.

------
kitotik
Apparently patched in iOS 12.3, but that’s a pretty gnarly bug.

------
cellular
I see a free data hack: Load a version of iMessage that never acknowledges the
message, but saves the data (and doesn't brick the phone). Send lots of data,
acknowledge via other means (checksum sent over email etc). How much data
could be sent this way? GBs?

~~~
snazz
This doesn't work with iMessage, because the carrier sees iMessage no
differently from any other kind of data download. However, a friend of mine
tried doing something similar using the <number>@txt.att.net (or equivalent
for your carrier) email-to-SMS trick and wrote an Android app that parsed the
messages. They promptly received a firmly worded email from AT&T and were
forced to abandon the project.

~~~
ev0lv
I'd definitely like to know more about the project.

Why did your friend choose to send data over SMS? Why was AT&T upset at his
project?

------
hendersoon
It can be recovered so it's not actually a bricking, but this is very bad. If
you aren't running 12.3 or later this will force you to turn iMessage off.

------
sjg007
I found google sheets in safari will shutdown a Mac with certain special chars
in it.

~~~
smeyer
Which special chars?

~~~
gonational
He tried replying but his Mac crashed.

------
Razengan
Can this be avoided by disabling iMessage notifications?

> _The calling method then calls -[IMBalloonPluginDataSource
> _replaceHandleWithContactNameInString:] which calls im_handleIdentifiers on
> the 'NSString' which is really an NSNumber, which throws an exception as the
> selector does not exist in that class._

Looks like they need to move more of their stuff to Swift to reduce snarfles
like this.

Stories like these (this isn't the first time that iOS/macOS could be crashed
by chat messages), and the empty root password debacle, or all the GateKeeper
bypasses, make me wonder if their engineers take their own WWDC security-
related talks seriously.

Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares
walked the land.

~~~
drieddust
> Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares
> walked the land.

You are speaking like an Apple fanboy. Days of XP are in the past and even
Windows 7/Windows 2008 fairs better than Apple OSX and iOS. This is especially
bad as apple sells a false sense of security when they fail to build even the
basics correctly.

Their walled garden is paved with expensive ibricks.

Edit: Those who think I am speaking rubbish can refer this link.
[https://www.cvedetails.com/top-50-products.php](https://www.cvedetails.com/top-50-products.php)

~~~
kalleboo
> Edit: Those who think I am speaking rubbish can refer this link.
> [https://www.cvedetails.com/top-50-products.php](https://www.cvedetails.com/top-50-products.php)

That listing groups together all OS X bugs back to _2002_ under one heading,
but splits up each Windows version into its own entity. So the numbers aren't
really comparable.

~~~
bildung
But the bottom of that page has a cumulative count by vendor which shows Apple
having the second most security issues, only topped by Microsoft. Considering
the fact that Microsoft has much bigger market share and therefore security
research attention, that's quite an achievement.

~~~
ricardobeat
You mean MS historically has 100% more security issues. Also IE alone competes
with entire OSes in that top 10.

That proves the other comment right, but surely you can spin it other ways.
Anyone who has switched from old windows to Mac doesn’t need numbers to tell
how wild it was.

~~~
bildung
_> You mean MS historically has 100% more security issues._

For an OS used 1000% as often[0], yes.

I have no skin in this game, BTW, as I use neither. But given the number of
security issues Apple has, I really bothers me that they still sell those
products as somehow more secure.

[0] =
[https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...](https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers)

------
tardismechanic
Comment 5 by a...@gmail.com on Thu, Jul 4, 2019, 5:33 PM PDT (3 days ago) I
really hope that no one big covers this, because if they do... oh boy

Comment 6 by p...@gmail.com on Fri, Jul 5, 2019, 3:27 AM PDT (3 days ago) Too
late, already out in big news website...

------
Wowfunhappy
Stupid question: How is the example python program actually sending an
iMessage? Since Apple generally has the system locked down.

~~~
kccqzy
Apple doesn't lock down iMessage sending. A long time ago I've used
AppleScript to automating sending messages (SMS/iMessage) successfully. These
days you can probably use JavaScript as well.

------
ncr100
Could a UI input fuzzer have caught this?

------
JustSomeNobody
Yet another wrong use of the word bricked. Bricked means bricked and you can’t
ever come back from that.

~~~
Someone1234
This definition never holds up to scrutiny.

For example, if I pull out my EPROM writer, de-solder the chips, and update
them almost no device is truly "bricked" by this definition. The only
exceptions would be burned update fuses or similar physical damage. Making the
definition itself extremely niche, to the point of being synonymous with
"physically damaged/destroyed."

I myself stick to the broader "technologically as useful as a brick"
definition. Which a boot-looping iPhone absolutely fits. The fact there are
ways to recover it is neither here nor there.

I generally call what you're describing a "Hard Brick." But even those are
sometimes recoverable via as I said chip re-programming.

~~~
JustSomeNobody
I stand by words mean things. If you can recover in any way, it's not a brick.
In this case it is a boot loop and there's no reason they should not have used
boot loop to describe the condition.

~~~
SkyBelow
>If you can recover in any way

Physically replacing every single component, one by one, will lead to a
recovery.

>I stand by words mean things.

They are an abstraction of thought to enable communication and external
storage. A very leaky abstraction.

~~~
Zenbit_UX
A bricked device can be recovered - usually - by replacing hardware, that's
the limit of the definition. The GP comment is right, bricked is bricked and
there's no way to recover a bricked device with any software means. It means
the hardware is fucked and it's usefulness is equivalent to a brick.

~~~
lagadu
What if you can reprogram an eeprom to make it work, would you consider it
bricked? You're not replacing any hardware and are fixing only software.

At the end of the day language is (for all pragmatic purposes) finite but
possible states of the universe are not, so you can't have a perfect
definition of that catches all possible states you want while excluding all
others with perfect accuracy.

------
HeWhoLurksLate

       bplist00ÔX$versionX$objectsY$archiverT$top † ¦U$nullÓ 
      WNS.keysZNS.objectsV$class¢
       €€¢€€€RanVldtext¢ËqÒZ$classnameX$classes\NSDictionary¢XNSObject_NSKeyedArchiverÑTroot€#-27>DKS^ehjloqsux„‰”ª­¶ÈËÐ                             Ò

~~~
IloveHN84
?

~~~
saagarjha
It's the serialized object used in the PoC, in binary property list format.
Here's what it looks like pretty-printed:

    
    
      {
        "$archiver" => "NSKeyedArchiver"
        "$objects" => [
          0 => "$null"
          1 => {
            "$class" => <CFKeyedArchiverUID 0x7fd45ec02d50 [0x7fff97761b10]>{value = 5}
            "NS.keys" => [
              0 => <CFKeyedArchiverUID 0x7fd45ec02c20 [0x7fff97761b10]>{value = 2}
              1 => <CFKeyedArchiverUID 0x7fd45ec02c40 [0x7fff97761b10]>{value = 3}
            ]
            "NS.objects" => [
              0 => <CFKeyedArchiverUID 0x7fd45ec02cf0 [0x7fff97761b10]>{value = 4}
              1 => <CFKeyedArchiverUID 0x7fd45ec02cf0 [0x7fff97761b10]>{value = 4}
            ]
          }
          2 => "an"
          3 => "ldtext"
          4 => 77777777
          5 => {
            "$classes" => [
              0 => "NSDictionary"
              1 => "NSObject"
            ]
            "$classname" => "NSDictionary"
          }
        ]
        "$top" => {
          "root" => <CFKeyedArchiverUID 0x7fd45ec02ff0 [0x7fff97761b10]>{value = 1}
        }
        "$version" => 100000
      }

------
wingerlang
Since a restore works it cannot be called a brick though?

~~~
taneq
It's a sliding scale which depends on the user's competence and not just the
hardware. To a completely non-technical person, a hard lock-up is "bricked"
even if it could be fixed by pressing buttons. To a normal user, a borked ROM
is "bricked" even if it could be fixed by plugging into a computer and re-
flashing. To a power user, a busted bootloader is "bricked" if it stops them
flashing a ROM, even if it could be fixed with a JTAG debugger. To a
sufficiently good EE, it's not bricked until the whole thing is physically
destroyed.

~~~
zaroth
The only purpose of the word’s existence is to define an entirely
unrecoverable state.

Crash loop or hung on startup describes the state. It is by definition not
_bricked_ if it can be recovered.

~~~
slyrus
It's almost like the author of the above comment (zaroth) didn't read the
parent comment. Put another way, bricking is in the eye of the beholder.

~~~
michaelmrose
Technical terms have meaning defined by actual technical usage regardless of
common misuse by the less informed.

Your entire tower isn't a cpu, a user recoverable device isn't bricked and if
tomorrow most people start calling kidneys livers they will still be kidneys.

Reducing bricked to a subjective statement about the users ability to use
their device robs the term of all utility in the same way as calling a
computer a cpu.

The author didn't fail to read your words, you are in fact wrong and repeating
yourself doesn't make you more correct.

~~~
dang
Please edit acerbic swipes out of your comments here.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
michaelmrose
I don't think I CAN edit it at this point but I will revisit the guidelines.
Do you feel that just the sentence that was problematic then?

~~~
dang
Yes, I was responding to the one sentence.

~~~
michaelmrose
Thanks

------
rubrick85
Another one :D

------
userbinator
Looks like the "curse of complexity" strikes again... every time I see bugs
like this, I wonder if it's because of some code that tries to be a little
"too smart" in trying to parse what could be arbitrary data, and forgetting
some edge-case.

(If you have JS disabled, you can click "View in Old UI" and then view source
to see the content. I find that a bit ironic in the context of this specfic
bug...)

~~~
viraptor
Is this an issue of complexity or lack of isolation? More isolation means more
complexity, but at the same time, this issue should crash the iMessage app
itself, not the whole system. The fact that springboard even knows about
iMessage structure is crazy...

~~~
userbinator
Complexity.

You don't really need isolation if the code is so simple as to obviously
contain no bugs (instead of containing no obvious bugs.)

Instead, we have a whole industry built upon encouraging the creation of
things as complex as possible, and working around the problems caused by that
by adding even more complexity, mainly because it means people have more to
do.

[http://countercomplex.blogspot.com/2014/08/the-resource-
leak...](http://countercomplex.blogspot.com/2014/08/the-resource-leak-bug-of-
our.html)

(No, downvotes from the complexity-brigade are not going to make me change my
mind either.)

~~~
viraptor
I think you could achieve low complexity at the time of early feature phones.
If you get a web browser and loadable untrusted binaries in the system, you've
lost this battle. There is no way to make those "obviously contain no bugs".

So you're kind of right, we wouldn't need isolation... if not for the fact
modern mobiles exist.

But even then - people are creative. Software may be obviously bug free,
hardware may be obviously bug free... then someone comes up with rowhammer and
you're owned by pure physics. I'm not sure "obviously bug free" even exists.

------
mholt
With ALL their infinite resources, how are Apple's bugs SO BAD.

Like, repeatedly.

goto fail, Facetime surveillance, empty password grants root access, and now
this.

As much as Apple touts privacy and security, this is not a great track record.

The more resources a company has, the less forgivable serious bugs like this
are.

I need to keep reminding myself: Apple is a hardware company, not a software
company.

~~~
dmitriid
> With ALL their infinite resources, how are Apple's bugs SO BAD.

Infinite resources do not easily translate to quality for many many reasons.

The main being: we’re just human, and we suck at managing large projects at
scale.

------
EugeneOZ
Lazy developers throw exceptions, good developers return errors. Exceptions
should be exceptional.

I'll use URL to this bug in my next comment-holywars to prove this point.

Yes, it takes much less code to throw an exception in hope some code will
catch it, but while compiler (not runtime) doesn't check it - this technique
is not safe. So we should return errors, check them and handle - sometimes it
means returning error further, but in some function we'll write code to handle
this case without crashing the system (or, at least, it will shutdown
everything gently, without panicking).

~~~
plorkyeran
You want to write explicit error handling for every possible case of runtime
type errors in a dynamically typed language?

The "unrecognized selector sent to instance" exception is not thrown in the
hope that someone will catch it. It's intended to be a fatal error reporting a
precondition violation.

~~~
aaronbrager
That’s what secure coding guidelines say to do. It’s called “input
validation”. For example here’s Apple’s:
[https://developer.apple.com/library/archive/documentation/Se...](https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/ValidatingInput.html)

Especially important on methods called on launch, if a crash would cause a
problem.

(Swift or other strongly typed language would help here.)

~~~
lagadu
The halting problem's existence means that there's no input validation that is
guaranteed to work absolutely 100% of the time though, for sufficiently large
inputs.

