iOS 13 notification 'text bomb' crashes iPhone, iPad
A new so-called "text bomb," a string of characters that could crash iOS devices if received in a notification, has surfaced online.
A new "text bomb" could crash your iPhone, iPad or iPod touch if it appears in an incoming notification.
Messaging bugs like these show up every now and then. Typically, they're messages of specific characters that can crash an iOS or iPadOS device when received, forcing a device restart.
This specific "text bomb" appears to consist of the Italian flag emoji and a specific Sindhi language character, and impacts all current versions of iOS and iPadOS 13. Reports indicate that the bug only causes crashes if it appears in an incoming notification.
According to information on Reddit, this specific malformed message first started making the rounds on Telegram, but it has also appeared on Twitter. It isn't clear which specific messaging apps the bug impacts, though the fact that it only crashes an iOS device when appearing in a notification suggests that it could be app-agnostic.
Notification-based "text bombs" can be particularly annoying, as they can cause iOS or iPadOS to get stuck in a "re-spring" loop.
A similar bug involving a character in the Telugu language caused a stir back in 2018 when it circulated around the internet.
As with the Telugu bug, it's likely that Apple will issue a fix in an upcoming version of iOS. In the meantime, users who are particularly worried about their devices crashing may want to disable notifications for messaging apps until the problem is resolved. Disabling message previews in notifications may also mitigate impact.
A new "text bomb" could crash your iPhone, iPad or iPod touch if it appears in an incoming notification.
Messaging bugs like these show up every now and then. Typically, they're messages of specific characters that can crash an iOS or iPadOS device when received, forcing a device restart.
This specific "text bomb" appears to consist of the Italian flag emoji and a specific Sindhi language character, and impacts all current versions of iOS and iPadOS 13. Reports indicate that the bug only causes crashes if it appears in an incoming notification.
According to information on Reddit, this specific malformed message first started making the rounds on Telegram, but it has also appeared on Twitter. It isn't clear which specific messaging apps the bug impacts, though the fact that it only crashes an iOS device when appearing in a notification suggests that it could be app-agnostic.
Notification-based "text bombs" can be particularly annoying, as they can cause iOS or iPadOS to get stuck in a "re-spring" loop.
A similar bug involving a character in the Telugu language caused a stir back in 2018 when it circulated around the internet.
As with the Telugu bug, it's likely that Apple will issue a fix in an upcoming version of iOS. In the meantime, users who are particularly worried about their devices crashing may want to disable notifications for messaging apps until the problem is resolved. Disabling message previews in notifications may also mitigate impact.
Comments
Someone’s code needs to be pulled out and rewritten from scratch.
The testing required to catch these kinds of bugs lends itself extremely well to test automation.
Embarrassing, but it still happens. Should never happen again.
I still don’t understand HOW this is even possible to BE a bug. Can someone give a technical explanation?
That is EXACTLY my point.
https://www.inflectra.com/ideas/topic/testing-methodologies.aspx
Better if the lower level text handling was able to fail a bit more gracefully. I was thinking though that the text system is possibly still in the C or Objective C Layer on iOS.
There is a problem for sure, but unit testing in itself isn’t a panacea.
How in the heck does somebody FIND these bizarre combinations? The Italian Flag combined with a Sindhi character? It seems unlikely that someone accidentally stumbled on this.
Sure, someone will now come to your rescue and claim that what you're describing is some simple form of if…else or try…catch, but that's simply not understanding the complexity of programs beyond the most basic things in the language; because unless written by the most basic amateur there's already all kinds of catching of errors and data validation and data being cleaned and data being sandboxed and whatnot, but… then there are the bugs that couldn't be predicted, including problems with the compiler or language itself, or a programmer mistyping something, or an unfortunate case of autocorrect, or a disgruntled employee, or test code accidentally being used live, or a bad copy-paste or cmd-z or about another gazillion other things that can't be predicted and avoided or caught.
Edit: Imagine that the bug is actually in how the display in a very unique situation deals with drawing the shading on somewhat overlapping characters; so it might not be possible to trigger at all unless you in the testing actually include a return code/message from the actual physical display, so in your testing it theoretically is possible that you actually need a physical device to trigger something. So to test everything you'd actually need at least one more physical device that first tries to do everything before it's done on your device. Two phones, with yours always pausing to let the other device try everything first. And even then there's always a layer somewhere that can't be tested, and that might contain bugs.
It's a different type of thinking…
For instance, if I wanted to attack a particular piece of software (without using tools like emulating the software/hardware it runs on, and that way actually seeing what's happening) I might perhaps do something like looking at who's credited with writing the code, and then checking his other (and much more public) work; and that way find his way of thinking, and/or his preferred way of coding certain things. That way I might perhaps find how he usually deals with certain ranges of data, and then see if his closed code project in anyway can be made to handle data that one way or another would be outside of what he would have expected when coding it. If I find something like that, then I would try a couple of ways of throwing such data at the software, to see what happens; and then build on that.
So it isn't just randomly finding things, but rather looking for ways to narrow down potential events that might not be expected; and then playing around with that to see what happens. (And the people actually working with this has a lot of knowhow about what people forget to think about.)