19 ms·

iMessage: Malformed Message Bricks iPhone

652 points by appwiz 7y ago

Waterluvian 7y ago
I cannot load this page on android Firefox without it immediately crashing Firefox. Fairly topical.
- ptlu 7y ago
  Works in my FF 67.
  - vinay427 7y ago
    Same, it works for me on 67.0.3.
  - burk96 7y ago
    Repeating repeatable results, works on 68 beta and 67.0.3 here
  - Faark 7y ago
    Works on my FF 69 as well, but the text select behavior is weird at best. The page did NOT work on my Edge 44, even after disabling uBlock.
- singron 7y ago
  I didn't get a crash with 67.0.3 from f-droid, just to add a data point.
- kitotik 7y ago
  Safari on iOS threw a WebKit exception on my first try, but a reload worked…
  - saagarjha 7y ago
    Works fine for me, which version of Safari are you using?
ptlu 7y ago
As an FYI: > Unrestricting, as this was fixed in the 12.3 update.
kitotik 7y ago
Apparently patched in iOS 12.3, but that’s a pretty gnarly bug.
arkadiyt 7y ago
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
- shurcooL 7y ago
  Do you know why is the upstream bug in "New (Open)" state, if it's fixed in currently released versions of iOS/macOS?
  - toyg 7y ago
    Maybe it still has to be fixed in the betas?
- IloveHN84 7y ago
  Turning off iMessage to prevent the bug is like turning off a car to prevent to consume petrol.. what a solution
  - kabwj 7y ago
    Where I live nobody uses iMessage so this sounds like a good workaround :P (Yes yes I know it’s been patched already...)
    - samoa42 7y ago
      second that. half of my friends using iphones dont enable imessage. thus penetration (in my circles) is way too low to make it useful.
      - jeromegv 7y ago
        Considering it's enabled by default, i'm really curious why you would want to do that.
iscrewyou 7y ago
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.
- nneonneo 7y ago
  The problem isn’t that the bug itself will cause data loss - it’s that you have no way of using the phone because of the boot loop unless you wipe. 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.
  - GhostVII 7y ago
    One of the comments on the bug has the answer: 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
    - Matt3o12_ 7y ago
      Instead of wiping the phone, couldn’t you just disable iMessage once you habe removed the SIM card and are out of WiFi range?
      - monkeynotes 7y ago
        Would that mean you could not use iMessage any more (without the patch)? An iPhone without iMessage is significantly redundant, at least in N.America.
- floatingatoll 7y ago
  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).
wingerlang 7y ago
Since a restore works it cannot be called a brick though?
- tambourine_man 7y ago
  Damn right it can’t. This lack of distinction annoys me to no end.
- taneq 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.
userbinator 7y ago
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 7y ago
  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...
  - olliej 7y ago
    right? ignoring the issue of invalid assumptions in iMessage taking content from the network (though at least it's objective-c so it's a "DoS" rather than RCE). The problem here seems to be that the code handling the incoming message is inexplicably running inside springboard rather than a separate process. :-/
    - saagarjha 7y ago
      > invalid assumptions in iMessage taking content from the network (though at least it's objective-c so it's a "DoS" rather than RCE) 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.
    - kirb 7y ago
      I’ve somewhat researched iMessage handling on iOS for a jailbreak tweak called TypeStatus, and I find this bug odd. In iOS 7, SpringBoard was restricted at the sandbox (kernel) level from any access to the Messages database. I had to adapt my code to instead run inside imagent, which is responsible for keeping a push socket open with iMessage among other Messages housekeeping things (this also exists on macOS). 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.
ValentineC 7y ago
For those with jailbroken iPhones, a community member has released the tweak BrickFix: https://www.reddit.com/r/jailbreak/comments/c9616j/release_brickfix_fix_for_imessage_bug_that_can/ https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...
- s3arch 7y ago
  https://www.reddit.com/r/jailbreak/comments/c9616j/release_brickfix_fix_for_imessage_bug_that_can/esu7afe?utm_source=share&utm_medium=web2x https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...
