iMessage: Malformed Message Bricks iPhone
bugs.chromium.org
bugs.chromium.org
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.
https://media.ccc.de/v/27c3-4060-en-attacking_mobile_phones
http://www.ngolde.de/sms/smsodeath_mulliner_golde_cansecwest...
Your "congress" is redundant because CCC=Chaos Communication Congress.
Hayes themselves would even insert the sequence in press releases posted to Usenet. https://groups.google.com/forum/#!topic/comp.dcom.modems/Vr2...
Those must've been some scary code bases.
By the time AOL 3.0 rolled around, it wasn't bluescreening the machine, rather just ending the AOL process and disconnecting.
Just post in the general chat area.
“Hey, to speed up Yahoo Games, press alt-f4.”
I learned that you could evade their swear word filters in your screen name by using ASCII codes.
So I looked up a table. Beep didn’t work, but NULL would boot everyone on your contact list out.
But you could also write the same code into any IRC chat room and anyone running that AV would get booted.
Guess what cell carriers did back then? Yes, they disabled multipart SMS
> 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.
By yesteryear do you mean the present and feature phones do you mean current android phones? Some models are still vulnerable to a text-of-death.
https://poetengineer.postach.io/post/deleting-the-text-of-de... not my blog, but the same problem happened with my mother in law's phone. The phone becomes unusable because of a stream of org.android.phone application has stopped messages and the only thing to do is use adb to delete all texts, until it comes in again. I was never able to pin down the exact problem.
Edit: Sorry, I didn't mean to come off as snarky, but I just wanted to 1) point out that there are still issues with decoding SMS and MMS messages, even in some modern phones and 2) provide a link to anyone who encounter the same issue as it was very frustrating for my MiL and very frustrating until I figured out I could just wipe all SMSes with adb.
They were indeed hardened? Do tell.
I've suggested that the iPhone be hardened against rendering crashes, here on HN. The immediate reaction is to downvote me, then reply, "undefined behavior must crash the process." That's pretty glib and shortsighted, however. It took me just a few seconds to think of a solution.
Have one process write the messages in a log file. This process also supervises the second process. The 2nd process renders the messages. If the 2nd process keeps crashing on the same message, the 1st process marks that message as a problem, and the user can be prompted to send the hex dump of the message for diagnostic purposes. (So if it's spicy, they can say no.)
The fact that such a basic function of the iPhone can be remotely vanished, requiring a reboot, is a pretty glaring hole. What's even worse, is that highly paid SV programmers would shrug their shoulders so easily.
Also if I switch to Android I don’t have to worry about disabling iMessage before. (Not that anybody in my country would ever send an iMessage or an SMS though...)
Not sure what pop-up you're talking about then.
This shows up when you insert a sim that’s not activated with iMessage. Maybe it depends on your region. In my country you really have to pay because the activation process sends an sms message.
All those features in a market where lots of people you'd be chatting with are on Android, I'd suspect.
There was also a bug that allowed a malicious message to crash phones sometime last year where the recommended fix was turning off iMessage (similar to this one).
Some folks probably don't remember to turn it back on after these incidents.
While there are a lot of reasons not to want to use iMessage but only being able to talk to other iOS users isn’t one.
iMessage is a subset of features in the Messages app that are unavailable when communicating with someone on a non-Apple device or if one of the parties has iMessage turned off.
iMessage is not that app unless 100% of the people you message use iPhones.
Ugh, so sick of seeing that
iMessage really could have been something great (despite apple controlling CA) if they had just opened it up for more devices. Instead WhatsApp wiped the floor with them.
and in the process eavesdrop on everybody's messages? no thanks.
Messages are not encrypted to Apples keys they’re only encrypted to recipient device keys - there is no way for Apple to filter any content without removing the end to end encryption of iMessage, which Apple does not want to do - every bit of user content that Apple can decrypt increases the value in compromising Apple’s service infrastructure.
What do you suggest they do?
Architecture-wise some thought should be given to keeping iOS from being DoS'd by the crash/respawn of any service.
Also, looking at the "assuming it's a string" line from the problem description, Apple needs to make an investment look through the codebase for this same error in other guises.
That's what occurs to me off the top of my head anyway.
or...
"Apple can turn off imessage to users with OS < 12.3 until users update"
> For those with jailbroken iPhones, a community member has released the tweak BrickFix: https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...
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.
Sure, you could patch the app to avoid sending what's known as bad data to the next layer but I'd argue that that's the wrong place to do it.
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.
I’m not entirely sure how you’d go about updating the phone without booting into it, but I think it is possible, and that would be one way to avoid losing all your data due to the bug.
For testing purposes, there are three ways that I found to unbrick the device:
1) wipe the device with 'Find my iPhone'
2) put the device in recovery mode and update via iTunes (note that this will force an update to the latest version)
3) remove the SIM card and go out of Wifi range and wipe the device in the menu
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.
Mind, they will still loose data, including some Jailbreak stuff that isn't included in iTunes backups.
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.
If you switch the graph to daily, you see that it passed 51% on June 10th, i.e. in four weeks, and it's at 66% now.
http://gs.statcounter.com/ios-version-market-share/mobile-ta...
But yeah, the big question is how stubborn that long tail is, in the face of news reports about serious bugs or not.
Alternatively, they could publish the gist of the exploit without providing enough detail to actually perform the exploit.
The bad guys (many enough of them) will anyway figure it out right away after the patches have been published, because with every patch, people will (and should) ask "why".
This view of it will assist hackers in getting a head start before the auto update cycle gets to your device and you're notified. And if you're hit but something like this before that, your iPhone will no longer be able to update and apply the fix.
Of course, there's no way to find an objectively "correct" time frame since update cycles vary, but a month or two ought to give plenty of time for the updates to roll out and users to be made aware.
That's why all disclosures come with window - if they don't, the companies aren't under any pressure to update their systems, the exploit start being used in the wild, etc. The window is not ideal, but it is better than no window.
And there isn't much point arguing over 30 vs 90 vs 120 vs 365 days. 90 is reasonable, enough for even the largest mainstream software companies to issue a patch release.
But what’s the point of reducing the window for nice vendors who quickly delivered a patch?
This is totally counter productive. In order to incentivize vendors to deliver patches more and more quickly, good actors should profits from that extra time to secure their user base. In a ideal world that might even permit to reduce the windows in the futur when everyone behave well.
This is just jerking around and sending bad signal unless of course that anticipated disclosure date was decided together with the vendor.
Security is not an ideal world, in fact I would say it is the opposite.
Does anybody know if it was? How does Project Zero make these decisions? Do they consider the install base already patched?
> Unrestricting, as this was fixed in the 12.3 update.
> Unrestricting, as this was fixed in the 12.3 update.
Why did your friend choose to send data over SMS? Why was AT&T upset at his project?
> 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.
Why do you think so?
Or does it happen even if you never use iMessage and have its notifications disabled?
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
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.
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.
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...
> Considering the fact that Microsoft has much bigger market share and therefore security research attention
The OS X bug numbers also include a bunch of bugs for open source projects that are bundled with OS X (Perl, Ruby, Python, SQLite, PHP etc) which increases the security research attention.
As for mobile, does anybody remember hearing of any iOS cross-app malware ("viruses") in the decade since it launched? I think that's pretty amazing.
[0] https://www.google.com/search?q=windows+update+deleted+docum...
They were actively misleading peoplebby running advertisements claiming MACs don't get virueses[2].
[1] https://www.forbes.com/sites/daveywinder/2019/06/21/new-crit...
Moreover Apple only stopped after misleading users for a long time and that also hapenned after high profile incidents as explained in the article.
Has iOS ever had anything where one app could "corrupt" other apps?
Haha, this is called moving the goal post. Fanboys do this all the time :)
Edit: Plenty of buffer overflow and momory corruptions are listed for iOS just in 2019.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
Ignoring the jab, which has no place here, malware is a general term which includes viruses. From the Wikipedia page on computer viruses (https://en.wikipedia.org/wiki/Computer_virus):
> The term "virus" is also misused by extension to refer to other types of malware. "Malware" encompasses computer viruses along with many other forms of malicious software, such as computer "worms", ransomware, spyware, adware, trojan horses, keyloggers, rootkits, bootkits, malicious Browser Helper Object (BHOs), and other malicious software. The majority of active malware threats are actually trojan horse programs or computer worms rather than computer viruses. The term computer virus, coined by Fred Cohen in 1985, is a misnomer.[16] Viruses often perform some type of harmful activity on infected host computers, such as acquisition of hard disk space or central processing unit (CPU) time, accessing private information (e.g., credit card numbers), corrupting data, displaying political or humorous messages on the user's screen, spamming their e-mail contacts, logging their keystrokes, or even rendering the computer useless. However, not all viruses carry a destructive "payload" and attempt to hide themselves—the defining characteristic of viruses is that they are self-replicating computer programs which modify other software without user consent.
> Edit: Plenty of buffer overflow and momory corruptions are listed for iOS just in 2019.
Again, these aren't viruses or even malware.
What's your point here? Hidden malware secretly watching your phone is better than explicit virus? Ignorance is bliss I guess.
> defining characteristic of viruses is that they are self-replicating computer programs which modify other software without user consent.
and Malware doesn't replicate?
Unless your goal is to get people to stop responding to you, don't do this.
> and Malware doesn't replicate?
It does when it's a virus. See the relationship between viruses and malware that I mentioned earlier.
Instead of commenting on this, he just moved the goal post to iOS never getting a Virus. What does iOS never getting a Virus has anything to do with Apple being dishonest?
P.S. Look what just showed up: https://news.ycombinator.com/item?id=20383432
His specific question has an answer, and you chose to obfuscate instead of answering.
You then went on to ignore that contradiction. Does that fall under "moving the goal post" too?
I also suspect you created a new account for the sole purpose of supporting yourself in this argument. [1]
If you want to use the broad, general definition of malware, then Microsoft literally bundles malware with Windows 10 in the form of their "telemetry" and Candy Crush advertisements.
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...
There are some implicit limits to what "bricked" means and those limits vary by individual.
One could argue that every single component on a device could be replaced to bring it back from the dead, but I would argue it isn't the same device at that point.
Bricked is a term that is, and always has been, defined as hardware that is rendered useless by bad software. Replacing hardware components to get a device working is not un-bricking it.
This is entering the realms of philosophy. If you get your screen replaced is it any longer your phone? If someone replaced every part of your phone one piece at a time, at teh pace of one piece a week did they suddenly steal it the moment the last piece was switched out? After all, they have "your" phone - if the concept of "your" phone ever made any sense in the first place.
Rendering useless by bad software - so if you take my linux device and install windows I now have something with objectively worse software than before, and where all my software no longer runs, and which is incapable of reading my ext4 formatting external hard drive. So...you've bricked it?
Obviously not because you can always put Linux back on it. A bricked device, you have no way of doing this. It's useless.
I can't believe all of this discussion simply because people want reuse a word that already means something. It's like the FE devs hijacking "real time". Good grief already.
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.
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.
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.
bplist00Ô X$versionX$objectsY$archiverT$top † ¦U$nullÓ
WNS.keysZNS.objectsV$class¢
€€¢€€€RanVldtext¢ËqÒZ$classnameX$classes\NSDictionary¢XNSObject_NSKeyedArchiverÑ Troot€#-27>DKS^ehjloqsux„‰”ª¶ÈËÐ Ò {
"$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
}Crash loop or hung on startup describes the state. It is by definition not bricked if it can be recovered.
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.
See prescriptivist vs descriptivist.
I had a EdgeMax Lite router which has a propensity for the flash storage to get corrupted at which point it fails to boot. The fix is to buy a particular model of USB flash drive, and image it with a specific .img file. Open the case and replace the flash stick, then boot holding the reset button.
It was a somewhat difficult repair, but in the end just a matter of following step-by-step instructions with readily available tools. I would not consider the device to have been bricked. No more than your computer is bricked when your hard drive dies.
I did brick an Xbox once, trying to solder on an early gen mod chip that was well beyond my soldering abilities!
In this case it’s not even a question of hardware damage. The fix is to reset to factory, upgrade, and restore. This is the happy path recovery process which has done millions of times over on iPhones. I had to do it just a couple weeks ago when my son changed the PIN on an iPhone we use to play music on, and then promptly forgot the new PIN. (He’s 7)
With the proposed meaning, everything is a brick to the technologically illiterate. Better to admit the headline is simply sensationalizing / clickbait.
It’s a fairly frequent pattern where an IoT device becomes a brick because an API shuts down. Similarly, if you can’t replace a crucial part because the manufacturer won’t sell it to you, that would brick a device. If the device is cheaper to replace than to repair, then it is bricked (the Xbox).
A brick must be entirely non-functional and simply not worth repairing. It’s supposed to be a less vulgar version of FUBAR.
There are rare stories of extraordinary lengths that a maker will go to (such as fabbing your own custom parts, or standing up a private version of an API and DNS hijacking requests from the device in order to make it function again) in order to “un-brick” a device. The defining trait of these stories is that something new is invented in order to make the device function again.
In this case we can recover the phone without replacing any hardware at all, so bringing up repair or replacement is a bit of a red herring.
But as I recall, Theseus’ ship was repaired over so many battles, nothing of the original remained. That is distinctly different than botching a single repair so badly you would have been better off replacing from the onset.
There are plenty of ways to get plenty of hardware into an obviously FUBAR state. It’s simply false to say that there is no such thing as a definitively bricked state for any device whatsoever.
Simple rule of thumb; if the commonly accepted solution is “get a new device” then you’ve probably bricked it.
Absolutely no one will have to buy a new iPhone because of this bug.
A bricked phone means it has as much use as a brick, therefore fully unrecoverable regardless of technical skill.
Even to the EE, the cost of parts and time to repair may exceed the cost of replacement, much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value. "Bricked" may still not be the right term, but the difference is irrelevant at that point.
Another consideration is there's a big difference to a user if the fix requires erasing all data, as the work required (after fixing) is then the same as getting a replacement. At the least, this is the effort of applying updates, restoring backups, then dealing with all the fiddly things that didn't update/reinstall/restore properly. At worst, it's irreplaceable data loss (and a hard lesson in why backups are important).
I've never heard of a minor incident referred to as being "totalled", but rather a "write-off", since it's the insurance companies that are ultimately making that decision, not the repair service. Is that a regional thing?
There’s nothing bricked about this. There are no levels of brickedness.
(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...)
The problem here seems to be that the code handling the incoming message is inexplicably running inside springboard rather than a separate process. :-/
In this case. In general, however, Objective-C can often fall victim to attacks where poorly validated attacker data ends up causing RCE: see the entire reason for the existence of NSSecureCoding.
There was a trend since iOS 6 to move backend/non-UI responsibilities away from SpringBoard. But in iOS 11 or 12 or so, more responsibilities started creeping back into SpringBoard. Maybe because of performance or memory consumption concerns, maybe it’s laziness avoiding having to set up a new daemon with appropriate dependencies and sandbox profile when the code can easily be plopped into SpringBoard, it’s not clear. As Natalie says in the report, on macOS this bug only causes DoS on a daemon. Worst case, iMessage stops working and your battery dies quicker. Being totally locked out of the device because SpringBoard is “boot looping” due to an existing fail-safe being excluded from the design seems awful.
On the subject, my Android phone stopped even presenting a keyboard on the lock screen or anywhere else, because the default keyboard is Gboard, and Gboard relies on Play Services, which was crashing inside Gboard. Like this iOS bug, the only known solution is to wipe the device and start over. At least I was still able to get into the device by connecting a USB keyboard. Sucks to know most would have no idea how to diagnose such an issue though, needlessly wiping their photos and all.
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...
(No, downvotes from the complexity-brigade are not going to make me change my mind either.)
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.
What would?
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.
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.
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).
Have you tested every combination of state + error and made sure your app is robust for each situation?
2) Yes, it's not so difficult. Writing tests, for example, also takes time - it's not a reason to don't write tests.
I had to read that several times before I realized you weren't talking about computer device drivers and computer systems.
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.
Especially important on methods called on launch, if a crash would cause a problem.
(Swift or other strongly typed language would help here.)