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.

Chris Cirefice
  • 1,460
  • 2
  • 13
  • 21
  • 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](http://en.wikipedia.org/wiki/IMessage#Technology) 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
  • lets wait and see what apple does... – LvB May 27 '15 at 17:36
  • @LvB Well yeah, of course we'll do that :P I was just wondering how these kinds of critical issues are addressed, as this exact problem can port over to a variety of services and software. – Chris Cirefice May 27 '15 at 17:38
  • they always require a custom solution, and involve many disciplines. this is not the right type of media to discuss it. – LvB May 27 '15 at 17:43
  • @ChrisCirefice messages aren't encrypted, or at least not to the eyes of Apple. If they were truly end-to-end encrypted how can I receive iMessages on a new device just by logging in with my Apple account? –  May 27 '15 at 20:00
  • @LvB this bug doesn't only affect iMessage as far as I know. Anything that causes a notification is affected, including plain old SMSes on which Apple has no control about. –  May 27 '15 at 20:03
  • Yes I learned that since I posted that comment. So if apple's smart they patch even the older ios'es – LvB May 27 '15 at 20:05
  • @André "Apple does not log messages or attachments, and their contents are protected by end-to-end encryption so no one but the sender and receiver can access them. Apple cannot decrypt the data." [(Page 35)](http://www.apple.com/business/docs/iOS_Security_Guide.pdf). I don't know about you, but I'm going to trust that a global corporation is not blatantly lying to my face in a formal security report on their OS and protocols. As to *how* you can decrypt on a new device, I don't know. Fancy magic by the CoreService developers? I didn't write the system. – Chris Cirefice May 27 '15 at 20:11
  • @André As this now has less to do with the question, we should take this to [chat](http://chat.stackexchange.com/rooms/151/the-dmz). – Chris Cirefice May 27 '15 at 20:20
  • 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). –  May 27 '15 at 20:47
  • "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." - an interesting case, as security measures made the user experience much much worse. – user253751 May 28 '15 at 03:47
  • @immibis I don't get what you're trying to say. If Apple had not used TLS to encrypt the messages to/from their servers, then they would be able to fix this bug by stripping the bad Unicode. However, that's a breach of privacy. They *do* encrypt, so they can't strip out the Unicode, because the bad Unicode would be encrypted. That isn't really "making things worse", because encryption had nothing to do with the problem. The problem is that the SpringBoard app is crashing due to this bug, when it receives the message to display a notification (in plain text). – Chris Cirefice May 28 '15 at 05:02
  • @ChrisCirefice Huh? First: They can decrypt anything sent to their servers with TLS. I assumed you meant they were doing end-to-end encryption. (Or are they doing end-to-end TLS? That would be unusual). Second: If they don't have end-to-end encryption, then exactly - they can strip the message on the server. That would make the affected phones not crash, avoiding the whole problem. (And depending on whether you consider a mass DoS worse than Apple being able to read your texts, possibly improving security) – user253751 May 28 '15 at 05:04
  • @immibis Sorry, I wasn't clear. TLS is used to establish the connection to their servers, end-to-end encryption is used to encrypt the iMessage itself. Though Apple decrypts as it hit their servers, the iMessage content (the crash-causing Unicode) would still be encrypted, as it wasn't in plain-text when it was sent initially to the server. Whether or not Apple can *still* decrypt is unknown, and it's now a trust issue. See my 2nd bullet point in my question edit and the above comments. If Apple 'fixes' this server-side, we'll know they're MitM 'attacking'. I expect an iOS update will fix it. – Chris Cirefice May 28 '15 at 05:12

2 Answers2

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.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 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](http://security.stackexchange.com/questions/90217/ios-unicode-notification-bug/90219#comment151385_90217). – 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).

Chris Cirefice
  • 1,460
  • 2
  • 13
  • 21