zedgerman 7y ago
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 7y ago
  Because it's now fixed. The window is to allow the vendor to issue a fix.
  - Twisell 7y ago
    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.
    - the-rc 7y ago
      The fix has been available for almost two months. Don't iOS updates hit the 50% adoption mark within two weeks?
      - davej 7y ago
        I’m not sure of the stats honestly but there’s still going to be a huge long tail of people on earlier versions for months afterwards. I was surprised that I was still on iOS 12.2.
      - acdha 7y ago
        http://gs.statcounter.com/ios-version-market-share/mobile-tablet/worldwide http://gs.statcounter.com/ios-version-market-share/mobile-ta... shows 12.3 at around 50%, so the question for me would be what percentage of that long tail would upgrade within any reasonable extension period. Public news might actually accelerate that since it gives people a reason not to procrastinate hitting that button.
rixrax 7y ago
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.
- askl 7y ago
  There was a nice talk about this a few years ago at the CCC congress. https://media.ccc.de/v/27c3-4060-en-attacking_mobile_phones https://media.ccc.de/v/27c3-4060-en-attacking_mobile_phones http://www.ngolde.de/sms/smsodeath_mulliner_golde_cansecwest2011.pdf http://www.ngolde.de/sms/smsodeath_mulliner_golde_cansecwest...
  - tambre 7y ago
    > [...] at the CCC congress Your "congress" is redundant because CCC=Chaos Communication Congress.
    - nathancahill 7y ago
      ATM machine
    - Natanael_L 7y ago
      CCC = chaos computer club. They might also use it for other meanings, but referring to the actual original name makes absolute sense.
- pcdoodle 7y ago
  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.
EugeneOZ 7y ago
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).
- saagarjha 7y ago
  Lazy developers also ignore errors by swallowing them. In this particular case, note that the error was detected many methods away because of Objective-C's weak typing, not because the developers "chose" to throw an exception.
- ec109685 7y ago
  Crashing a program is often safer for unexpected conditions than hoping your error handling will recover from it? Have you tested every combination of state + error and made sure your app is robust for each situation?
  - EugeneOZ 7y ago
    1) Quite the contrary. And there is no "hope" - you either write code to recover or you throw an exception (and then there is a "hope" that some other code will catch it), it's just different approaches. 2) Yes, it's not so difficult. Writing tests, for example, also takes time - it's not a reason to don't write tests.
- kennywinker 7y ago
  This error is due to use of a un type checked language (objc). You can blame the coding style all you want but it’s like blaming bad drivers for accidents instead of fixing the system.
  - 7y ago
mholt 7y ago
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 7y ago
  > 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.
Razengan 7y ago
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.
- saagarjha 7y ago
  > Can this be avoided by disabling iMessage notifications? Why do you think so?
  - saurik 7y ago
    From the code right after that quote, I would be confused if a the view fronting that IMBalloonPluginDataSource was rendered in SpringBoard if you had turned off notifications.
  - Razengan 7y ago
    I'm assuming it crashes when it first tries to display a preview for the message? Or does it happen even if you never use iMessage and have its notifications disabled?
- drieddust 7y ago
  > 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
rubrick85 7y ago
Another one :D
tjmc 7y ago
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 7y ago
  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_brickfix_fix_for_imessage_bug_that_can/ https://www.reddit.com/r/jailbreak/comments/c9616j/release_b... (source: https://news.ycombinator.com/item?id=20379779 https://news.ycombinator.com/item?id=20379779)
- lw 7y ago
  Can anyone confirm that older iOS devices are affected as well or was this introduced at a later point?
- dtech 7y ago
  Don't remote root exploits (jailbreaks) exists for those devices? Then it's basically game over if anyone want anything already.
microcolonel 7y ago
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 7y ago
  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 7y ago
    > 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.
    - lagadu 7y ago
      But that's unrelated to how tightly coupled the app is with the OS, but rather how ungracefully the driver fails. No matter how "far away" the app is from the gpu, at some point in the pipeline whatever data is being received will have to interact with it in some way, via the driver. 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.
    - 0x0 7y ago
      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/config/software_rendering_list.json https://chromium.googlesource.com/chromium/src/gpu/+/master/...
