Benign bug in iOS and iPadOS crashes gizmos with just four characters Typing a special four-character string will crash your iPhone thanks to a newly discovered, albeit benign, bug in iOS and iPadOS. The bug affects SpringBoard, the underlying application that manages iPhone and iPad home screens. Simply typing "":: in a select few search bars within iOS and iPadOS will cause apps to abort in …
It's amazing (but not amazing) how many times over the decades parsing errors are crashers. Nobody writing parsers ever seems to think of the worst case scenarios, and then of course someone finds it.
Especially when the parser starts out simple, then a thousand increasingly complex use cases are stacked on top of it. I'm guessing whatever's looking for "[x]" and [y]:[z] are two separate bits of logic in the parser, both added much later, and the "" parsing sets something the : parsing doesn't expect and it goes right off the end of the string.
This is where fuzz testing helps a lot.
Parsers are actually really hard. A lot of the field of compiler theory is writing robust parsers and handling ill-formed text without crashing.
In a lot of languages, it's actually really difficult to find out exactly where a syntax error is so you can emit an appropriate error message. Are there too many closing braces, or is it actually an opening brace was omitted?
Edit: I remember a couple BASICs that would just go "syntax error" and not even attempt to tell you which line.
That depends quite a bit on just what you're doing and how you're going about it. If doing, say, a Crenshaw-style parser, it's not hard to keep track of exactly where you are in the input and exactly what it is that you're expecting right now to be in there. It is quite limited in what sort of grammar it can parse, but search input should be well within its capabilities. Going backward and forward (with a more advanced method) covering for all the overlapping possibilities is one way that things can get hairy in a hurry.
Though thinking about this scenario, the quotes might introduce a token even though it turns out to be empty, and the colon might trigger a keyword lookup (like site or inurl or whatever, just guessing here), and the lookup assumes the token isn't empty. If that's the case, then this is a simple broken-and-unchecked assumption.
It doesn't look that easy because any string inside the quotation marks does the same thing. Maybe there are a few tokens that, if placed in there, would do something and not crash, but if so, it's not just a missing check for an empty string but a check for being present in a list of recognized tokens.
> In a lot of languages, it's actually really difficult to find out exactly where a syntax error is so you can emit an appropriate error message. Are there too many closing braces, or is it actually an opening brace was omitted?
True, some languages are very hard to parse. C++ can be a right bugger.
But why is there anything even vaguely complicated to parse in a search box for Settings or Notes? What could even need proper parsing? That is, anything more complicated than a bit of lexing or even, dare I say it, trying out a few select regexs on the input?
Someone suggested that the presence of colons in the trigger phrases could be related to looking for URLs - in which case, what kind of URL starts with quotes (or are those apostrophes, no matter, same response)?[1]
If you have a search box routinely worrying about such things as matching parentheses then something has gone very wrong somewhere!
[1] before you ask, yes, I have written a lexer that looks for URLs, as part of a Wiki parser - which never generates an error message, a "failed" parse just gives up and leaves that bit untouched, attaching no special significance to it - which is what I'd expect a search box to do when you gave it "malformed input": just search for that exact string without even attempting whatever cleverness it was hoping to do. Duff URLs don't get converted into hyperlinks, loony dates don't get added to the timeline, malformed smileys are not replaced by any appropriate image.
A test engineer enters a bar and orders a beer
A test engineer enters a bar and orders a thousand beer
A test engineer enters a bar and orders zero beer
A test engineer enters a bar and orders minus one beer
A test engineer enters a bar and orders NaN beer
A test engineer enters a bar and orders beer
A test engineer enters a bar and orders a coat
...
When you say it "works on", do you mean the attempt to cause a problem did cause a problem, so the method to *break* the phone works, or did you mean that the *phone* works without a problem, i.e. the attempt to cause a problem did not work?
And did you mean "whatever I meant, it happens that way on the one or two devices I happen to have to hand" or "across all 127 devices I was able to test" or "I'm just reporting what a bloke down the pub told me is going on"?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
