3

Evidently, someone has discovered a Unicode bug in iOS, where if an app receives a specific Unicode sequence (infinitely-repeating Unicode code point), the OS will kill the Springboard as it allocates too much memory, restarting it immediately. I can't include the sequence here, because SE detects it and denies including it in the body.

Now, this doesn't seem like a serious issue; "Oh, my phone was reset randomly. Great.", but this is posing a great risk to the availability of iOS devices everywhere. For instance, if I know a person that has an iOS device, I could send this message anonymously through a fake Apple account via iMessage on a Mac OSX/iOS device to reset their phone (even in the middle of a call, as this is a notification bug).

If I were truly malicious, I could write a script on Mac OSX to generate a list of (semi)-random phone numbers to send this message to every X minutes, effectively permanently putting their device in a resetting state (preventing them from patching, doing anything important, etc).

Apple is aware of the issue and their devs are fixing it, but a huge amount of users delay updates as long as possible, or simply don't bother to update; this means that the issue could be a permanent threat to them.

Methods I've thought of to fix the issue that seem impossible:

1.) Push a hot-fix to iOS devices (is this even implemented?)

2.) Force an update to the latest version of the OS (seems to breach privacy/ToS agreement)

Since this poses a threat to the availability of Apple devices, I figured I would ask the security experts: how can Apple ensure that this issue does not plague (software-outdated) iOS devices in the coming years?

Edit: The problem is two-fold:

1.) Pre-send validation in iOS requires an update, as the code to whitelist Unicode characters obviously doesn't exist yet, otherwise this wouldn't be an issue; this is why I asked the question.

2.) This problem can't realistically be fixed server-side as Apple is relaying the message, because Apple encrypts the messages before they are sent, and if they decrypted the messages to strip out bad Unicode, it would be a breach of users' privacy.

  • 1
    apple could fix this server side. simply filtering out this sequence before relaying it to the device. – LvB May 27 '15 at 17:21
  • @LvB How, when the message content are encrypted and Apple cannot themselves decrypt the message body? Consider that, if they could, it would be a serious breach of privacy, and would completely defeat the point of encrypting the message in the first place. The only fix that would bypass that is sending metadata with the message like "message contains invalid Unicode". However, that would require a patch to the OS/application, which requires updates, and you see that we're back to square one here. – Chris Cirefice May 27 '15 at 17:29
  • right, they did kick out the NSA... forgot about that. but if they really wanted to they could. just for an automated process would not even break privacy necessarily... still dangerous though... – LvB May 27 '15 at 17:32
  • @LvB I agree that it's "just for an automated process", but consider that decrypting the messages, even for a few microseconds, is a privacy concern and would, most likely, breach Apple's own Privacy Policy. Then again, I'm not a lawyer. I just know that if people say they're encrypting, then they decrypt, even on their own systems, they often get sued for it. – Chris Cirefice May 27 '15 at 17:34
  • 1
    @ChrisCirefice to recap what we said in chat, I don't recommend trusting the security guidelines unless they're backed by source code (and you can prove it's indeed that code that's running on your device). – user42178 May 27 '15 at 20:47
1

Generally speaking, if I have an application that I know doesn't need the entire UTF8, UTF16 or UTF32 character set, I'll limit it to just what is needed.

That being said, I'd whitelist certain character sets within an encoding. Special control characters would be either ignored or replaced using a regex or similar.

This concept is portable to other platforms and technologies.

  • It seems that Stack Exchange also uses this approach, as I wasn't able to post the sequence in the question, and the error referenced the line which contained the buggy Unicode. But again, this is client-side code (iOS), which would require an update to implement, thus why I asked the question :) I really doubt it can be fixed server-side, even though all iMessages are passed through Apple's servers, due to the reasoning in my other comment. – Chris Cirefice May 27 '15 at 17:32
0

It turns out that Apple did indeed 'fix' this server-side. Evidently they had a mechanism to force iMessage off when a device tried to send an iMessage.

This is anecdotal:

My iPhone reverted to standard SMS even when communicating with other iPhones (which also reverted to SMS), and iMessage on my iPad ceased to work.

Apple mentioned this bug in iOS update 8.4.1 and, once I updated, my device's iMessage began to work again, but only with iOS devices that had also been updated to 8.4.1.

Thus, it is safe to assume that Apple was disabling iMessage server-side based on iOS version, and only allowed iMessages to go through when the recipient was on iOS > 8.4.1 (which had the Unicode bug fix).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.