JustSomeNobody 7y ago
Yet another wrong use of the word bricked. Bricked means bricked and you can’t ever come back from that.
- iamnotacrook 7y ago
  No, it's not as simple as that. People use brick to mean slightly different things - sometimes they say hard/soft bricked instead of bricked. And you'll even find some people who say what you say but admit that it was still the correct word to describe devices which can only be fixed by disassembling the hardware and using jtag, which "brick extremists" probably wouldn't allow.
  - JustSomeNobody 7y ago
    This was a boot loop condition. The person reporting it clearly knows this and yet confused the issue by saying "bricked." Bricked is non-recoverable.
    - lagadu 7y ago
      Can you provide your definition of non-recoverable? An extreme example: someone could tear down the phone down to every single last nanometer-scale transistor and polymer, fix the problem and reassemble it; that would make it recoverable from even most scenarios of destruction, hell, with enough energy available one could in theory fuse/fusion it down into iron and reconstruct the very elements themselves in order to eventually produce a working phone again. There are some implicit limits to what "bricked" means and those limits vary by individual.
      - JustSomeNobody 7y ago
        I'm curious, what component could you replace in this instance to recover the iPhone and not lose data? 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.
sjg007 7y ago
I found google sheets in safari will shutdown a Mac with certain special chars in it.
- smeyer 7y ago
  Which special chars?
  - gonational 7y ago
    He tried replying but his Mac crashed.
  - nvr219 7y ago
    Cmd + q
romaaeterna 7y ago
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.
- EADGBE 7y ago
  They're (Apple) rather lucky that their user base vehemently upgrades whenever possible.
  - snaveed 7y ago
    I've iPhone user I've ever met outside tech circles avoids installing OS updates. They end up updating soon anyway for a variety of reasons (some updated apps stop working, update occurs "on its own" overnight, to get rid of of the notification icon, and so on).
    - machinecoffee 7y ago
      It does help that the process is pretty painless. And at least for me, a good excuse to do a reboot - which I really do as seldom as possible on my laptop and iphone.
- applecrazy 7y ago
  What they should also do is block the malformed message from being sent too. Not sure how to do that, since iMessages are encrypted in transit, but I'm sure there's some way.
  - arwineap 7y ago
    Apple controls the CA; it's pretty straight forward for them to check contents. 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.
cellular 7y ago
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?
- 420codebro 7y ago
  It doesn’t work that way. The person with a cell bill will still be charged the downloaded data.
- snazz 7y ago
  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 7y ago
    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?
HeWhoLurksLate 7y ago
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 7y ago
  ?
  - saagarjha 7y ago
    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 }
Wowfunhappy 7y ago
Stupid question: How is the example python program actually sending an iMessage? Since Apple generally has the system locked down.
- rhinoceraptor 7y ago
  It looks like it uses some AppleScript and Frida [1] to inject code into Messages.app on the Mac. 1: https://www.frida.re/ https://www.frida.re/
- kccqzy 7y ago
  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.
hendersoon 7y ago
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.
ncr100 7y ago
Could a UI input fuzzer have caught this?
tardismechanic 7y ago
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...

652 points by appwiz 7y ago

Waterluvian 7y ago

I cannot load this page on android Firefox without it immediately crashing Firefox. Fairly topical.

ptlu 7y ago
Works in my FF 67.
- vinay427 7y ago
  Same, it works for me on 67.0.3.
- burk96 7y ago
  Repeating repeatable results, works on 68 beta and 67.0.3 here
- Faark 7y ago
  Works on my FF 69 as well, but the text select behavior is weird at best. The page did NOT work on my Edge 44, even after disabling uBlock.
singron 7y ago
I didn't get a crash with 67.0.3 from f-droid, just to add a data point.
kitotik 7y ago
Safari on iOS threw a WebKit exception on my first try, but a reload worked…
- saagarjha 7y ago
  Works fine for me, which version of Safari are you using?

ptlu 7y ago

As an FYI: > Unrestricting, as this was fixed in the 12.3 update.

kitotik 7y ago

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

arkadiyt 7y ago

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

shurcooL 7y ago
Do you know why is the upstream bug in "New (Open)" state, if it's fixed in currently released versions of iOS/macOS?
- toyg 7y ago
  Maybe it still has to be fixed in the betas?
IloveHN84 7y ago
Turning off iMessage to prevent the bug is like turning off a car to prevent to consume petrol.. what a solution
- kabwj 7y ago
  Where I live nobody uses iMessage so this sounds like a good workaround :P (Yes yes I know it’s been patched already...)
  - samoa42 7y ago
    second that. half of my friends using iphones dont enable imessage. thus penetration (in my circles) is way too low to make it useful.
    - jeromegv 7y ago
      Considering it's enabled by default, i'm really curious why you would want to do that.

iscrewyou 7y ago

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.

