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)
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 …
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.
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.
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.
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.
> 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?
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):
See also e.g.
"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."
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.
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.
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...
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.
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.
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.
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.