Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
IOS IT Apple

Bug in Apple Devices Crashes UI With Four-Character Input (techcrunch.com) 71

A newly discovered bug causes iPhones and iPads to briefly crash. All you need to trigger the bug are just four characters. From a report: On Wednesday, a security researcher found that typing "":: can cause the Apple mobile user interface, called Springboard, to crash. TechCrunch verified those characters do crash Springboard when typed into the Search bar in the Settings app, as well as if you swipe all the way to the right on your home screen and type them into the App Library search bar.

As others noted, all that's needed is actually "": and any other character. Triggering the bug briefly crashes Springboard, then reloads to your lock screen. In other tests, the bug flashed the screen black for a second. Researchers tell TechCrunch the bug does not appear to be a security issue. "It's not a security bug," said Ryan Stortz, an iOS security researcher who analyzed the bug. Patrick Wardle, who also researches iOS and founded security startup DoubleYou, agreed.

This discussion has been archived. No new comments can be posted.

Bug in Apple Devices Crashes UI With Four-Character Input

Comments Filter:
  • Maybe it's not a security bug YET, but forcing a restart is likely to be an important step in a chain that is a real security bug.

    • I don't think so because it immediately crashes no matter what i put you put in so there's no opportunity there for creativity.

    • Re: (Score:2, Insightful)

      Yes. It was stupid and, at his level, either dishonest or incompetent to say that a prompt-injection bug of any kind was "not a security bug".
      • by dgatwood ( 11270 ) on Thursday August 22, 2024 @03:35PM (#64727334) Homepage Journal

        Yes. It was stupid and, at his level, either dishonest or incompetent to say that a prompt-injection bug of any kind was "not a security bug".

        Not necessarily. It depends on the type of crash:

        • Use-after-free assertion failure: Possibly a security bug.
        • Any other assertion failure: Almost never a meaningful security bug (notwithstanding the potential for DoS).
        • Null pointer dereference: Maybe a 10% chance of being a security bug.
        • Non-lowmem segfault caused by a data access instruction: probably a security bug.
        • Any segfault caused by the instruction pointer: almost certainly a security bug.

        There are probably exceptions to the above guidelines that I'm not thinking of right now, but that gets you in the ballpark, anyway.

        • by unrtst ( 777550 )

          So, out of the types of crashes you covered, you listed the chances of it being a security bug as:
          * Possibly
          * Almost never (IE: possibly)
          * Maybe 10% (IE: possibly)
          * Probably
          * Almost certainly

          And yet you disagreed with this comment???

          Yes. It was stupid and, at his level, either dishonest or incompetent to say that a prompt-injection bug of any kind was "not a security bug".

          Unless that guy knows a lot of insider stuff they're not telling us (which would also be kinda dishonest), that seems to hold water.

          • by dgatwood ( 11270 ) on Thursday August 22, 2024 @04:13PM (#64727412) Homepage Journal

            Almost never (IE: possibly)

            Within the margin of error of being never. An assertion means that the software realized something was wrong and chose to abort rather than continue. The only way that can be a security bug (unless you consider the ability to use it for denial of service to be a security bug) would be if somehow the assertion fired because of some previous memory corruption, which is just incredibly unlikely to happen without causing a crash earlier. It would be an absolute fluke to find that sort of bug in this way.

            So if the crash falls into that category, then it is entirely reasonable for someone to say that it is unlikely to be a security bug.

            Also, I kind of object to calling this a prompt injection bug unless there's some good reason to believe that AI/ML models are involved. This seems more likely to be a bug in procedural code, I suspect.

            • Itâ(TM)s not a DoS because the user has to type it themselves.
            • by unrtst ( 777550 )

              That's still only one of 5 categories of bug types - the list of which you provided - that is an almost never. Even if that one was a "never a bug" type, that only accounts for 20% of the types of bugs. So again, unless that guy know more than they're letting on, they shouldn't be carte blanche declaring it not a security bug. This isn't even a claim that this _IS_ a security bug, or even that it is likely to be one; It's simply that they shouldn't say it isn't one unless they really really know that, and i

              • by dgatwood ( 11270 )

                That's still only one of 5 categories of bug types - the list of which you provided - that is an almost never. Even if that one was a "never a bug" type, that only accounts for 20% of the types of bugs. So again, unless that guy know more than they're letting on, they shouldn't be carte blanche declaring it not a security bug.

                The person in question this could trigger the crash on demand, and therefore could also see the crash log, which would clearly indicate whether the crash was a thrown exception or not. The only way what you're saying would make sense would be if the people reporting on it did not own an iPhone or did not know how to do basic logs extraction, which is something most iOS devs do regularly.

                • by unrtst ( 777550 )

                  That's still only one of 5 categories of bug types - the list of which you provided - that is an almost never. ...

                  ... The only way what you're saying would make sense would be ...

                  I'm just summing the totals from the list that YOU provided:

                  dgatwood said:

                  Not necessarily. It depends on the type of crash:
                  Use-after-free assertion failure: Possibly a security bug.
                  Any other assertion failure: Almost never a meaningful security bug (notwithstanding the potential for DoS).
                  Null pointer dereference: Maybe a 10% chance of being a security bug.
                  Non-lowmem segfault caused by a data access instruction: probably a security bug.
                  Any segfault caused by the instruction pointer: almost certainly a security bug.
                  There are probably exceptions to the above guidelines that I'm not thinking of right now, but that gets you in the ballpark, anyway.

                  Are you changing your story now and saying that the bug is certainly an assertion failure that is not a use-after-free assertion?
                  If it still could be any of those, then my point stands quite well and makes perfect sense.

        • With an easily reproducible bug like this, you can follow exactly what the outcome is. You might then say âoeif the bug did X then it would be a security bug. But at the same time you find no, it doesnâ(TM)t do X. And then you follow it further.

          If you reach a point where security is broken, itâ(TM)s a security bug. If you reach a point where you canâ(TM)t predict how your code continues , you err on the safe side and assume itâ(TM)s a security bug. If you reach a point where your
    • by AmiMoJo ( 196126 )

      Apple seems to have long standing problems with input sanitisation. Over the years there have been a few of these kinds of bugs. I seem to recall one was triggered by receiving an SMS, i.e. remote DOS attack.

    • it does not force the iphone to restart, just the one app - Springboard
    • Please explain how that would supposedly work.
    • iT jUsT wOrKs!
    • by Bob_Who ( 926234 )

      World's worst Easter Egg ever!

    • by MoHaG ( 1002926 )

      The user needs to enter the string - if it can be triggered from outside, it might be a security bug... (Even if it can run arbitrary code, code execution from an "attacker" (user) that already have arbitrary code execution (can install apps) on the device is not a security issue)

      If it allows running code with elevate permissions though...

  • Hope the simulation we live in isn't that easy to crash.

    • Re:uh'oh (Score:5, Funny)

      by nightflameauto ( 6607976 ) on Thursday August 22, 2024 @03:26PM (#64727320)

      Hope the simulation we live in isn't that easy to crash.

      May I ask why? I for one would love to see the cascading digital failure coming before I cease to exist. Just so I can have one moment of laughter before it all disappears. Maybe the next boot up, 13.8 billion years in, the new me will feel differently, but right now I'm all for mixing it up.

      "Anything different is good." -Phil Connors, Groundhog's Day

      • I was so disappointed when I read that the "Big Collapse" - the universe collapsing in on itself, to lead to another Big Bang - was no longer favored as our form of cataclysmic absolution. I mean, I probably won't be here whenever the heat death of the universe happens, but I was really hoping for a collapse so it would wipe out any possible memento of our embarrassing existence.
        • I was so disappointed when I read that the "Big Collapse" - the universe collapsing in on itself, to lead to another Big Bang - was no longer favored as our form of cataclysmic absolution. I mean, I probably won't be here whenever the heat death of the universe happens, but I was really hoping for a collapse so it would wipe out any possible memento of our embarrassing existence.

          Recommended read: The End of Everything, Astrophysically Speaking by Katie Mack. Highly entertaining in its own right, it also gives those of us that find comfort in the idea that this is all gonna end at some point hope that we may actually get to experience it. Though some of them would really suck. The vacuum collapse theory really blows, pun intended. We wouldn't get to see that one coming. But there's some truly wild theories out there about different things that could glitch up and send a wave of noth

    • I never have mod points when i need them.
    • Hope the simulation we live in isn't that easy to crash.

      IDK. After reading Katie Mack's (aka: AstroKatie) book, The End of Everything (Astrophysically Speaking) [astrokatie.com] and especially the chapter on Vacuum Decay [cosmosmagazine.com], I'm wary. Granted, it may be unlikely and/or very rare, but sounds easy ...

    • Re:uh'oh (Score:5, Funny)

      by dgatwood ( 11270 ) on Thursday August 22, 2024 @03:44PM (#64727360) Homepage Journal

      Hope the simulation we live in isn't that easy to crash.

      Crash, no. That would require that it actually enforce segmentation violations. Instead, it just keeps running and tries to use checksumming and stuff to minimize the amount of data corruption. This is how we got the duck-billed platypus, President Trump, black holes, and Batman.

      The platypus was created when two processes running as root wrote to the same section of memory at once.

      The Trump presidency was caused by an off-by-one error in a for loop.

      Black holes were caused by the slightly broken chipset returning negative infinity when you divide by zero.

      Batman was caused by someone inadvertently computing the value of "not a number" raised to the sixteenth power.

      • When I tried it, it only crashed/killed the GUI for a moment then went to the lock screen like the way CTRL ALT backspace kills X on a Linux box, the operating system seemed unaffected
      • by Bongo ( 13261 )

        And Slashdot was created because calling it Doublequotecolon led to Spring season ending.

    • The universe comes with a real heavy-duty fuzz tester built in, what with all the particles flying around. So I think we're safe.
    • How would we know? We wouldn't even be able to realize when we start over from a save point.
    • beta 17.6.1

      Must be version specific, because I use an old iPhone running 15.8.3, and nothing happens to mine either.

  • Looks like "": followed by just about any other character causes a crash. Oops.

  • by marcle ( 1575627 ) on Thursday August 22, 2024 @03:34PM (#64727328)

    I've got an iPhone 13 Pro running iOS 17.5.1, and this doesn't crash my phone at all. Going to Settings, tapping Search, and typing in "";; simply brings up some search results (nothing very interesting).

    Too bad the article didn't specify iOS version, hardware models, etc.

    • Colon, not semicolon. Same model/version here, not that I ever use springboard, but it does crash it.
      • How exactly do you not use Springboard?

        • Apparently I do, I had to look up what it is. I just assumed it was that new search/common apps screen (the one that's like Launchpad in OSX - which I also never use) but apparently it's basically just what runs the home screen. Never heard the name before today.
    • by znrt ( 2424692 )

      you're crashing it wrong!

      steve.

    • Crashed me out on an xr running 17.6.1. Same on a 15 Pro running 17.6.1

      Didn't even have to hit enter, just two quotation marks, two colons, boom, crash.

  • weird, did not crash....14pro, 17.6.1 I must be doing something wrong...
  • On my iphone13 in the app library search I typed in "":: and it killed the GUI like Ctrl alt backspace kills X on an old linux box,
  • by Rosco P. Coltrane ( 209368 ) on Thursday August 22, 2024 @04:16PM (#64727418)

    It doesn't matter how hard Apple try to sell the idea that their stuff is more secure and better engineered than everyone else's: it isn't. All software and every OSes are chock-full of yet-undiscovered dumb bugs and vulnerabilities. Apple's, Microsoft's, Linux', Google's... Everybody's.

    Apple's shortcomings are just less visible than Microsoft's. Well, everybody's shortcomings are less visible than Microsoft's in fairness, because Microsoft is exceptionally good at shooting itself in the foot in the most spectacular fashion.

    Stupid bugs like this one are a good thing: they remind everybody that Apple's PR is just that: PR.

    • the idea that their stuff is more secure and better engineered than everyone else's: it isn't. All software and every OSes are chock-full of yet-undiscovered dumb bugs and vulnerabilities.

      You could say that about literally anything, F-150 > Cybertruck, Cybertruck > F-150
      They all have undiscovered and known defects, true, nobody disputes that.
      Pointing out one F-150 bug or one Cybertruck bug doesn't disprove either assertion. It's just a weird ax to grind.

      Apple's hardware and software is better designed than everyone else's, AND all OSes and software have bugs. It's a mind blowing concept.

  • In the apps it affects, it only crashes that app. On the app screen it crashes springboard because you are in springboard. In settings, it just crashes settings and brings you back to springboard. I wonder what other searches this affects?
    • by m2pc ( 546641 )
      I was able to get Apple's "Notes" app to crash as well with that search string.
      • Erm... Begs a few questions:

        1. Why is a service running that parses text inputs in every app?
        2. Why is it that said service is capable of crashing any app at all? I don't know iOS internals but that has an odor of sharing or at least injecting into the same memory space, which is dangerous
        3. When will apple ever stop introducing text parsing bugs capable of trashing multiple layers of the software stack? That has an even stronger odor of bad coding practices overall

        • 1. Why is a service running that parses text inputs in every app?

          Possibly to provide consistent text transformations across apps, so shortcuts like (C) get replaced with the © symbol consistently. (Not to mention all sorts of slashdot-breaking substitutions like smart quotes, ellipses, etc.) Probably also for reasons involving copy/paste, password field inputs, etc. You really don't want every app to have to implement all that internally.

          2. Why is it that said service is capable of crashing any app at

          • Possibly to provide consistent text transformations across apps, so shortcuts like (C) get replaced with the © symbol consistently.

            Why on earth would they do it that way instead of having context system? E.g. long press C or adding a symbol button? Less finger movement for sure this way.

            You really don't want every app to have to implement all that internally.

            You shouldn't even need to in the first place. The fact that we're even having this conversation speaks loudly about just how bad their engineers are.

            Because... it's software. How do you propose it be made incapable of crashing?

            By using channels to communicate instead of communicating by overwriting shared memory when you have no guarantee of it being safe to do so. That's just really, really bad coding, and it's things like that

  • install linux

      it deletes all your data, launches CD's at your pets, and then freezes up.

  • Update to article it does not seem to only be "": + any character, it will also restart Springboard on " +any characters/text/number+":
    Though no info has been spread yet, maybe it can be used to enter secret debug menus "debugradio": or "deactivatefaceid":
  • by RUs1729 ( 10049396 ) on Friday August 23, 2024 @09:08AM (#64728794)
    As opposed to - what? To protractedly crash? If it crashes what difference does it make?
  • How does a bug like this happen?? It is incomprehensible.

Digital circuits are made from analog parts. -- Don Vonada

Working...