nneonneo 7y ago
The problem isn’t that the bug itself will cause data loss - it’s that you have no way of using the phone because of the boot loop unless you wipe. 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.
- GhostVII 7y ago
  One of the comments on the bug has the answer: 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
  - Matt3o12_ 7y ago
    Instead of wiping the phone, couldn’t you just disable iMessage once you habe removed the SIM card and are out of WiFi range?
    - monkeynotes 7y ago
      Would that mean you could not use iMessage any more (without the patch)? An iPhone without iMessage is significantly redundant, at least in N.America.
floatingatoll 7y ago
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).

wingerlang 7y ago

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

tambourine_man 7y ago
Damn right it can’t. This lack of distinction annoys me to no end.
taneq 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.

userbinator 7y ago

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 7y ago
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...
- olliej 7y ago
  right? ignoring the issue of invalid assumptions in iMessage taking content from the network (though at least it's objective-c so it's a "DoS" rather than RCE). The problem here seems to be that the code handling the incoming message is inexplicably running inside springboard rather than a separate process. :-/
  - saagarjha 7y ago
    > invalid assumptions in iMessage taking content from the network (though at least it's objective-c so it's a "DoS" rather than RCE) 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.
  - kirb 7y ago
    I’ve somewhat researched iMessage handling on iOS for a jailbreak tweak called TypeStatus, and I find this bug odd. In iOS 7, SpringBoard was restricted at the sandbox (kernel) level from any access to the Messages database. I had to adapt my code to instead run inside imagent, which is responsible for keeping a push socket open with iMessage among other Messages housekeeping things (this also exists on macOS). 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.

ValentineC 7y ago

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

s3arch 7y ago
https://www.reddit.com/r/jailbreak/comments/c9616j/release_brickfix_fix_for_imessage_bug_that_can/esu7afe?utm_source=share&utm_medium=web2x https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...

zedgerman 7y ago

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 7y ago
Because it's now fixed. The window is to allow the vendor to issue a fix.
- Twisell 7y ago
  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.
  - the-rc 7y ago
    The fix has been available for almost two months. Don't iOS updates hit the 50% adoption mark within two weeks?
    - davej 7y ago
      I’m not sure of the stats honestly but there’s still going to be a huge long tail of people on earlier versions for months afterwards. I was surprised that I was still on iOS 12.2.
    - acdha 7y ago
      http://gs.statcounter.com/ios-version-market-share/mobile-tablet/worldwide http://gs.statcounter.com/ios-version-market-share/mobile-ta... shows 12.3 at around 50%, so the question for me would be what percentage of that long tail would upgrade within any reasonable extension period. Public news might actually accelerate that since it gives people a reason not to procrastinate hitting that button.

rixrax 7y ago

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.

askl 7y ago
There was a nice talk about this a few years ago at the CCC congress. https://media.ccc.de/v/27c3-4060-en-attacking_mobile_phones https://media.ccc.de/v/27c3-4060-en-attacking_mobile_phones http://www.ngolde.de/sms/smsodeath_mulliner_golde_cansecwest2011.pdf http://www.ngolde.de/sms/smsodeath_mulliner_golde_cansecwest...
- tambre 7y ago
  > [...] at the CCC congress Your "congress" is redundant because CCC=Chaos Communication Congress.
  - nathancahill 7y ago
    ATM machine
  - Natanael_L 7y ago
    CCC = chaos computer club. They might also use it for other meanings, but referring to the actual original name makes absolute sense.
pcdoodle 7y ago
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.

EugeneOZ 7y ago

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

saagarjha 7y ago
Lazy developers also ignore errors by swallowing them. In this particular case, note that the error was detected many methods away because of Objective-C's weak typing, not because the developers "chose" to throw an exception.
ec109685 7y ago
Crashing a program is often safer for unexpected conditions than hoping your error handling will recover from it? Have you tested every combination of state + error and made sure your app is robust for each situation?
- EugeneOZ 7y ago
  1) Quite the contrary. And there is no "hope" - you either write code to recover or you throw an exception (and then there is a "hope" that some other code will catch it), it's just different approaches. 2) Yes, it's not so difficult. Writing tests, for example, also takes time - it's not a reason to don't write tests.
kennywinker 7y ago
This error is due to use of a un type checked language (objc). You can blame the coding style all you want but it’s like blaming bad drivers for accidents instead of fixing the system.
- 7y ago

