Not totally convinced that providing a handy place to grab the text so anyone can send it to all their iPhone owning friends was the best idea in the world. It only works if it is formatted correctly across multiple lines, so reproducing the text on a single line would have been a better option (IMHO of course)
That EVIL TEXT that will CRASH your iPhone: We pop the hood
Cads and/or bounders can crash and reboot iPhones from afar by sending them specially crafted texts, thanks to a new vulnerability in iOS. A 75-byte sequence of unicode characters triggers the glitch, and can be smuggled into text messages, causing iThings to crash if they appear in the victim's notification screen. Texting …
COMMENTS
-
-
-
-
Thursday 28th May 2015 03:32 GMT Anonymous Coward
Full Text
And thats your defense for publishing it?
Isn't that a good enough defence?
The full text is in the wild, it is findable by a google search so not publishing it wouldn't achieve much other than forcing the curious to leave El Reg and go to Google to find it.
Publishing it, on the other hand, allows them to properly talk about the problem.
I know which seems better to me.
-
Thursday 28th May 2015 17:26 GMT erikj
Re: Full Text
My kids and their mates have been gleefully crashing each others iStuff all week at school -- so I'd say the vulnerability is rather well publicized in the wild. I see it as a digital (and slightly better) equivalent to smashing actual mailboxes -- and possibly just as much of a federal crime. Time to have a fatherly chat.
-
-
-
Thursday 28th May 2015 14:35 GMT DJO
Not totally convinced that providing a handy place to grab the text
But it's not, the article has a bitmap of the text which can't be copied to unicode, to do that you'd have to know the code for each of the symbols which while not impossible is reasonably tricky, certainly harder than tracking down the offending string from another source so I'd say there's no harm done in showing the message here.
-
-
-
-
Friday 29th May 2015 05:08 GMT Ian Michael Gumby
@Natallie
Clearly you have a limited view on software development and how things work.
Your messages have to be routed to go from you to your friends' iPhones and what not.
So of course they have a way to this.
If you looked at Apple's ecosystem iStore, iCloud, etc ... all features revolve around Apple and they have a lot of potential to snoop if they so desired. It makes a lot of sense from a design perspective, and nothing to get your panties in a twist over.
Now if you wanted to talk about Google... that's a different story.
-
Friday 29th May 2015 13:36 GMT Anonymous Coward
Re: @Natallie
> Clearly you have a limited view on software development and how things work.
And clearly you have a limited view on telecommunications and how proper systems design works.
For data to be routed, there is no need to have access to the information therein.
Surely, a "how things work"-aware type of person is already familiar with OTR?
-
-
-
-
-
Wednesday 27th May 2015 23:10 GMT Anonymous Coward
Off by one error.
"I'm getting an overpowering sense of déjà vu here. Didn't this, or something very similar, happen last year too?"
Yes, but I think you may have an "off by one" error (2013 not 2014). They're my favourites too.
Or maybe it's 2013, 2014, AND 2015.
Either way, wtf?
Linl to El Reg 2013 article (from today's article):
http://www.theregister.co.uk/2013/09/04/unicode_of_death_crash/
See also e.g.
http://arstechnica.com/apple/2013/08/rendering-bug-crashes-os-x-and-ios-apps-with-string-of-arabic-characters/
"There's a new bug in town, and it's here to crash your Mac and iPhone applications. Posters in a HackerNews thread from late yesterday have discovered that it's possible to crash Web browsers and other apps running on current versions of iOS and OS X by making them render a specific, nonsensical string of Arabic characters. The title of the HackerNews thread implies that the issue is with the WebKit browser engine, but it actually affects any browser or application that uses Apple's CoreText API to render text. Ars Microsoft Editor Peter Bright has taken great pleasure in sending the text string to his co-workers, which has crashed the Limechat IRC client and Adium chat client, among other programs."
[continues]
-
Thursday 28th May 2015 10:46 GMT h4rm0ny
Yes. A couple of years ago:
It was exactly what I thought of when I read the story. I wouldn't have thought they'd be caught out like this twice. Apple are usually better than this, but there you go...
Incidentally, El Reg. seem to be giving up any pretence of knowing parody these days and just going for direct Daily Mail style gratuitous sexualisation. Unless I'm missing some subtle relevance to the giant image of a strapless model to this article. Off-topic, yes. But then so is the photo.
-
Saturday 30th May 2015 22:58 GMT Michael Wojcik
Apple are usually better than this, but there you go...
Unicode processing is complicated. Complicated systems are fragile.
Of course, rewriting the core Unicode processing code to do a better job of handling invalid references - more extensive pointer validation, and catching and unwinding after SIGSEGV within well-defined regions - would make it a lot more robust.
-
-
-
-
Thursday 28th May 2015 08:57 GMT DropBear
Re: And you're telling me it's accidental?
That kind of check is the sort of thing programmers drop off in their sleep without even thinking about it - it's not meant to "harden" anything, it's just a barely-more-than-nothing standard precaution handling pointers returned by some library call you just made; the implicit understanding is that the call will either fail (and therefore return a null pointer, against which you check) or else it will contain a valid address if it succeeds. They say it's not the fall that kills you but the sudden stop at the end; in this case, that sequence of instructions is that sudden stop - but the actual "cause of death" is most likely somewhere ahead, where that pointer acquires a value that's neither invalid nor valid. Either way, one should probably check the _actual_ status code returned by the call instead of relying on "oh and in case of failure also the pointer returned is NULL" (if that is even specified). It's also possible of course that the pointer is not returned by some call but computed right there on the spot - in which case the algorithm computing it is either conceptually buggy or simply making assumptions it should not make...
-
-
Wednesday 27th May 2015 22:08 GMT Anonymous Coward
Shit happens. Hope they patch soon.
It doesn't look particularly hardened, it's just a null pointer check. It looks like we ended up with a reference to some data belonging to an object whose pointer was 0x00 - it's too late to easily check pointers by then.. I don't know anything about objective C object handling though, just a guess.
-
Thursday 28th May 2015 04:10 GMT ThomH
Re: Shit happens. Hope they patch soon.
Speculation elsewhere that this is in part because iOS inherits NextStep's UTF-16 internal encoding and inadvertently truncates one of the 32-bit Arabic characters halfway when trying to add an ellipsis where it calculates it needs to chop the text. The effect of the invalid UTF-16 data (yes, it was validated upon receipt, but then it was broken) is an infinite loop in the decoder, which overspills the end of memory, rather than the buffer ever having been mapped at zero.
Apple doesn't put user-space memory at 0x00 since neither C nor Objective-C has a formalised syntax for optional returns so 0x00 is used for return nil/NULL.
See also: Should UTF-16 be considered harmful? on programmers.stackexchange.com, though I expect most around here won't need to.
-
-
Thursday 28th May 2015 06:48 GMT Sceptic Tank
Restart required
I fail to see how this will cause the sun to go dark and the stars to fall to the earth.
Open message from friend. Phone reboots. Curses uttered. Phone restarts. Remove friend from Christmas card list.
You can probably even block the sender and instruct them to solve their personal issues before you will allow them to contact you again.
-
Thursday 28th May 2015 07:43 GMT EssEll
ERROR
GIVEASH1T module failed to load: closing dooowwwwnnnnnnnnn....
But seriously: I do genuinely admire the quality of the article and the effort to which the author has gone to verify this issue, so kudos for that. The fact that the issue itself is not that big a deal is why I don't really give a stuff.
-
-
-
Thursday 28th May 2015 14:53 GMT Anonymous Coward
userland vs shared library vs kernel code ?
"Well the article does say that the notification screen is a core OS component, so presumably it doesn't run in user space."
I'm not quite following your logic there. Perhaps I misunderstood. Let's simplify it (I don't speak Apple).
We're looking at a bug in something functionally comparable with (but not the same as) (say) printf().
printf() runs in user mode, though it may frequently be in a system-wide shareable library.
Being in a system-wide shareable library just means everyone that uses it gets the same copy. It doesn't necessarily mean the code is part of the kernel and runs in kernel mode.
Does this one crash the whole system (as it would if it was a piece of kernel mode code) or just the app(s) in question?
Incidentally, Android's quite capable of similar silliness. A couple of weeks back I seemed to pick up a corrupt entry in my Android contacts data. Any app that attempted to access the Contacts data would crash when it did so. Bit embarrassing. It seems to be a fairly common problem, and the only fix I could find was a factory reset. I couldn't take a proper backup of my phone because I hadn't yet rooted it (think on that for a moment: I couldn't back up *my* data on *my* phone because the vendor prevents me).
-
Thursday 28th May 2015 14:10 GMT Anonymous Coward
If a user space application is considered essential for the system to provide the required "user experiece", the kernel has to restart it - and sometimes the only way to restart it after a crash may be a reboot, because the kernel may have no way to know the current state, and just restarting it may be dangerous. In this case it's the notification system crashing, it may still crash in user space, but if iOS or whatever think that it's essential, it will reboot.
You can obtain the same behaviour in other operating sytem if you can successfully kill some essential application running in user space, i.e. killing winlogon in Windows.
-
-
-
-
-
This post has been deleted by its author
-
-
Thursday 28th May 2015 14:34 GMT Brewster's Angle Grinder
Re: Exception handling??
All exceptions do is introduce extra hidden code paths. They don't make error handling any easier; arguably they make it more error prone. They are really only useful for exceptional circumstances where the next step is to terminate the module. But they are handy for getting errors out of constructors, provided they adhere to the basic guarantee.
-
Thursday 28th May 2015 15:00 GMT Anonymous Coward
Re: Exception handling??
Exceptions *do* make error handling much easier, and they help to write far more robust code - when properly implemented and used. Also, exceptions ensure an error can't be silently ignored because of a missing check (oh well, unless a lame and lazy programmer uses empty "catch" statements) keeping on running code in a no longer valid application state. Exception can avoid an application termination, if correctly handled, and application state correctly reset.
The FUD about exceptions is just due to the fact the C++ has chosen a poor exception handlling model, that makes code unnecessarily complex (i..e. it gave birth to the growing family of "smart" pointers), because C++ designer aimed at the "mathematical purity" of their model ignoring real code development needs (especially when C libraries needs to be used from C++ code...). Also, any C++ book for beginners makes its best to explain exceptions in the simples and most useless way (throwing string and numbers is not the way you really use exceptions).
There's no really "hidden" code paths - exception handling is clearly defined and shown in code. But if you prefer code littered by "ifs" and "gotos", well, hope it won't ever run on a system of mine...
-
Thursday 28th May 2015 19:53 GMT Brewster's Angle Grinder
Re: Exception handling??
goto
, no never. And definitely not its bastard evil siblinglongjmp
. But that's what an exception effectively is. That's my point: it's the mother ofgotos
.And I agree, a missing error check is a problem. And being able to elide an
if
is nice syntactic sugar. However the error doesn't go away when you delete theif
. What happens when the exception is thrown? I'll presume you're properly using RAII so nothing leaks. But what state is your object in? Will the class invariants be preserved? Had you started writing to a file? Were you in the middle of a database transaction? All those problems are shifted to the catcher which is not well equipped to answer them. And noob programmers---which I'm not implying you are---don't see and think about those things. Deleting theif
doesn't solve the problems. In fact it encourages people not to think about them, which makes the code less robust.It's the "...when properly implemented..." point. They are hard to implement properly. I use them where they really can improve the code. But it's taken a lot of experience to get there. And I seem use badly more often that I see them used well.
But we can agree that the examples are always fucking awful. They tend to be expected errors, too. Running out of core is an exception; a missing file, generally, isn't.
-
Friday 29th May 2015 10:02 GMT Anonymous Coward
Re: Exception handling??
I now understand the reason of crappy applications around. Fear of exceptions - especially because C++ choose RAII which makes code unnecessarily complex (because not all the world is made of C++ classes) compared to leaner implementations, and requires a good knowledge of all the smart pointers family members workings. Developers used to the C way may find it daunting at first.
Sure, worshipper of "C++ is my god and Stroustrup is its prophet" will never admin Stroustrup is wrong... just they should ask themselves why in Boost first and C++11 later smatpointers types started to proliferate.... I believe it's a symptom of a bad original design, it was tried to fix it with auto_ptr, it was implemetend badly, then it was deprecated and a new family of smart pointers was introduced again to try to fix the original sin... same happens in languages trying to adopt the ARC memory model, same issues trying to achive an "automatic" object instance managment.
An exception is not a "goto" - it has a failry more powerful semantic. They ensure a proper stack unwindling. You know why you got into an exception handling block, and a well designed exception hiearchy will let you know what happened and ley handle it at each correct level. Libraries can raise exception and let code written later to catch them, something a goto can't do. Having to check each call, clutters the code. And without gotos or the like, no way to centralize error handling, lot of duplicate code to maintain to clean after an error - which in turn means less robust code that can easily leak or worse.
The catcher may or may be not "well equipped " to handle an exception. It depends on where the catch happens, and what it knows about the attempted operations. A good exception hierarchy and its implementation will let proper exception handling code to perform what it needs to keep the system in a good, known state - preseving invariants.
Rolling back a database transaction is a classic example where a single exception handler can easily return the system to a stable state, inform the user of what happened, and if needed, retry the operation, even if the transaction spans several different SQL statements.
Sure, if you let exceptions escape several calls, the outermost exception handler can do very little because it knows very little - one of the rules about exception handling is if you expect an exception may occur, you have to handle it the closer you can from its "throw" point. But an exception will anyway reach an exception handler, and that alone will make code more robust - even if it means your application will be terminated before it can create more havoc, if the application happily continues in an unstable state. Any good handler will at least log what exception occurred and where (although sometimes the root cause may be elsewhere), and maybe even some useful diagnostic informations.
Like it or not, it's very difficult and error prone to write OO applications without a proper extensive use of exceptions and exceptions handler.
In this case of course terminating the notifier process is of no help, because it triggers a reboot.. Low level exceptions like a segfault are usually hard to handle - but even in that case maybe tha application could have handled it in a more graceful way.
-
-
-
-
Thursday 28th May 2015 20:12 GMT Brewster's Angle Grinder
@d3vy
Talking about EXCEPTION handlers: "really only useful for EXCEPTIONAL circumstances"
No shit.
You'd think, wouldn't you. But here's an example. Lets ask the user whether to proceed with this operation. If they say, "yes", the code returns. If they say, "no", it throws an exception.
Now I'm not going to hold truly lousy code against exceptions. But that's why I make the point that the name is a clue about how to use them.
-
Friday 26th June 2015 09:25 GMT d3vy
Re: @d3vy
@Brewster's angle grinder.
"But here's an example. Lets ask the user whether to proceed with this operation. If they say, "yes", the code returns. If they say, "no", it throws an exception."
If that's what you are doing you are using exception handlers wrong, you shouldn't be throwing an exception on some possibly expected user input - you're effectively using exception handlers as part of your business logic...
Handle your user input normally and leave the exception handlers to pick up the pieces when all else fails...
-
-
-
-
-
Friday 29th May 2015 13:28 GMT Colin Wilson 2
Re: Exception handling??
Ok here's the clue:
>> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
An unhandled exception! Any reasonable modern language would convert this OS exception to an exception that it can handle - the same way as it would handle any other natively thrown exceptions.
As far as the ApplyGlyphFeatureTags function goes - the original programmer *should* have tested the pointer better - rather than just comparing it to nil. In the old days on Windows we used to use IsBadReadPtr to do this - but that's now seriously deprecated, and according to MSDN you're meant to use structured exception handling instead.
In this case, handling the exception simply by logging it, and applying some default glyph feature tag sounds like a reasonable approach.
>> If you think this problem has anything to do with exception handling, then you really, really don't know what you are talking about.
meh
-
-
-
Thursday 28th May 2015 12:59 GMT Anonymous Coward
Warning!! the Evil TXT that reboots iphones also destroys the email app!
Warning to all - sending the evil txt as an email message renders the recipients iphone email app useless!! Even with the device unlocked once the email has been opened the email app will crash out and as long as the message is in the in box you will not be able to open the email app, just crashes out or opens a "no message found here" screen with a back icon top left, tapping this will again crash the email app.
Also worth noting is the senders email app will be affected as well with the "sent" email folder crashing out the device every time it is tapped.
There is no recovery from this, restoring the device is the only solution I have found, even deleting the email account and setting up from fresh doesn't guarantee recovery if the evil text is in the subject line!
This is far more serious than the txt message reboot as the phone will still run the message app after the reboot.
Apple - you need to sort this asap!!
-
-
Thursday 28th May 2015 15:42 GMT Anonymous Coward
Re: "She's holding a phone"
"topical only because she's holding a phone. "
Don't know who does what testing at El Reg, but on my Firefox the phone in question isn't actually visible, which made the whole thing rather strange.
Not quite like an Acer netbook article picture (was that the one?) but along similar lines.
-
Thursday 28th May 2015 15:00 GMT Nick L
Amiga coders lecacy, perhaps?
The one single address you could be guaranteed of finding something useful in the Amiga memory map was at 0x00000004, and in it would be the address of exec.library. Offsets then provided the various function calls...
Maybe old habits die hard ;-) . Don't bother - I'm already reaching for my coat...
-
Friday 29th May 2015 04:39 GMT nh525
Crashes 'The Register' app on Windows 8 too
It is quite ironic, but if I try to read this article about the 75 character string using the Windows 8 app called 'The Register' (apparently an official app developed by The Register), the app crashes!!!
It's a repeatable crash too, not a fluke.
-
Saturday 30th May 2015 05:10 GMT TimChuma
Didn't there also used to be one for modems?
Was a character string some not nice people would post to newsgroups that would hang up a certain brand of modem.
Also Web-TV had the infamous "wtv-client:hangup-phone" command.
Telstra also unloaded a whole heap of end of line ADSL modems that would disconnect on Myspace and Facebook for some reason.