Slashdot Mirror
A Text Message Can Crash An iPhone and Force It To Reboot
DavidGilbert99 writes with news that a bug in iOS has made it so anyone can crash an iPhone by simply sending it a text message containing certain characters. "When the text message is displayed by a banner alert or notification on the lockscreen, the system attempts to abbreviate the text with an ellipsis. If the ellipsis is placed in the middle of a set of non-Latin script characters, including Arabic, Marathi and Chinese, it causes the system to crash and the phone to reboot." The text string is specific enough that it's unlikely to happen by accident, and users can disable text notification banners to protect themselves from being affected. However, if a user receives the crash-inducing text, they won't be able to access the Messages app without causing another crash. A similar bug crashed applications in OS X a few years ago.
Generally, if a carefully-crafted input can cause your application to crash, a similarly-crafted data may be able to exploit the same bug and cause an execution of malicious code. If — as is usually the case — the crash is due to buffer overflow and I can stomp over your app's memory, I may be able to place my code in the right place and it will be executed as part of the app...
There are ways to mitigate that — such as by declaring data-parts of memory non-executable — but the earlier successful exploits of buffer overflow in the image-parsing code suggest, Apple is not using this.
Security — as any good work in general — is hard. Disproportionally harder than the merely Ok work. The real measure is not the number of bugs, really, but the speed of the fixes, once the problems are discovered. Unfortunately, Apple seems to be slow at that too...
In Soviet Washington the swamp drains you.
No, it's 1985 again. Or even earlier. 1985 was when I found out an escape sequence that would reboot the HP100 portable computer my boss used to access the message system on the HP 3000 minicomputer. Cue me sending an email with it in the subject. The reboot took so long the messaging system logged you off and handily when you log in it prints the subjects of your unread emails and around you go again.
This kind of stuff never gets old.
I've got a better story than that. Back in the mid-80's, when I was working at IBM, we did almost all of our programming in REXX and APL2 using dumb terminals.
One of the features of the system was the ability to send a message to another user that would appear directly on his or her screen like a text message.
By accident, one of the guys in my group discovered that by sending a certain string of characters to another user, he could force the receipt's terminal to automatically log off. Predictably, this led to a campaign of various people sending the "message of death" to each other, hearing the recipient yell and curse, and then quickly closing any open file before the victim fired back with a message of his own. This went on for about two weeks before we all got tired of it.
And of course I could also talk about the REXX worm that shut down the entire IBM internal email system for more than a day, but that is another story. :-)
Everything old is new again.
It's not that NSString itself is broken, it's that the fact that 99.99% of the time an NSString is one 16-bit code unit per glyph that apps using it rarely test the use case where it's two code units per glyph. So a person goes in and writes an app that inserts a new character at a particular byte offset and it works 99.99% of the time, but if it happens to get stuck in the middle of a multi-code-unit glyph, the program breaks.
The documentation is no help. First off, it lies:
As we all should know, that's simply not true. Unfortunately, a lot of people don't know better. Unicode is not a universal, uniform encoding scheme that is 16 bits per character. Even UTF-16 isn't that.
characterAtIndex returns a 16-bit integer. So obviously it has no way to actually represent wider unicode characters. The length method is not the number of characters on the screen, but the number of code units, which is different, but highly misleading to programmers. They're, again, the same thing 99.99% of the time, but those rare cases where they're not generally slip through testing. And this is why UTF-16 is such a hazardous encoding to use.
Yes, NSString is old. And that's part of the problem. It was made at a time where many thought that unicode was only going to be 16 bits. It hasn't aged well. And it's caused a lot of bugs over its time. And now I'd bet that it or something similar has created a brand new iPhone-equivalent of Winnuke.
Programmers really need two types of strings, and only two, for the lion's share of tasks. One, binary strings, where a char is always 8 bytes and operations can be optimized to heck and back. And two, unicode strings, where a char always represents a whole unicode character that you would display, and the count of characters represents the count of display characters and so forth. None of this "99.99% of the time it's one thing, but every so often it's another...". That's asking for bugs.
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
And since some characters have different lengths, even counting characters might not be good enough. (Can't use max_bytes=80, nor max_chars=40.)
The message could be "displayed" in memory with the chosen font and size to calculate it's length, then truncate the string in character mode to fit within the limited area.