mholt 7y ago

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 7y ago
> 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.

Razengan 7y ago

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.

saagarjha 7y ago
> Can this be avoided by disabling iMessage notifications? Why do you think so?
- saurik 7y ago
  From the code right after that quote, I would be confused if a the view fronting that IMBalloonPluginDataSource was rendered in SpringBoard if you had turned off notifications.
- Razengan 7y ago
  I'm assuming it crashes when it first tries to display a preview for the message? Or does it happen even if you never use iMessage and have its notifications disabled?
drieddust 7y ago
> 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

rubrick85 7y ago

Another one :D

tjmc 7y ago

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 7y ago
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_brickfix_fix_for_imessage_bug_that_can/ https://www.reddit.com/r/jailbreak/comments/c9616j/release_b... (source: https://news.ycombinator.com/item?id=20379779 https://news.ycombinator.com/item?id=20379779)
lw 7y ago
Can anyone confirm that older iOS devices are affected as well or was this introduced at a later point?
dtech 7y ago
Don't remote root exploits (jailbreaks) exists for those devices? Then it's basically game over if anyone want anything already.

microcolonel 7y ago

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 7y ago
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 7y ago
  > 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.
  - lagadu 7y ago
    But that's unrelated to how tightly coupled the app is with the OS, but rather how ungracefully the driver fails. No matter how "far away" the app is from the gpu, at some point in the pipeline whatever data is being received will have to interact with it in some way, via the driver. 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.
  - 0x0 7y ago
    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/config/software_rendering_list.json https://chromium.googlesource.com/chromium/src/gpu/+/master/...

JustSomeNobody 7y ago

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

iamnotacrook 7y ago
No, it's not as simple as that. People use brick to mean slightly different things - sometimes they say hard/soft bricked instead of bricked. And you'll even find some people who say what you say but admit that it was still the correct word to describe devices which can only be fixed by disassembling the hardware and using jtag, which "brick extremists" probably wouldn't allow.
- JustSomeNobody 7y ago
  This was a boot loop condition. The person reporting it clearly knows this and yet confused the issue by saying "bricked." Bricked is non-recoverable.
  - lagadu 7y ago
    Can you provide your definition of non-recoverable? An extreme example: someone could tear down the phone down to every single last nanometer-scale transistor and polymer, fix the problem and reassemble it; that would make it recoverable from even most scenarios of destruction, hell, with enough energy available one could in theory fuse/fusion it down into iron and reconstruct the very elements themselves in order to eventually produce a working phone again. There are some implicit limits to what "bricked" means and those limits vary by individual.
    - JustSomeNobody 7y ago
      I'm curious, what component could you replace in this instance to recover the iPhone and not lose data? 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.

sjg007 7y ago

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

smeyer 7y ago
Which special chars?
- gonational 7y ago
  He tried replying but his Mac crashed.
- nvr219 7y ago
  Cmd + q

romaaeterna 7y ago

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.

EADGBE 7y ago
They're (Apple) rather lucky that their user base vehemently upgrades whenever possible.
- snaveed 7y ago
  I've iPhone user I've ever met outside tech circles avoids installing OS updates. They end up updating soon anyway for a variety of reasons (some updated apps stop working, update occurs "on its own" overnight, to get rid of of the notification icon, and so on).
  - machinecoffee 7y ago
    It does help that the process is pretty painless. And at least for me, a good excuse to do a reboot - which I really do as seldom as possible on my laptop and iphone.
applecrazy 7y ago
What they should also do is block the malformed message from being sent too. Not sure how to do that, since iMessages are encrypted in transit, but I'm sure there's some way.
- arwineap 7y ago
  Apple controls the CA; it's pretty straight forward for them to check contents. 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.

cellular 7y ago

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?

420codebro 7y ago
It doesn’t work that way. The person with a cell bill will still be charged the downloaded data.
snazz 7y ago
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 7y ago
  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?

HeWhoLurksLate 7y ago

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 7y ago
?
- saagarjha 7y ago
  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 }

Wowfunhappy 7y ago

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

rhinoceraptor 7y ago
It looks like it uses some AppleScript and Frida [1] to inject code into Messages.app on the Mac. 1: https://www.frida.re/ https://www.frida.re/
kccqzy 7y ago
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.

hendersoon 7y ago

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.

ncr100 7y ago

Could a UI input fuzzer have caught this?

tardismechanic 7y ago

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