{"id":25875,"date":"2019-07-08T14:57:41","date_gmt":"2019-07-08T18:57:41","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=25875"},"modified":"2019-07-08T16:08:57","modified_gmt":"2019-07-08T20:08:57","slug":"malformed-imessage-could-brick-iphone","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/07\/08\/malformed-imessage-could-brick-iphone\/","title":{"rendered":"Malformed iMessage Could Cause iPhone Boot Loop"},"content":{"rendered":"

Project Zero<\/a> (via Hacker News<\/a>):<\/p>\n

The method -[IMBalloonPluginDataSource individualPreviewSummary]<\/code> in IMCore can throw an NSException<\/code> due to a malformed message containing a property with key IMExtensionPayloadLocalizedDescriptionTextKey<\/code> with a value that is not a NSString<\/code>. This method calls [IMBalloonPluginDataSource _summaryText]<\/code> which returns the property assuming it is a string, but this is not checked. The calling method then calls -[IMBalloonPluginDataSource _replaceHandleWithContactNameInString:]<\/code> which calls im_handleIdentifiers<\/code> on the NSString<\/code> which is really an NSNumber<\/code>, which throws an exception as the selector does not exist in that class.<\/p>

On a Mac, this causes soagent to crash and respawn, but on an iPhone, this code is in Springboard. Receiving this message will case Springboard to crash and respawn repeatedly, causing the UI not to be displayed and the phone to stop responding to input. This condition survives a hard reset, and causes the phone to be unusable as soon as it is unlocked. The only way I could find to fix the phone is to reboot into recovery mode and do a restore. This causes the data on the device to be lost though.<\/p><\/blockquote>\n\n

The bug is fixed<\/a> in macOS 10.13.4 and iOS 12.3, but what about customers on previous OS versions? Now that the bug is known, they could be targeted. And it doesn’t seem like Apple could intercept the bad messages at the server level without decrypting private messages.<\/p>\n\n

NSSecureCoding<\/code> can’t really protect against this kind of mistake. Maybe Swift could have, depending on how the code was written.<\/p>\n\n

I recently ran into a similar bug with AVPlayer<\/code>, where using the scroll wheel calls an internal method with the wrong data type where a number was expected, causing an exception and alert window. I’m sure sort of thing happens all the time, throughout the iOS\/macOS and apps, but rarely are the potential consequences so dire.<\/p>\n\n

Previously:<\/p>\n