This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear.<p>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.
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.<p>[1]: <a href="https://support.apple.com/en-us/HT210118" rel="nofollow">https://support.apple.com/en-us/HT210118</a><p>[2]: <a href="https://support.apple.com/en-us/HT210119" rel="nofollow">https://support.apple.com/en-us/HT210119</a>
For those with jailbroken iPhones, a community member has released the tweak BrickFix: <a href="https://www.reddit.com/r/jailbreak/comments/c9616j/release_brickfix_fix_for_imessage_bug_that_can/" rel="nofollow">https://www.reddit.com/r/jailbreak/comments/c9616j/release_b...</a>
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.
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
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.
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.
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?)
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?
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.
Can this be avoided by disabling iMessage notifications?<p>> <i>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.</i><p>Looks like they need to move more of their stuff to Swift to reduce snarfles like this.<p>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.<p>Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares walked the land.
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<p>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...
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.<p>(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...)
With ALL their infinite resources, how are Apple's bugs SO BAD.<p>Like, repeatedly.<p>goto fail, Facetime surveillance, empty password grants root access, and now this.<p>As much as Apple touts privacy and security, this is not a great track record.<p>The more resources a company has, the less forgivable serious bugs like this are.<p>I need to keep reminding myself: Apple is a hardware company, not a software company.
Lazy developers throw exceptions, good developers return errors. Exceptions should be exceptional.<p>I'll use URL to this bug in my next comment-holywars to prove this point.<p>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).