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.
it's a parsing bug, what difference would sanitizing user input make...
Yes, technically there is a way to execute phone specific code with specially crafted text messages. This is not doing that. It's not executing a program. The system is trying to abbreviate the contents of the message to display in a notification banner or on the lock screen through a widget (or whatever apple calls them). The system is doing something it's designed to do, but due to lack of foresight or just shoddy development, they never bothered testing this with special characters. And some clown obviously found the bug. This is actually pretty big. So in the past few months I've learned about 3 important issues with IOS devices, even those running the current release: 1)They are still including a chinese root cert that has been delisted for handing out forged google certs, and who knows what else. 2)A specially crafted access point being in range of your IOS device can cause it to become unstable and eventually crash, even if you have not connected to that network 3)A specially crafted text message can crash your phone upon receiving it. Lets be clear, I'm not saying Android doesn't have some major issues as well, so don't try to fanboy me. But this is not what I expect from Apple. This is just bad. Lack of sanity testing? Keeping their users at risk seemingly just to say FU to google?
https://xkcd.com/327/
I still laugh at this... am I an idiot? Don't answer that.
Sanitize a language people use for actual communication? The text shouldn't have to change. This is a case of bad coding and nothing more.
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.
I'd be willing to bet that the unicode library they were using was UTF-16 . Either that or they were handling unicode in a straight binary string with something homebrewed. Both are horribly dangerous - the latter for obvious reasons, but the former in particular because it makes it easy to code something that "just works" for 99,99% of cases, but those rare 0,01% side cases involving 32-bit unicode characters slip through testing and come back and bite you down the road. It's amazing how many apps have incorrect behavior with 4-byte unicode characters, on a wide range of platforms.
Both should be considered bad practice and programming languages evolved to standardize on UTF-8 for any string format that is to handle unicode. C++ for example needs to introduce something along the lines of "std::ustring" that makes unicode string ops "just work" with a UTF-8 backend, at the cost of some memory and performance vs. std::string, which should be seen as exclusively for ascii and binary string operations. std::wstring should be obsoleted.
POTUS Witch Hunt tracker: 75 charges filed against 19 witches, 4 witches cooperating and 5 witches have pled guilty.
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.
It wouldn't be a parsing bug if the parser sanitized its input.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
I'm willing to accept a garden with walls if it means I don't have to constantly worry about what unpatched vulnerability is ripe for exploitation on my phone.
You mean like that vulnerability where I can send you a text message and cause your phone to crash? ;-)
I wish I were as sure of anything as some people are of everything
See everyone? Apple doesn't invent anything! They just do it with more polish.
If you were me, you'd be good lookin'. - six string samurai
Here.
https://www.reddit.com/r/apple/comments/37enow/about_the_latest_iphone_security_vulnerability/
We've come to a time that reddit posts are more infotmative then slashdot articles.
Never. Ever. Do. That. Again.
Or I will mark you as a troll if I have mod points. And frankly, I hope somebody does that to this one.
If you're going to post an informative link from Wikipedia, go straight to Wikipedia; not that wikiwand crap. Using that link to a site pushing a formatting extension that changes the way wikipedia's UI format looks is trolling for users to hijack with a MitM attack. This is fucking /. The general population knows better than to install random extensions from unverified sources. Go pedal your crapware on reddit.
It's not a special character that needs escaping. It's a character that needs multiple bytes to specify the code point. The parser just isn't handling the fact that you can't just crop a character mid code point - it's operating at the byte level when it should be operating at the code point level during a crop operation.
Just because it's unlikely with a real text string doesn't mean that any of the text is invalid for a message. The text string should still not need to be changed. The bug only affects notifications, and it's clear that the text can be displayed just fine in conversation view.
This is almost certainly due to splitting multibyte characters on sub-character boundaries. That's a design problem, not a sanitizing problem.
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.
I immediately tried to crash every phone of every coworker who has an iPhone within earshot of me and it didn't work.
I too enjoy getting fired over stupid shit. Do you have any other suggestions I might try?
Dewey, what part of this looks like authorities should be involved?
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.