iOS 13 notification 'text bomb' crashes iPhone, iPad

Posted:
in General Discussion
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
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.
«1

Comments

  • Reply 1 of 22
    Rayz2016Rayz2016 Posts: 6,957member
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    dysamoriajony0MplsPbonobobPetrolDavemuthuk_vanalingamGilliam_Bates
  • Reply 2 of 22
    dewmedewme Posts: 5,531member
    This bug should have been caught at the Unit Test level with automated Fuzz Testing.  

    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.


    dysamoriaPetrolDavemuthuk_vanalingam
  • Reply 3 of 22
    dysamoriadysamoria Posts: 3,430member
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    Agreed. What the hell is going on in the text system that characters can crash it? And it’s only an iOS thing?? It’s not a mature and robust set of API elements. But then I knew that already, because of how text fields behave in Safari on iOS (abysmally & inconsistently!).

    I still don’t understand HOW this is even possible to BE a bug. Can someone give a technical explanation?
  • Reply 4 of 22
    lkrupplkrupp Posts: 10,557member
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    shark5150StrangeDaysjony0mike1lam92103PetrolDave
  • Reply 5 of 22
    dewmedewme Posts: 5,531member
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    ... which is exactly why test automation is routinely used to uncover this sort of defect. Test scripts and computers have nothing better to do and work for nothing more than a little bit of electricity.
    PetrolDavelkruppGilliam_Bates
  • Reply 6 of 22
    StrangeDaysStrangeDays Posts: 12,955member
    dewme said:
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    ... which is exactly why test automation is routinely used to uncover this sort of defect. Test scripts and computers have nothing better to do and work for nothing more than a little bit of electricity.
    How long would it take to test combinations of all supported language glyphs with every emoji? Wouldn’t it take years?
    lolliverlkrupp
  • Reply 7 of 22
    dewmedewme Posts: 5,531member
    dewme said:
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    ... which is exactly why test automation is routinely used to uncover this sort of defect. Test scripts and computers have nothing better to do and work for nothing more than a little bit of electricity.
    How long would it take to test combinations of all supported language glyphs with every emoji? Wouldn’t it take years?
    Yes, testing all possible combinations of 143,924 Unicode character combinations (emoji are text) using brute force, black box testing, like trying to crack a password, would take forever.  But there's no reason to take such an approach, especially when they have previous crash information, know what induced previous crashes, and understand the common properties and characteristics for the underlying symbol sets, control characters, languages, etc. Throwing a representative set of test cases at the code, with some degree of randomization, and applying a white box testing approach to force all known code paths to be executed, would certainly not be all-inclusive, but it would certainly exercise a lot more variations using scripted test automation than they could ever achieve using manual testing or a black box approach, or no testing. I'm assuming they've been doing automated testing all along, have regression tests defined for their existing code that execute at every single build, and that the primary focus for broader based testing is in areas where new features have been added, which further reduces the overall test burden.
    PetrolDavemuthuk_vanalingamGilliam_Batesbeowulfschmidt
  • Reply 8 of 22
    MplsPMplsP Posts: 3,966member
    dewme said:
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    ... which is exactly why test automation is routinely used to uncover this sort of defect. Test scripts and computers have nothing better to do and work for nothing more than a little bit of electricity.
    How long would it take to test combinations of all supported language glyphs with every emoji? Wouldn’t it take years?
    I'm more curious as to the mechanism of the bugs. on the surface they seem similar which makes it appear that the code has a more fundamental problem.
    muthuk_vanalingam
  • Reply 9 of 22
    Rayz2016Rayz2016 Posts: 6,957member
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    And that is precisely why the code needs to be pulled out and rewritten. If they’re patching the code every time a new character combination appears then I’m afraid they’ve written it wrong, and it will remain vulnerable forever. 
    PetrolDavemuthuk_vanalingamrazorpitIreneW
  • Reply 10 of 22
    Rayz2016Rayz2016 Posts: 6,957member

    MplsP said:
    dewme said:
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    ... which is exactly why test automation is routinely used to uncover this sort of defect. Test scripts and computers have nothing better to do and work for nothing more than a little bit of electricity.
    How long would it take to test combinations of all supported language glyphs with every emoji? Wouldn’t it take years?
    I'm more curious as to the mechanism of the bugs. on the surface they seem similar which makes it appear that the code has a more fundamental problem.
    That is EXACTLY my point. 
    muthuk_vanalingamMplsPrazorpit
  • Reply 11 of 22
    CheeseFreezeCheeseFreeze Posts: 1,297member
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    But that’s not how testing is (not should be) done. 
    Engineers should write testable code, and Apple probably has very clear and sophisticated guidelines for it. With their huge codebase however mistakes are inevitably made in writing code as such. 

    Automated testing in this case can be done by firing millions of text combinations, and the results of how it’s interpreted on the receiving end can be logged, filtered and acted upon. This is all simulated (it doesn’t have to be on actual phones - but done at a source code level).

    https://www.inflectra.com/ideas/topic/testing-methodologies.aspx
    PetrolDave
  • Reply 12 of 22
    asdasdasdasd Posts: 5,686member
    dewme said:
    This bug should have been caught at the Unit Test level with automated Fuzz Testing.  

    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.


    Given the number of inputs ( all the characters in all the languages in the world in any combination) that wouldn't be feasible.

    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. 
    edited April 2020 watto_cobra
  • Reply 13 of 22
    Rayz2016Rayz2016 Posts: 6,957member
    dewme said:
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    ... which is exactly why test automation is routinely used to uncover this sort of defect. Test scripts and computers have nothing better to do and work for nothing more than a little bit of electricity.
    How long would it take to test combinations of all supported language glyphs with every emoji? Wouldn’t it take years?
    Eons 
    edited April 2020 razorpit
  • Reply 14 of 22
    Rayz2016Rayz2016 Posts: 6,957member
    asdasd said:
    dewme said:
    This bug should have been caught at the Unit Test level with automated Fuzz Testing.  

    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.


    Given the number of inputs ( all the characters in all the languages in the world in any combination) that wouldn't be feasible.

    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. 
    And isn’t the whole sandboxing thing supposed to prevent bugs like this from taking down the whole operating system? 

    Ah. But wait. The text engine is part of the operating system. 🤦🏾‍♂️
    edited April 2020 razorpit
  • Reply 15 of 22
    dewmedewme Posts: 5,531member
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    But that’s not how testing is (not should be) done. 
    Engineers should write testable code, and Apple probably has very clear and sophisticated guidelines for it. With their huge codebase however mistakes are inevitably made in writing code as such. 

    Automated testing in this case can be done by firing millions of text combinations, and the results of how it’s interpreted on the receiving end can be logged, filtered and acted upon. This is all simulated (it doesn’t have to be on actual phones - but done at a source code level).

    https://www.inflectra.com/ideas/topic/testing-methodologies.aspx
    The testing you’re describing is called unit testing. In fact, modern code generation tools also generate a unit test code wrapper for every function in the class wrappers it generates. There are also unit test code engines like NUnit that create executable unit test code scripts that run on every build. Development teams that are using continuous integration (CI) and continuous delivery (CD) are also doing continuous testing. 

    I do agree with those commenters who understand the numerical complexity of trying to test all possible combinations using brute force, black box techniques. It’s impossible. However, I also believe that developers who understand the code and the nature of the inputs they are dealing with can come up with a much smaller subset of input combinations that exercise their code paths. 

    I’m a big believer in CI and CD and one of the foundational rules of CI/ CD is that there is no longer a difference between a software developer and a software tester - all developers are also testers, at least at the unit test level. If you write a piece of code you must also write a unit test for it. Period. If you don’t, the code cannot be integrated and cannot be delivered. This is the essence of test driven development (TDD). 
  • Reply 16 of 22
    razorpitrazorpit Posts: 1,796member
    Rayz2016 said:
    asdasd said:
    dewme said:
    This bug should have been caught at the Unit Test level with automated Fuzz Testing.  

    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.


    Given the number of inputs ( all the characters in all the languages in the world in any combination) that wouldn't be feasible.

    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. 
    And isn’t the whole sandboxing thing supposed to prevent bugs like this from taking down the whole operating system? 

    Ah. But wait. The text engine is part of the operating system. 🤦🏾‍♂️
    I was thinking, why can’t there be a sandboxed function that every incoming text And paste command gets passed through. If the function returns a “0” the text message is displayed or the paste completes. If it returns a “1” then the text is forwarded to Apple and the message to the user is killed. 

    While not perfect, you could theoretically come up with the next combination by typing in Pages, Notes, Messages, etc. but then that’s on you for trying to figure out what the next viral message is.
  • Reply 17 of 22
    StrangeDaysStrangeDays Posts: 12,955member
    dewme said:
    dewme said:
    lkrupp said:
    Rayz2016 said:
    This happened once before. They fix it. And it happens again with a different set of characters?
    Someone’s code needs to be pulled out and rewritten from scratch. 
    And the new code would still have bugs. Software engineers and coders don't have the time or inclination to spend hundreds of hours trying  random, different key combinations to find one that exposes a bug. That’s for the wack jobs who sit around all day, every day, in their parent's basements, fiddling around. 
    ... which is exactly why test automation is routinely used to uncover this sort of defect. Test scripts and computers have nothing better to do and work for nothing more than a little bit of electricity.
    How long would it take to test combinations of all supported language glyphs with every emoji? Wouldn’t it take years?
    Yes, testing all possible combinations of 143,924 Unicode character combinations (emoji are text) using brute force, black box testing, like trying to crack a password, would take forever.  But there's no reason to take such an approach, especially when they have previous crash information, know what induced previous crashes, and understand the common properties and characteristics for the underlying symbol sets, control characters, languages, etc. Throwing a representative set of test cases at the code, with some degree of randomization, and applying a white box testing approach to force all known code paths to be executed, would certainly not be all-inclusive, but it would certainly exercise a lot more variations using scripted test automation than they could ever achieve using manual testing or a black box approach, or no testing. I'm assuming they've been doing automated testing all along, have regression tests defined for their existing code that execute at every single build, and that the primary focus for broader based testing is in areas where new features have been added, which further reduces the overall test burden.
    I also have no reason to believe Apple doesn’t employ automated testing, but I don’t believe unit testing can catch this since it would take years to try all possible problem combinations. Even a subset of languages, now with emoji, would likely still take too long. 

    There is a problem for sure, but unit testing in itself isn’t a panacea.
    edited April 2020 linkmanasdasd
  • Reply 18 of 22
    DAalsethDAalseth Posts: 2,853member
    I keep wondering about a deeper issue:

    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.
    razorpit
  • Reply 19 of 22
    svanstromsvanstrom Posts: 702member
    razorpit said:
    I was thinking, why can’t there be a sandboxed function that every incoming text And paste command gets passed through. If the function returns a “0” the text message is displayed or the paste completes. If it returns a “1” then the text is forwarded to Apple and the message to the user is killed. 
    Practically speaking that's just pushing the problem into another layer, while at the same time saying that that layer can't have any bugs; and then when a bug surfaces in that layer, then you'd say the same thing about another layer that is supposed to not have any bugs in it, and then another, and another… So practically speaking your idea is essentially the same as you simply saying "I was thinking, why can't there be no bugs anywhere".

    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.
    edited April 2020 razorpit
  • Reply 20 of 22
    svanstromsvanstrom Posts: 702member

    DAalseth said:
    I keep wondering about a deeper issue:

    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.
    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.)
    razorpit
Sign In or Register to comment.