A Text Message Can Crash An iPhone and Force It To Reboot

DavidGilbert99 writes with news that a bug in iOS has made it so anyone can crash an iPhone by simply sending it a text message containing certain characters. "When the text message is displayed by a banner alert or notification on the lockscreen, the system attempts to abbreviate the text with an ellipsis. If the ellipsis is placed in the middle of a set of non-Latin script characters, including Arabic, Marathi and Chinese, it causes the system to crash and the phone to reboot." The text string is specific enough that it's unlikely to happen by accident, and users can disable text notification banners to protect themselves from being affected. However, if a user receives the crash-inducing text, they won't be able to access the Messages app without causing another crash. A similar bug crashed applications in OS X a few years ago.

Comments

Happy Wednesday from The Golden Girls!

[Anonymous Coward]

Thank you for being a friend
Traveled down the road and back again
Your heart is true, you're a pal and a cosmonaut.

And if you threw a party
Invited everyone you knew
You would see the biggest gift would be from me
And the card attached would say, thank you for being a friend.

Thanks guardian

[NotInHere]

For enabling video inside html without flash. Welcome to the modern web!

NO MORE SJW STORIES, DICE

[Anonymous Coward]

Seriously, stop it. You're pissing off your long-term readers and they won't be replaced.

Re:NO MORE SJW STORIES, DICE

[Anonymous Coward]

SJW: had to look it up myself.

Lol

[penguinoid]

This is why you always sanitize user input.

Re:Lol

[Anonymous Coward]

it's a parsing bug, what difference would sanitizing user input make...

Re:Lol

[omnichad]

Sanitize a language people use for actual communication? The text shouldn't have to change. This is a case of bad coding and nothing more.

Re:Lol

[penguinoid]

it's a parsing bug, what difference would sanitizing user input make...

Well if your parser can't handle something, it should sanitize input before parsing it. Eg if you use special characters internally to do something, make sure your user input doesn't have those characters in that order unless you want the user to be doing that thing.

Even if you just add something, eg "\ " if spaces do special things, and a user input "\" can be stored internally as "\\".

Re:Lol

[penguinoid]

It wouldn't be a parsing bug if the parser sanitized its input.

Re:Lol

[Anonymous Coward]

So if you know you have a bug, you should fix the bug.

You're a genius, man. Apple should hire you, assuming Microsoft or Google doesn't hire you first.

Re:Lol

[gstoddart]

Even if you just add something, eg "\ " if spaces do special things, and a user input "\" can be stored internally as "\\".

Eccch ... and suddenly I'm reminded of things where you need to escape the escape of the escaping of the escape so that it doesn't keel over.

And then it become "Yo, Dawg, I hear you like escape characters".

It can pretty quickly devolve into really annoying things, especially when something else wants to read it, or when humans have to. I've seen things with things which turned into nightmares of "\\\\\\".

Re:Lol

[Anonymous Coward]

i find rsync seems to require quadruple escaped spaces even in quoted urls

Re:Lol

[tomxor]

And to sanitise the input what process would you need to perform on the input? is it called parsing? and would you need to sanitise the sanitisers parser...

Re:Lol

[tomxor]

Just to clarify, that came out rather rhetorically, it's a genuine question, where does the parsing stop, how do you sanitise without having to protect the sanitising parser too?

Re:Lol

[Impy the Impiuos Imp]

Not necessarily. You could use AI to reject things if it gets scared.

Re:Lol

[geminidomino]

Sanitize a language people use for actual communication?

Yeah, not so much. It's bad coding because of a lack of sanitizing.

Re: Lol

[Anonymous Coward]

It's not a special character that needs escaping. It's a character that needs multiple bytes to specify the code point. The parser just isn't handling the fact that you can't just crop a character mid code point - it's operating at the byte level when it should be operating at the code point level during a crop operation.

Re:Lol

[omnichad]

Just because it's unlikely with a real text string doesn't mean that any of the text is invalid for a message. The text string should still not need to be changed. The bug only affects notifications, and it's clear that the text can be displayed just fine in conversation view.

This is almost certainly due to splitting multibyte characters on sub-character boundaries. That's a design problem, not a sanitizing problem.

Re:Lol

[penguinoid]

And to sanitise the input what process would you need to perform on the input? is it called parsing? and would you need to sanitise the sanitisers parser...

Yes, you could do it with a simpler parser eg delete all non-latin characters from user input because the people who designed our parser were noobs. Or go on a case-by-case basis, this character is used internally for such and such, if user input has this character then put an escape character in front of it or whatever.

For example, a fun gag on a new Linux user is to create a file called " -rf" and ask them to delete it via a command line. If they naively type "rm -rf" then it gets parsed as an option for the rm command rather than a filename. There are, of course, several ways to deal with that sort of thing which involve sanitizing the filename. I suppose it might be even more fun to create a file or directory named " --help & rm -rf $HOME/*". Point being that if you use something internally to execute commands, you'd better be damned sure that user input can't bypass your parser and execute arbitrary commands. It's not an easy thing and if you can't handle it just reject the input that's too complicated for you (eg forbid interesting characters in filenames).

Re:Lol

[Z00L00K]

And it's nothing new that a "text" message can crash a phone. It can happen on many phones, and you can send OTA messages for configuration to really screw up the phone for someone.

Re:Lol

[Anonymous Coward]

It affects the triggering of the bug I guess?
TO BE SVRE I VVILL REVERT TO CLASSICAL ROMAN ALPHABET

MATER PARA PASTAM
PERVENTURUM SUM

UBI ES
DIXISTI HOC ESSE

Filter error error: all caps is not yelling in classical latin. Or they always yelled which might explain they scared off so many.

Re:Lol

[LynnwoodRooster]

Because writing in Chinese or Arabic is something to be sanitized? According to the summary (no, I didn't RTFA - this is /. after all), having a long enough message so that the ellipsis happens between those ISO-extended characters causes the problem. Sucks to be a user who writes/communicates in other languages!

Re:Lol

[cfalcon]

Yes, it is. Any input that will crash your library needs to be sanitized. You need to truncate the message on display, at the bad character. That doesn't mean you change the source message or render whatever folks use it to communicate unable to do that- you as the fucking programmer SANITIZE YOUR INPUT, because otherwise, you fuck the user.

Re:Lol

[BronsCon]

If you need to truncate after X characters, you don't just truncate after X*8 bits. Sure, that works if you're using an 8-bit encoding, but we're talking about multi-language script, variable-length encodings like UTF-8 here. You truncate after X code points when dealing with those, it's not a fixed number of bytes, and sanitizing your input (which I'm sure they're already doing) does not protect you against cutting a multi-byte character in half if you're counting bytes for truncation.

Re:Lol

[RyuuzakiTetsuya]

Problem with this case is that people who don't speak languages that use latin characters are going to be pissed that they can't get texts in their language.

The real bigger problem is that Unicode is hard, and it's probably some weird unchecked buffer overflow or something stupid. What's strange is that when another text is sent, the problem case solves itself and the messaging app becomes usable again.

Re: Lol

[laie_techie]

It's not a special character that needs escaping. It's a character that needs multiple bytes to specify the code point. The parser just isn't handling the fact that you can't just crop a character mid code point - it's operating at the byte level when it should be operating at the code point level during a crop operation.

Too bad I don't have mod points because you are absolutely correct! As more and more code points are defined, the number of bytes needed to represent characters increases. Their abbreviation mechanism should at least recognize surrogate pairs and combining characters.

Re:Lol

[flink]

What's strange is that when another text is sent, the problem case solves itself and the messaging app becomes usable again.

It's not that weird. The IOS messaging app shows messages organized by sender with the most recent message summarized under each sender's name. If a message is being cropped incorrectly and causing the crash, then wh3n another message comes in from that sender, the new message will replace the problematic one in the summary.

Re: Lol

[psyclone]

And since some characters have different lengths, even counting characters might not be good enough. (Can't use max_bytes=80, nor max_chars=40.)

The message could be "displayed" in memory with the chosen font and size to calculate it's length, then truncate the string in character mode to fit within the limited area.

Re:Lol

[BasilBrush]

You guys that are talking about sanitizing the input don't understand the bug. There is absolutely nothing wrong with the input. This is not injection of escape codes. It's valid text in a different language, and changing at at input would constitute a second defect. The problem is connected to the eliding algorithm.

And in fact the argument where in the code the problem lies is not that helpful anyway. The bigger problem is that there wasn't a test case for it.

Re:Lol

[Anonymous Coward]

> case of bad coding

How is it a case of bad coding when Apple confirmed this is a hoax. It is not true. I don't understand why you tabloid press Republicans can't understand that. You're so stupid. It doesn't work. I tried the claimed exploit, and I proved it a lie. It is a lie. You and the rest of your Republican kind need to shutup and go to hell.

Re:Lol

[Guy Harris]

Yes, it is. Any input that will crash your library needs to be sanitized. You need to truncate the message on display, at the bad character.

Where has it ever been stated that the message, as sent to the phone, contains a bad character? Everything I've read indicates that the problem is that the code that's displaying the message is inserting an ellipsis in the middle of a perfectly valid character, making the resulting string invalid.

That's not un-sanitized input, it's bad output, from buggy code.

Re:Lol

[Anonymous Coward]

Yes, you could do it with a simpler parser

So you need a parser to sanitize the input for your parser...to put a parser in your parser but who will parse the input for the parser that goes in the parser?

It's a bug in the parser, they don't need to do anything with the input, just fix the bug with the parser.

Re:Lol

[exomondo]

It wouldn't be a parsing bug if the parser sanitized its input.

And what exactly do you mean by 'sanitized its input' in this case? Since we're talking about truncating a string of non-latin character sets with variable-length values for the codepoints the problem is with the parser not correctly handling this and assuming fixed length codepoint values. Changing the input is most definitely the wrong way to handle a bug like this.

Re:Lol

[penguinoid]

There's no law that says they can't pad the variable length input to fixed length, then do their "we can only handle fixed length" parsing, then remove the padding. Or that they can't check for variable length and throw a we-were-too-lazy-to-deal-with-this exception. If you make unguaranteed assumptions about user input then you deserve what you get.

Re:Lol

[exomondo]

There's no law that says they can't pad the variable length input to fixed length

I'm not sure you quite understand the problem, it's not the input length, it is the encoding of each of the characters. So are you suggesting turning all single-byte encoded characters into multi-byte encoding of some arbitrary maximum length? If you can already identify the problem at this level then you would just do that in the parser that is truncating the string.

Re: Lol

[spitzak]

No, the problem is code that pretends that illegal UTF-8 sequences magically don't exist!

For some reason UTF-8 turns otherwise intelligent programmers into complete morons. Here is another example from Apple. Let me state some rules about how to deal with UTF-8:

1. Stop thinking about "characters"!!!! This is a byte stream. The ONLY reason to think about a "character" is because you are DRAWING it on a display designed for a human to read, and humans do think about "characters". All other software either does not care, or is concerned with far more complex patterns (such as regexp and editors that deal with words and sentences), these second ones are not helped at all by an intermediate translation.

2. It is TRIVIAL to detect that the byte sequence you are looking at is not a valid UTF-8 character. In this case draw a replacement for exactly ONE byte and then try the next byte to see if it is a valid sequence. Do not skip more. There must be one error per byte so that the maximum number of good characters is preserved and so that a sequence with errors can be parsed bidirectionally without looking more than a few bytes ahead, and so that it is possible to search for error patterns. It also means there are only 128 different errors, not millions.

3. NEVER "translate to Unicode" (ie UTF-16) because this will be a lossy conversion of these invalid sequences and thus you have not preserved the original data. I'm sorry but Microsoft really screwed us here. Best recommendation is to write a wrapper around the filesystem calls and translate from UTF-8 to UTF-16 at the last moment, using U+DCxx as a translation for the error bytes (this is lossy but filenames already are, due to case independence, Apple's normalization, and even on Unix where "./foo" and "foo" are the same file).

This is blatantly obvious if you substitute "words" for "characters" and imagine how you would write a program to deal with text strings. Words are also composed of multiple bytes in a row. For some reason nobody seems to crash on misspelled words, and they manage to concatenate and split strings and make whole file systems and diff programs and all kinds of other fancy text manipulation without having to translate the text so that each word is a fixed-sized integer. Amazing!

Re:Lol

[spitzak]

No you don't. You are demonstrating the typical moronic attempts to deal with UTF-8.

Here is how you do it:

Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there.

BUT BUT BUT I'm sure you are sputtering about how this won't give you exactly X "characters". NOBODY F**KING CARES!!!! If you want the string to "fit" you should be *measuring* it, not saying stuff that has not been true on computers since the 1950's about "N characters fit". I bet you think a combining letter and accent should count as 2, huh?

And your display function should not crash because it was given a string with an error in it! Even if you stupidly inserted the ellipsis all it should do is draw a few error indicators before the ellipsis.

Re:Lol

[neoform]

Yes, you could do it with a simpler parser eg delete all non-latin characters from user input because the people who designed our parser were noobs.

Nice, fuck everyone who doesn't speak English, amirite?

Re:Lol

[Anonymous Coward]

it's a parsing bug, what difference would sanitizing user input make...

It's a Unicode string handling bug. Specifically Apple's code is shit at handling Unicode Combining Characters (http://en.wikipedia.org/wiki/Unicode_equivalence#Combining_and_precomposed_characters) and when it truncates the string in the middle of a Combining Character to add the ellipsis it causes the GUI renderer to crash. You'd have thought they would have learned their lesson when this happened on OS X with Unicode file names.

Re:Lol

[penguinoid]

It's the Slashdot way.

Re: Lol

[Guy Harris]

No, the problem is code that pretends that illegal UTF-8 sequences magically don't exist!

Where's the illegal UTF-8 sequence in the message? Is the actual octet sequence in the message different from what's in this Slashdot posting (once converted to a sequence of octets), which contains no invalid UTF-8 sequences (yes, I went through them all by hand)?

Re:Lol

[cfalcon]

It's a bad character if the library you call will fuck it up. That's what makes it bad. Once you overwrite part of some multibyte character IT IS A BAD CHARACTER!!!

Re:Lol

[Guy Harris]

Just because it's unlikely with a real text string doesn't mean that any of the text is invalid for a message. The text string should still not need to be changed. The bug only affects notifications, and it's clear that the text can be displayed just fine in conversation view.

This is almost certainly due to splitting multibyte characters on sub-character boundaries.

Or mishandling combining characters; the screenshot geminidomino provided shows several combining characters, as indicated by the dotted-line circles in some of the glyphs (and I suspect some of the marks above the Arabic characters come from combining characters as well).

Re:Lol

[cfalcon]

This only works for UTF-8, and theoretically fails with the older type of UTF-8 (when you could have up to 6 bytes, by spec).

So you probably will have to go through it character by character, not byte by byte, exactly as Brons said. If you go N bytes into the string, and the string was just a ton of kanji, then you might truncate a VERY short message indeed- if you go looking 40 bytes in, you could be looking at a 10 character string or something for no reason, when your display would happily fit 40.

Re:Lol

[cfalcon]

The string doesn't just need funny characters in it, it needs them at a precise position (and apparently not just any character will break, so it needs to have a particular expansion in whatever they used to encode their unicode). A test case would have solved it, but it doesn't sound like a reasonable test case to expect.

And yes, if you call a library that does some buggy truncation, you need to guard it on input.

Re:Lol

[Guy Harris]

No you don't. You are demonstrating the typical moronic attempts to deal with UTF-8.

Here is how you do it:

Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there.

As long as you're not splitting a sequence of multiple characters (multiple characters, some of which might be encoded in multiple bytes with UTF-8) some of which are combining characters. Don't split a character from a combining character following it. Splitting a sequence like that can introduce more rendering errors into the string than are already there.

(I suspect that's what the problem is in this bug, given that there are several combining characters in the string as shown in various places.)

(And you don't want to split it after N characters, if the goal is to limit the display length of the string you're displaying, as not all characters are the same width - and, of course, a base character followed by several combining characters might just have the width of the base character.)

Re:Lol

[Guy Harris]

(And you don't want to split it after N characters, if the goal is to limit the display length of the string you're displaying, as not all characters are the same width - and, of course, a base character followed by several combining characters might just have the width of the base character.)

...and, of course, when you're figuring out where to truncate, remember that some characters go right-to-left, not left-to-right - the string has both Roman-alphabet (left-to-right) and Arabic-alphabet (right-to-left) characters.

Re: Lol

[cfalcon]

In this case, the illegal UTF-8 sequence is the string after you have blown part of its funny foreign squiggle. He's saying that thing you call with your newly minted mangled string shouldn't fail.

Which is one way to solve it. I would argue, if the thing you calls mangles strings, sanitize its inputs so it doesn't get a string with a bad character (a unicode character of whatever format it uses internally, post-mangle). Ideally, you would never go off to lala land, no matter your input- even if the guy upstream mangled it to be invalid.

Re:Lol

[BasilBrush]

You demonstrate exactly what I'm talking about.

You're assuming the nature of the bug. And when writing an operating system you can almost always fix the real bug, or get it fixed, not simply guard a known bug.

And you don't know you need to guard it on input unless you have a breaking test case.

The argument that it's an unlikely case to have written misses out that tests are not just random, but explore edge cases.

Re:Lol

[dave420]

But the character is not bad until Apple attempts to display it. If the library is so fucked up it doesn't understand multibyte strings, then the library is broken for this purpose.

Re: Lol

[spitzak]

From that description it does sound like the string is still valid. However if the display is crashing on a certain sequence containing an ellipsis, I am not clear why you can't construct that string directly, rather than rely on the insertion of the ellipsis.

It does sound like they maybe rely on "sanitizing" but of a far more complex scheme that I was aware of. This is still wrong, maybe far worse, as they are detecting and rejecting patterns containing ellipsis and some other character, that is INSANE!!!. Any such work should be delayed until the VERY LAST moment. In this case their glyph layout should simply not crash on any possible arrangement of bytes or words in the incoming string. This is very much the same stupidity that I was ranting about for UTF-8. Nobody used to crash because you put mis-spelled words in your text and tried to print it. Apply the same logic to UTF-8 and Unicode. It is not hard and it seems really obvious, but for some reason Unicode turns some otherwise really smart programmers into total idiots.

Re: Lol

[spitzak]

What I recommend is that anything that takes text input assume that the input could be any possible arrangement of the data units (ie any stream of bytes for UTF-8, and any stream of 16-bit words for UTF-16).

Don't "sanitize", because that is simply a step that produces a new string and feeds it to the next step. You have not fixed anything because an error in "sanitizing" will still crash (as quite a few posters here have tried to point out). The work must be done at the point that the data is translated to something other than a string. In this case is is the glyph layout in their rendering. That code should assume the input is ANY possible arrangement. Ideally it should draw something visible showing that there was an error and place it between glyphs so that it is clear what location in the string the error was.

Relying on previous steps only producing valid data is not only unsafe (as this bug shows) but also wasteful because of the scanning of the data. And it is either lossy (because errors are translated to a valid sequence and thus two different inputs map to the same result) or a denial of service (due to an exception being thrown and the loss of further processing). Unfortunately handling that is completely obvious for most data is somehow confusing to programmers when they are presented with Unicode.

Re:Lol

[spitzak]

No you are wrong. What I propose does not fail any worse than what I think you are proposing, which is "search N Unicode code units forward and put the ellipsis there".

My scheme will not add an error. Either it will find the start of a character, or if there is enough trailing continuation bytes it will know that the string ends with an error and add the ellipsis after that (thus not adding an error and not removing it). As other posters here point out there is absolutely no need to count Unicode code points as it has nothing to do with how many "characters" there are.

A better scheme would be to actually measure the rendered string to see if it fits, and then do a weighted binary search for the correct location to place an ellipsis to get the longest string containing an ellipsis that fits. This still assumes that shorter strings render in a shorter area, which is still not true, but true enough that I think this may work.

Re: Lol

[cfalcon]

So you are saying "fix the library". I am saying "sanitize input for library".

Both work, but I would argue that sanitizing for the library is usually a lot less problems.

Re:Lol

[cfalcon]

"No you are wrong."

Pretty sure I'm not. We could just claim that way back and forth, but lets go over this:

Here's what you said:

"Go X bytes into the string. If that byte is a continuation byte, back up. Back up a maximum of 3 times. This will find a truncation point that will not introduce more errors into the string than are already there."

Here's what I said:

"This only works for UTF-8, and theoretically fails with the older type of UTF-8 (when you could have up to 6 bytes, by spec). So you probably will have to go through it character by character, not byte by byte, exactly as Brons said."

So pretend you have a 12 character display. Your method, for UTF-8:
> Checks to see if the input is 12 or less bytes, and displays it fine (this works)
> If not, it goes to that 12th byte, then checks it to see if it is a continuation byte (a byte which, when ANDed with 0xC0, is equal to 0x80)
> If it is a continuation byte, and we haven't seen three in a row yet, increment the number seen, and back up one byte.
> If we found a non-continuation byte or we have seen three continuation bytes in a row, then what we are looking at must be a starter byte.
> Write four bytes beginning with the overwriting the starter byte: 0xE2 0x80 0xA6 0x00 (ellipsis, null character)

With this method, you definitely could have left some garbage to the right of the null (if that null ate anything to the right of that), but that's ok because the null ends the stream (if it doesn't, you'll need to pad some more nulls). An alternate method that doesn't stamp the null is vastly worse, as if you were finding a two byte character to stamp the three byte elipsis into, you would have eaten the first byte of the NEXT multibyte sequence, leaving you with an illegal data stream, and no null to tell the next guy to stop.

But, anyway, this one works- like I said- but I claimed that it had two problems- "only for UTF-8" and "results in a VERY short message for some inputs". It also trivially fails for the pre-RFC-3629 UTF-8 standard, but I guess we are ok with that (that version can have up to five continuation bytes).

If your message was, lets say, 8 of the "smiling face with smiling eyes" emojis:
http://www.fileformat.info/inf...
(or equivalent 4 byte characters)

The algorithm of "go 12 bytes in" will skip past the first two entire "0xF0 0x9F 0x98 0x8A" sequences, landing on the "0x8A" one of the last one. The algorithm will detect that this is a continuation byte, and back up the max times (through the 0x98, and 0x9F), landing on (and stamping over) the 0xF0 initial byte. But this means that your output message is:

(happy face)(happy face)(ellipsis)

You took a 12 character display AND LIMITED IT TO TWO CHARACTERS. When in fact, the original message would have fit, if you did what Brons said.

Because you searched in N bytes, instead of doing what Brons said (and that you even fucking called "MORONIC"), you fucked your hypothetical user AND insulted the guy with the right answer at the meeting (or were at least rude to him, brusque, or superior without cause).

But, lets continue.

I also claimed that this "only works for UTF-8". This is pretty trivially true- you explicitly refer to "continuation bytes", which are definitely not present in all encoding methods. UTF-16 is either one or two 16-bit words, and these are not "continuation bytes". With such an input, you would go 2*N forward, and then check for if the word sequence found was whichever surrogate comes first in your byte ordering (ex, you might be looking to see if it is a high surrogate, and therefore the start of a character, if your byte stream has that ordering), and if not, back up one word to find the guaranteed start of character, and then stamp over that with your elipsis. This is the general equivalent of your UTF-8 solution, but you still dramatically shorten what your user can

Re:Lol

[Guy Harris]

It's a bad character if the library you call will fuck it up. That's what makes it bad.

If it's a valid character in the character set being used, and a valid representation of the character in the encoding being used for that character set, then it is by definition not a bad character; if the library you call fucks it up, the library is bad.

The fuckup isn't the lack of "sanitization" of perfectly clean strings, the fuckup is the library's inability to handle those strings.

Once you overwrite part of some multibyte character IT IS A BAD CHARACTER!!!

Then the fuckup is the overwriting of part of that character - or the overwriting of a combining character following a base character, or not handling bi-directionality correctly when figuring out where to and how to truncate the string. No, the rendering code shouldn't crash when handed the fucked-up string, but it should report the underlying bug somehow (in a way that gets back to the developer), so that bug doesn't go completely unnoticed.

Re: Lol

[Guy Harris]

In this case, the illegal UTF-8 sequence is the string after you have blown part of its funny foreign squiggle.

Where has it been proven that the bug is the trashing of a UTF-8 sequence?

First of all, Apple tends to use UTF-16 in the higher-level frameworks, e.g. that's how CFString/NSString work internally.

Second of all, processing entire characters rather than bytes is something I suspect Apple got right fairly early in the process. I suspect the problem is either that 1) when truncating the message for display, they're not processing entire graphemes, they're processing entire characters or 2) they're not taking bidirectionality into account or 3) they're not handling a combination of both issues.

He's saying that thing you call with your newly minted mangled string shouldn't fail.

Which is one way to solve it.

There are multiple things here that should be fixed. That's one of them - the renderer shouldn't crash if handed a bad string, it should fail more softly, e.g. put in a REPLACEMENT CHARACTER for all bad sequences and, if possible, log the error in a way that indicates that routine XXX has handed a bad character sequence to it.

I would argue, if the thing you calls mangles strings, sanitize its inputs so it doesn't get a string with a bad character (a unicode character of whatever format it uses internally, post-mangle).

And I would argue (all the way to the heat death of the universe) that, if you know that the thing you call mangles strings, and if it's produced by somebody else working on the same OS, you get it fixed so that it doesn't do that; you don't mangle user input (which includes text messages from other users) in released software, unless you don't have time to fix the underlying problem for the release.

Re:Lol

[spitzak]

Do you really think 12 happy faces fit in the same space as 12 letter 'i'?

This is why it is pointless to do such counting.

And what you propose would split betwen a letter and a combining accent, so it really isn't any better for trashing strings.

Basically as soon as the words "N characters" come out of your mouth you are wrong. All your description just does that for many paragraphs. Don't feel too bad however as there are many many other people, including ones working for Apple, who are wrong as well.

PS: the surrogate order does not depend on they byte order in UTF-16. You might want to check what you are doing if you thought that.

Re: Lol

[Guy Harris]

So you are saying "fix the library". I am saying "sanitize input for library".

Both work, but I would argue that sanitizing for the library is usually a lot less problems.

"Programming for international environments is hard, let's go shopping!"

I would argue that you have perhaps not considered all the possible problems and have thus perhaps miscounted the problems with "work around a broken library by transforming perfectly legitimate Unicode character sequences into sequences that might not represent what the person sending the message intended", that being the correct description of the second approach to this problem in the list above.

Yeah, correctly truncating a message that could be an arbitrary sequence of text in multiple languages with combining character sequences and bidirectional text isn't easy, but, well, if you want to be thought of as a company that makes stuff that "just works", you'd better figure out how to make that complicated process "just work".

Maybe iOS 8.3.1 needs to have a quick fix of some sort, but iOS 10, if not iOS 9, should fix the truncation code.

Re: Lol

[Guy Harris]

From that description it does sound like the string is still valid. However if the display is crashing on a certain sequence containing an ellipsis, I am not clear why you can't construct that string directly, rather than rely on the insertion of the ellipsis.

Yup.

It does sound like they maybe rely on "sanitizing" but of a far more complex scheme that I was aware of.

Not to me, unless by "sanitizing" you mean "shortening so it'll fit in Notification Center".

This is still wrong, maybe far worse, as they are detecting and rejecting patterns containing ellipsis and some other character

I've seen nothing to indicate that they're doing anything specific with ellipses, other than "sticking them in at the point of truncation to let the user know that the full message isn't being displayed".

About all I'd assume is that certain sequences of characters are not being handled correctly by some part of Core Text; perhaps it's assuming, explicitly or implicitly, that those sequences "can't happen" and, instead of drawing them, crashing, perhaps in an assert.

In this case their glyph layout should simply not crash on any possible arrangement of bytes or words in the incoming string.

Correct.

It is not hard and it seems really obvious, but for some reason Unicode turns some otherwise really smart programmers into total idiots.

There's a lot to know, and people might not be aware of all of it and all the issues involved.

Re: Lol

[Guy Harris]

And since some characters have different lengths, even counting characters might not be good enough.

And some characters might not always have a length and the length of some characters isn't "how much do you move to the right", it's "how much do you move to the left", so truncating is tricky.

Re:Lol

[cfalcon]

"Do you really think 12 happy faces fit in the same space as 12 letter 'i'?"

Holy fucking shit, who cares? If this was done by LETTER WIDTH, we wouldn't see the problem- it would be converted to a graphic and pruned that way. Many characters are much SMALLER. M is bigger than i, etc. You are just so fucking wrong you are trying to fight. It was never about font display.

I found the smiley that is 4 bytes. It is as wide as a capital W, to within pixels... on this PC.

Assuming that a character that is four bytes long is four times as wide as a one byte character is just simply retarded, and you would NEVER have said it if you weren't trying so hard to be correct.

"And what you propose would split betwen a letter and a combining accent"

What YOU propose would do that too!! If your method landed on a the accent mark, it would turn it into ellipsis, stripping the circumflex or whatever from the letter. The fix for either would be trivial- you check the next character to see if it is a combining whatever, and then go to the one after that. Either way, you need to parse the goddamned string.

"Basically as soon as the words "N characters" come out of your mouth you are wrong."

NO FUCKING JUST NO HOLY FUCKING SHIT

Your thing works with a specific encoding, and makes some messages dramatically shorter than others. Doing it by characters instead of byte length isn't wrong, it's THE ONLY ACTUALLY CORRECT WAY!!!!!

UTF16:
You're correct about the surrogate order, and thank you. I'm not working with UTF-16 atm.

Re: Lol

[Guy Harris]

It is not hard and it seems really obvious, but for some reason Unicode turns some otherwise really smart programmers into total idiots.

There's a lot to know, and people might not be aware of all of it and all the issues involved.

...and "really smart" might actually be a handicap if it means "I'm smart, I know how to do this, it's easy!", and not bother to Read The Fine Manual, whereas somebody less smart might find Unicode scary and actually bother to RTFM.

Re:Lol

[Guy Harris]

There's no law that says they can't pad the variable length input to fixed length

I'm not sure you quite understand the problem, it's not the input length, it is the encoding of each of the characters. So are you suggesting turning all single-byte encoded characters into multi-byte encoding of some arbitrary maximum length? If you can already identify the problem at this level then you would just do that in the parser that is truncating the string.

...and then make sure you're handling combining character sequences and bidirectional text correctly.

Re:Lol

[spitzak]

Holy fucking shit, who cares? If this was done by LETTER WIDTH, we wouldn't see the problem-

EXACTLY! That is why you do not want "N characters". I don't understand what your problem is here.

It is true that for this example most programmers would scan from the start, finding the longest string that fits with an ellipsis at the end.

What I was trying to point out is that if you want to be clever, you can guess as to an insertion point. But 11 bytes is just as good of a guess as 11 "characters" and since 11 characters requires scanning you are not saving any time.

You are perfectly correct that after you stick the ellipsis in there you need to test to see if the rendering fits and perhaps try another guess. The idea is that you will do fewer measurements, but that such insertion can be done using byte offsets, and "N characters" is a useless concept that never enters into it.

I am amazed

[fustakrakich]

Simple text can execute a program?

Re:I am amazed

[Anonymous Coward]

Unicode, no doubt. It's not really all that simple.

Re:I am amazed

[phishybongwaters]

Yes, technically there is a way to execute phone specific code with specially crafted text messages. This is not doing that. It's not executing a program. The system is trying to abbreviate the contents of the message to display in a notification banner or on the lock screen through a widget (or whatever apple calls them). The system is doing something it's designed to do, but due to lack of foresight or just shoddy development, they never bothered testing this with special characters. And some clown obviously found the bug. This is actually pretty big. So in the past few months I've learned about 3 important issues with IOS devices, even those running the current release: 1)They are still including a chinese root cert that has been delisted for handing out forged google certs, and who knows what else. 2)A specially crafted access point being in range of your IOS device can cause it to become unstable and eventually crash, even if you have not connected to that network 3)A specially crafted text message can crash your phone upon receiving it. Lets be clear, I'm not saying Android doesn't have some major issues as well, so don't try to fanboy me. But this is not what I expect from Apple. This is just bad. Lack of sanity testing? Keeping their users at risk seemingly just to say FU to google?

Re:I am amazed

[Anonymous Coward]

no simple text can be parsed by a program are you still amazed?

Re:I am amazed

[NotInHere]

Yes, there are special types of SMS the carrier can use to send commands to your baseband chip.

Re:I am amazed

[mi]

Yes, technically there is a way to execute phone specific code with specially crafted text messages. This is not doing that. It's not executing a program.

Generally, if a carefully-crafted input can cause your application to crash, a similarly-crafted data may be able to exploit the same bug and cause an execution of malicious code. If — as is usually the case — the crash is due to buffer overflow and I can stomp over your app's memory, I may be able to place my code in the right place and it will be executed as part of the app...

There are ways to mitigate that — such as by declaring data-parts of memory non-executable — but the earlier successful exploits of buffer overflow in the image-parsing code suggest, Apple is not using this.

But this is not what I expect from Apple. This is just bad. Lack of sanity testing?

Security — as any good work in general — is hard. Disproportionally harder than the merely Ok work. The real measure is not the number of bugs, really, but the speed of the fixes, once the problems are discovered. Unfortunately, Apple seems to be slow at that too...

Re:I am amazed

[Rei]

I'd be willing to bet that the unicode library they were using was UTF-16 . Either that or they were handling unicode in a straight binary string with something homebrewed. Both are horribly dangerous - the latter for obvious reasons, but the former in particular because it makes it easy to code something that "just works" for 99,99% of cases, but those rare 0,01% side cases involving 32-bit unicode characters slip through testing and come back and bite you down the road. It's amazing how many apps have incorrect behavior with 4-byte unicode characters, on a wide range of platforms.

Both should be considered bad practice and programming languages evolved to standardize on UTF-8 for any string format that is to handle unicode. C++ for example needs to introduce something along the lines of "std::ustring" that makes unicode string ops "just work" with a UTF-8 backend, at the cost of some memory and performance vs. std::string, which should be seen as exclusively for ascii and binary string operations. std::wstring should be obsoleted.

Re:I am amazed

[bouldin]

I think you hit the nail on the head when you observed "they never bothered testing."

As long as software vendors have zero liability for defects, we'll probably continue to see easy-to-catch and easy-to-exploit bugs in software. Even software out of large, mature dev groups that should really know better.

Re:I am amazed

[Dog-Cow]

Right. They never bothered testing for a particular string that was found 8 years after the iPhone's release.

Could you be more stupid?

Re:I am amazed

[Dog-Cow]

Apple's NSString implementation is at least 15 years old. Sure it's been improved over the years, but it's not like Apple's a newcomer to parsing Unicode.

Bugs happen.

Re:I am amazed

[Dog-Cow]

To clarify: the iPhone has been out for (almost) 8 years, and only now the offending string was found.

No testing provides 100% coverage, especially for the number of combinations of possible Unicode characters in a 160-character/byte message. Only a complete moron would blame this bug on lack of testing.

Re:I am amazed

[gstoddart]

I think you hit the nail on the head when you observed "they never bothered testing."

Now, that is a bit disingenuous. TFS says The text string is specific enough that it's unlikely to happen by accident.

You can test and test and test, and it's still not possible to say you have tested every conceivable combination of stuff.

This doesn't sound like an "easy-to-catch and easy-to-exploit bug", this sounds like something obscure and unlikely. And it can be a bear tracking down and identifying something like that.

Unless Apple tested with every possible combination of characters, or had a test case which exactly matched this, I can easily see this being something which would get missed.

Re:I am amazed

[penguinoid]

Yes, technically there is a way to execute phone specific code with specially crafted text messages.

"Click here to install a puppy screensaver!!!"

Re:I am amazed

[bouldin]

This isn't as difficult to find as you might think. You do not have to test millions or billions of random text strings.

Software security testing works by breaking inputs into categories, and assuming that if you test one or two items in the category, then the category is covered. Categories are derived from the software specifications.

Example categories:
1. 0-byte message
2. max-length message
3. max-length +1 message
4. message consisting of all NULL bytes
5. message with unicode characters ...

If ellipses are treated specially, then they are part of the specifications, and should factor in to the choice of categories. There is software to automate building of test cases based on the categories, and the testing could be automated as well.

If we only test likely cases, we are not doing security testing. Given that this is an unauthenticated network vector, it should be subject to security testing. Apple has the resources to do this.

Re:I am amazed

[bouldin]

You don't understand software security testing. See my reply to gstoddard.

Re:I am amazed

[Anonymous Coward]

Probably the usual buffer overflow.

These days, system designers are fairly good about separating code and data, and making it impossible to execute data, but the one place they refuse to address the issue is on the stack, which contains code pointers, which are essentially "goto" instructions, and thus, they're code. Despite this, they constantly toss data on the stack all of the time, and occasionally people figure out how to send just the right data to a program to cause it to overwrite those code pointers with new code pointers that cause the program to do exactly what they want it to do.

The solution obviously is to have one stack for code, and a separate stack for data. This could be achieved on a PC by simply using the CPU's stack pointer (which it uses to store return addresses) only to store return addresses, and maintaining a separate stack for data, by using a different register to store a pointer on this stack and manually incrementing/decrementing that pointer when the stack is accessed. It would prevent a lot of exploits, but as usual, compiler authors are more concerned with performance than they are with security, never mind that one can buy a faster computer, but one cannot buy a more secure computer.

Obviously I think we should be primarily focused on security, and when security is too slow, we should look to speed up our hardware, not compromise our security. However, I seem to be in the minority on that one. Despite security being in the news every day, people still care more about speed.

Re:I am amazed

[bouldin]

Generally, if a carefully-crafted input can cause your application to crash, a similarly-crafted data may be able to exploit the same bug and cause an execution of malicious code. If â" as is usually the case â" the crash is due to buffer overflow and I can stomp over your app's memory, I may be able to place my code in the right place and it will be executed as part of the app...

This is only true for certain classes of memory management defects. There are many different kinds of defects, and many different ways to crash software that bring no possibility of remote code execution.

Re:I am amazed

[digitig]

Let me guess: you're into Agile development, but don't understand it well enough to know why black-box testing isn't enough for high-reliability applications.

Re:I am amazed

[Impy the Impiuos Imp]

For complicated c9mbos, perhaps. But random string generators should relatively quickly stumble across an elipsis in the middle of Latin or Arabic characters.

I wouldn't a priori suspect a string display routine to have a problem, but the guy who wrote it to do some gymnastics switching character sets should, and should have run such a test in a debugger ready to trap bad memory accesses.

Re:I am amazed

[Octorian]

Pretty much all Unicode handling in framework libraries is UTF-16, and has been for quite a long time. Windows "wide" strings, Java String, .NET String, Qt QString, ICU UnicodeString, etc. Of course some libraries may support choosing between the two, and many newer libraries do opt for UTF-8. Serialized formats are also more likely to be UTF-8. However, UTF-16 is still far more common as the "in memory" representation.

Since multi-element characters are far less common in UTF-16 than in UTF-8, I can see how one could forget something about that in their implementation. Then again, between Emoji and Asian languages, its kinda hard to ignore dealing with those.

Re:I am amazed

[Impy the Impiuos Imp]

Whitebox testing would point to exercising an ellipsis if treated specially. But good old blackbox billions of random strings should stumble across an ellipsis surrounded by non-Latin script characters, and fairly quickly.

Re:I am amazed

[Rei]

It's not that NSString itself is broken, it's that the fact that 99.99% of the time an NSString is one 16-bit code unit per glyph that apps using it rarely test the use case where it's two code units per glyph. So a person goes in and writes an app that inserts a new character at a particular byte offset and it works 99.99% of the time, but if it happens to get stuck in the middle of a multi-code-unit glyph, the program breaks.

The documentation is no help. First off, it lies:

Conceptually, a CFString object represents an array of Unicode characters (UniChar) along with a count of the number of characters. The [Unicode] standard defines a universal, uniform encoding scheme that is 16 bits per character.

As we all should know, that's simply not true. Unfortunately, a lot of people don't know better. Unicode is not a universal, uniform encoding scheme that is 16 bits per character. Even UTF-16 isn't that.

A string object presents itself as an array of Unicode characters . You can determine how many characters a string object contains with the length method and can retrieve a specific character with the characterAtIndex: method. These two “primitive” methods provide basic access to a string object.

characterAtIndex returns a 16-bit integer. So obviously it has no way to actually represent wider unicode characters. The length method is not the number of characters on the screen, but the number of code units, which is different, but highly misleading to programmers. They're, again, the same thing 99.99% of the time, but those rare cases where they're not generally slip through testing. And this is why UTF-16 is such a hazardous encoding to use.

Yes, NSString is old. And that's part of the problem. It was made at a time where many thought that unicode was only going to be 16 bits. It hasn't aged well. And it's caused a lot of bugs over its time. And now I'd bet that it or something similar has created a brand new iPhone-equivalent of Winnuke.

Programmers really need two types of strings, and only two, for the lion's share of tasks. One, binary strings, where a char is always 8 bytes and operations can be optimized to heck and back. And two, unicode strings, where a char always represents a whole unicode character that you would display, and the count of characters represents the count of display characters and so forth. None of this "99.99% of the time it's one thing, but every so often it's another...". That's asking for bugs.

Re:I am amazed

[Anonymous Coward]

While I understand where you are coming from, I think what the poster meant is only a moron would believe testing will find all bugs, security or otherwise.

Re:I am amazed

[tlhIngan]

No testing provides 100% coverage, especially for the number of combinations of possible Unicode characters in a 160-character/byte message. Only a complete moron would blame this bug on lack of testing.

Let's not forget that Unicode is a standard that's constantly evolving - new glyphs are constantly added (there's already a new proposed set for Unicode 9 including glyphs for "selfie", "avocado" and others)

People keep arguing that /. doesn't support Unicode, when it really does - it just uses a narrow whitelist of characters. The reason for this is obvious if you think about it - to prevent situations like this from happening.

Heck, there might be strings out there that will crash any Unicode library implementation, just we haven't found them yet because the search space is huge.

Re: I am amazed

[AvitarX]

Wouldn't a message in all Chinese trigger this?

Or if it has to do with splitting a multi byte character.,all Chinese and an odd number of Latin thrown in (I see snippits of Latin characters on weibo all of the time ).

If the error is not likely to happen, there's more too it than being explained.

Re:I am amazed

[cfalcon]

They probably tested with most of the unicode set. They probably didn't test with all of the unicode set at the exact message length (and in the correct position) needed to find this bug.

Re:I am amazed

[Rei]

Yep, they have been UTF-16 for a long time. And Unicode has been widely broken for a long time. It's not a coincidence.

Someone on StackExchange did some tests last year, adding in 4-byte unicode characters in common applications and seeing how they behaved. The results were really bad:

Opera has problem with editing them (delete required 2 presses on backspace)
        Notepad can't deal with them correctly (delete required 2 presses on backspace)
        File names editing in Window dialogs in broken (delete required 2 presses on backspace)
        All QT3 applications can't deal with them - show two empty squares instead of one symbol.
        Python encodes such characters incorrectly when used directly u'X'!=unicode('X','utf-16') on some platforms when X in character outside of BMP.
        Python 2.5 unicodedata fails to get properties on such characters when python compiled with UTF-16 Unicode strings.
        StackOverflow seems to remove these characters from the text if edited directly in as Unicode characters (these characters are shown using HTML Unicode escapes).
        WinForms TextBox may generate invalid string when limited with MaxLength.

I've had more than my share of these sort of experiences too.

UTF-16 is dangerous, and should be phased out as much as possible. Where absolutely needed for performance reasons, it should be an internal representation only, hidden from the developer as much as possible. In particular, "length" functions should return the actual string length in characters, not code units; indexing functions should take character offsets; not code unit offsets; and returned "single characters" exposed to the developer should be of a format capable of handling multi-code-unit glyphs. Anything involving working with actual singular UTF-16 code units should only be available as a "for advanced users only, use at your own risk" functionality.

Re:I am amazed

[jc42]

People keep arguing that /. doesn't support Unicode, when it really does - it just uses a narrow whitelist of characters. The reason for this is obvious if you think about it - to prevent situations like this from happening.

Heck, there might be strings out there that will crash any Unicode library implementation, just we haven't found them yet because the search space is huge.

Hmmm ... That tempts me to try a test using a couple of file names on this machine that are two of the names for a Mandarin-English dictionary: .html and Ptnghuà.html (and also Pu3Tong1Hua4.html for systems that can only accept ASCII ;-). Those names aren't in any sense obscure or tricky; they're strings you'd expect to see in online discussions of text handling in various languages. If you can't handle at least these trivial Chinese strings, you've failed pretty badly. Of course, they look findin this Comment: panel, and will likely survive the Preview button.

Let's see how /. handles them ...

Nope; the 3 Hanzi characters didn't show at all, and only the à showed correctly in the second name. But both everything looks correct in this second editing widget. This proves that /. hasn't damaged the actual text in the Preview. Let's see what happens when I try to post it ...

Re:I am amazed

[Anonymous Coward]

Troll? Fucking moron moderator didn't get the joke. Cum sucking idiot!

Re:I am amazed

[Anonymous Coward]

To be fair, Swift's string type actually deals with all the above problems correctly.

Re:I am amazed

[cbhacking]

Correct. As a random example, a NULL pointer read - certainly the most common class of memory error I've seen, probably the most common by far in general - is almost never exploitable (for arbitrary code execution). You can use it to crash programs (denial of service) but usually not for anything else.

Re:I am amazed

[BasilBrush]

As far as I can see the new String type used by Swift does it right.
Although when using existing Cocoa APIs it's get bridged to NSString anyway, so we're not out of the woods yet.

Re:I am amazed

[jc42]

People keep arguing that /. doesn't support Unicode, when it really does - it just uses a narrow whitelist of characters. The reason for this is obvious if you think about it - to prevent situations like this from happening.

Heck, there might be strings out there that will crash any Unicode library implementation, just we haven't found them yet because the search space is huge.

Hmmm ... That tempts me to try a test using a couple of file names on this machine that are two of the names for a Mandarin-English dictionary: .html and Ptnghuà.html (and also Pu3Tong1Hua4.html for systems that can only accept ASCII ;-). Those names aren't in any sense obscure or tricky; they're strings you'd expect to see in online discussions of text handling in various languages. If you can't handle at least these trivial Chinese strings, you've failed pretty badly. Of course, they look findin this Comment: panel, and will likely survive the Preview button.

Let's see how /. handles them ...

Nope; the 3 Hanzi characters didn't show at all, and only the à showed correctly in the second name. But both everything looks correct in this second editing widget. This proves that /. hasn't damaged the actual text in the Preview. Let's see what happens when I try to post it ...

I see that the "Comment:" edit widget for this message does have the Hanzi and marked 'u' and 'o' characters missing. So the damage is done after you hit the Submit button. There's no excuse for this. None of those characters have any special meaning to the code, and text containing them can't do any damage to anything. If damage happens, it's the fault of the crappy software handling the text, not the fault of the creator of the text. The right thing to do is to correct the crappy software. Damaging the text is simply idiotic, and interferes with the main reason (communication between literate people) that Unicode was invented.

(And we might note that a significant fraction of the users of the Internet now consists of people who communicate via Hanzi text, or Arabic or any of the hundreds of other character sets that humanity uses to communicate. Damaging those folks' texts to avoid fixing your crappy software is a good way to tell them that you don't want them communicating with other people. This is rapidly becoming a commercially untenable position for people trying to "attract eyes" on the Net. ;-)

Re:I am amazed

[spitzak]

My recommendation is special interators on std::string. Something like this:

    for (utf16_interator i = string.begin(); i != string.end(); ++i) {
          int x = *i;
          if (x < 0) error_byte_found();
          else utf16_found(x);
    }

There would also be interators for UTF-32 (probably what you were thinking of as "Unicode" but a lot of Microsoft programmers think "Unicode" means UTF-16). And iterators for other normalization forms. In all cases these would return negative numbers or some value that cannot be confused with a code point for UTF-8 error bytes.

This would be very fast because you can find the next Unicode code unit or whatever in constant time. Any api where you can arbitrarily index a unit using an integer is not going to be constant, it will be linear with that integer. Iterators avoid this.

Re:I am amazed

[spitzak]

Actually I think "Unicode strings" should be avoided completely.

They do not help at all in doing text manipulation, because Unicode code points are *not* "characters" or any other unit that users think about. This is due to combining characters and invisible characters such as bidi indicators. There is a prefix code unit that eats the next 2 letters and turns it into a country flag! It is a huge mess.

Far more important is they all lack the ability to store errors that are in a UTF-8 string in a lossless way. This means you cannot trust arbitrary 8-bit data to survive translation to "Unicode" and back. This has been the source of endless bugs and is the reason people can't use Python 3.0.

Re:I am amazed

[Rei]

We have to have something, though. Not everybody writes in English.

Re:I am amazed

[Rei]

I like that idea. You're right, it should be pretty efficient to implement, regardless of the string's backend encoding. And the value represented by the iterator will, by nature of being implemented as a pointer to a certain part in the string, be able to point to a glyph of arbitrary length (unlike a getter function with a fixed-length return type). Being an iterator it'll fit into all standard c++ libraries that take iterators.

It would be nice to have it be a random-access iterator so that you can jump to an arbitrary offset. There's a lot of optimizations they could do internally to help facilitate that. But obviously you still want to let programmers choose - by some means or another - whether they want such unicode optimizations (or unicode iteration, or so forth). Because while the overhead they'd impose wouldn't be huge, there still would be overhead.

Re:I am amazed

[spitzak]

Yes, we have UTF-8. You do know that it can hold non-English, right?

Re:I am amazed

[spitzak]

I don't think there are any useful algorithms that need random access, except for searches that do not require the index to be "exact". Therefore you certainly do not need a reliable string[i]. You can make it return a pointer to byte i, which will work for most uses (ie searches for ASCII and replacing one ASCII byte with another).

Some complex searches do want to jump arbitrary amounts ahead, but do not require any "exact" location. Instead they want "a character near the middle" and so forth. In this case it might be useful to produce an iterator that points near byte i. A simple UTF-32 one would jump to byte i and then back up to the last non-continuation byte, unless there are 3 or more in which case it would stay where it first went (as that is the start of an error). Ones that return normalization forms would be much more complex. Something like this:

      utf16_iterator i(string, string.length()/2); // i now points near middle of string

Re:I am amazed

[Rei]

UTF-8 is an encoding of unicode, so I'm totally not getting your "Actually I think "Unicode strings" should be avoided completely."

Re:I am amazed

[Anonymous Coward]

I would love a sed command that would replace all these worthless shitposts on ANY character-related topic, with an empty set. Or maybe a confused baby emoji.

"Oh, but not everyone speaks in English!". Of course not. That's never the fucking topic. Shut. The. Fuck. Up.

You and all the others like you can just excuse yourself from encoding discussions, and most the fuck CERTAINLY regex discussions. None of which are ever about what you guys think they are. That would be delish.

Re:I am amazed

[cfalcon]

Agree totally, but it would be nice to add some utf-8 specific functions that will, in ONLY those cases, actually walk the data (vastly slower for very large inputs than an index) and generate data about the string as utf-8 instead of byte data. Maybe those already exist in C/C++/ whatever the kids laughably think will be the next thing over those.

Re:I am amazed

[spitzak]

A lot of misinformed programmers use the term "Unicode" to mean encodings other than UTF-8, typically UTF-16 or UCS-2. For instance a function called "toUnicode" often is a translator from UTF-8 to UTF-16. Therefore when people say "Unicode strings" they almost always mean non-byte strings. I propose the best solution is to eliminate all such strings. It is true that byte strings would encode UTF-8 and thus be "Unicode" but the hope is that this would be so standard that there would be no need to ever specify this and they would be called "strings".

Re:I am amazed

[Rei]

So you mean get rid of wide-character encodings and only use UTF-8 where unicode characters are needed? I agree. :)

Re:I am amazed

[spitzak]

So you mean get rid of wide-character encodings and only use UTF-8 where unicode characters are needed? I agree. :)

Yes

But Macs "just work", right?

[spiritplumber]

I'm genuinely confused as to why people keep buying Apple stuff. I can get the same performance for half the price and twice the battery life from a lot of different brands.

Re:But Macs "just work", right?

[BradleyUffner]

I'm genuinely confused as to why people keep buying Apple stuff. I can get the same performance for half the price and twice the battery life from a lot of different brands.

By Spending large amount of money on something you don't have to you "prove" to others that you have large amount of money. See http://www.wikiwand.com/en/Han...

Re:But Macs "just work", right?

[Dog-Cow]

You have to give up 2x battery life to get the same performance? What kind of shit hardware do you buy?

Re:But Macs "just work", right?

[cjjjer]

Confused or want karma points, probably the latter.

Re: But Macs "just work", right?

[Rone]

Why? One big reason...

What percentage of current-generation Android phones will be able to get the next 2-3 major releases of the OS?

5-10% ?

What percentage of current-generation iPhones will be able to get the next 2-3 major releases?

~100%.

The apple phone does everything I need it to, and because of OS fragmentation on the Android side, third party apps are typically better / more stable. (Exceptions always exist, of course.)

I'm quite happy to hear arguments to the contrary, but my broad-brush perspective is that while Apple's ecosystem is a walled garden, Android's ecosystem is the wild west.

I'm willing to accept a garden with walls if it means I don't have to constantly worry about what unpatched vulnerability is ripe for exploitation on my phone.

Re:But Macs "just work", right?

[Anonymous Coward]

I've had HTC and Android phones, neither had any great claims to battery life.. except that you could remove the battery and have a spare available. As for laptops, if they cost less than a Mac, they certainly don't have comparable battery life.

Re: But Macs "just work", right?

[Anonymous Coward]

I've had a couple android phones from HTC and Samsung, they were fine with supported releases until they were 6 months old. After that it was pathetic. And I realize that's a vendor / carrier complicated issue, but it's the end result that matters.

Re: But Macs "just work", right?

[mjtaylor24601]

I'm willing to accept a garden with walls if it means I don't have to constantly worry about what unpatched vulnerability is ripe for exploitation on my phone.

You mean like that vulnerability where I can send you a text message and cause your phone to crash? ;-)

Re:But Macs "just work", right?

[RavenLrD20k]

Never. Ever. Do. That. Again.
Or I will mark you as a troll if I have mod points. And frankly, I hope somebody does that to this one.

If you're going to post an informative link from Wikipedia, go straight to Wikipedia; not that wikiwand crap. Using that link to a site pushing a formatting extension that changes the way wikipedia's UI format looks is trolling for users to hijack with a MitM attack. This is fucking /. The general population knows better than to install random extensions from unverified sources. Go pedal your crapware on reddit.

Re:But Macs "just work", right?

[Anonymous Coward]

" As for laptops, if they cost less than a Mac, they certainly don't have comparable battery life."

I've got a 75 MHz Pentium. With an upgraded battery pack, it runs for almost 48 hour straight.

Please show me ANY Apple laptop that gets that sort of battery life. Oh, they're only JUST NOW getting made with that sort of low power envelope.

Re: But Macs "just work", right?

[codepigeon]

I'm willing to accept a garden with walls if it means I don't have to constantly worry about what unpatched vulnerability is ripe for exploitation on my phone.

You mean like the ability to crash a phone with a text message? :)

Re: But Macs "just work", right?

[MobileTatsu-NJG]

Wasn't It Android the main ingredient of a botnet half a million strong a couple of years ago?

Re: But Macs "just work", right?

[geminidomino]

What percentage of current-generation iPhones will be able to get the next 2-3 major releases?

~100%.

How many of those phones, after receiving 2 or 3 major releases, will be so buggy or sluggish as to be unusable? Considering the amount of bitching every time it happens, I'd say non-zero.

Re: But Macs "just work", right?

[Anonymous Coward]

LOLOL apples to oranges. Let me see you multitask on that laptop like i do on Mac. I paid $1200 for my 2012 mbp i7. I was looking at an i7 laptop with similar specs to run Linux, $900. I might as well spend the extra $300 and get all the perks that come with apple. If $300 is setting you broke, then you need a new job.

Re: But Macs "just work", right?

[Anonymous Coward]

Yes, which in 8 years of using an iPhone has never once happen to me. And probably will never happen to me.

Re: But Macs "just work", right?

[Anonymous Coward]

The correct answer is 0%, not 100%.

Major features are left out for no good reason, like voice assistant. It's not like it was missing hardware, and the original app it was based on worked with even first gen phones (and even Android was almost done before the buyout)

Moreover, Android's individual components and system apps are updated outside of major OS revisions. That fraudulent SSL Cert issuer in China like a month or two? That was fixed without a full system update in under a week. Meanwhile, you're STILL waiting... and your information can be siphoned off pretty easily with a forged cert.

You can keep your hyperbole... I'll keep to my security.

Re: But Macs "just work", right?

[Anonymous Coward]

LOL, if you buy a non-flagship phone, what are you expecting?

I'm not sure what you're referring to. Even old flagship (and a decent portion of non-flagship) Android devices have at least 1, if not 2 years updates before the features are just too much for the aging phone (in which case, it still gets security updates because most system apps can be updated through Google Play.

Re: But Macs "just work", right?

[MobileTatsu-NJG]

Judging from the negative mod I got for my remark, the answer is yes, I was right, and yes it was inconvenient for the Fandroids out there.

Have nice day.

Re: But Macs "just work", right?

[BronsCon]

Citation, please? I don't recall this.

Re: But Macs "just work", right?

[Anonymous Coward]

Amusingly Slashdot did cover that. It's like there's some weird blind spot when it comes to weaknesses in Android.

You lot really should show a little more objectivity. It doesn't hurt anything.

Re: But Macs "just work", right?

[BronsCon]

I'm not denying it, I'm asking for a link to an article about it, as I legitimately don't recall having heard or read about it at the time. How about being helpful, instead of being a douche, for once?

Re: But Macs "just work", right?

[BronsCon]

Oh! It was this? Huh, interesting. FTFA: "Users would then see notifications about the finished downloads and would click on them, prompting the malicious application to install if their devices had the "unknown sources" setting enabled"

Yes, iOS is protected from this sort of attack by simply not allowing the user to install from unknown sources, a setting which is disabled by default on Android, incidentally. In other words, one specifically has to make themselves vulnerable to this attack in order to be vulnerable, it doesn't work in Android's default configuration.

It's always amusing when Apple fanbois point to vulnerabilities that require the ability to install from untrusted sources and scream about how insecure Android is. Really? Don't check the box to allow it (which, again, is unchecked by default) and it's a non-issue; the only people who should be checking that box are Android developers and, then, only on their development and testing devices.

The other class of "exploits" I find laughable are those that require root. Sure, many of them can be found in the Play store, but they have no effect whatsoever on a stock Android install. If you're going to consider those "exploits" you need to compare against the iOS equivalent: jailbroken devices. Suddenly, Android doesn't look so bad.

Sent from my Space Gray iPad Air 2.

Re: But Macs "just work", right?

[mars-nl]

I'm quite happy to hear arguments to the contrary, but my broad-brush perspective is that while Apple's ecosystem is a walled garden, Android's ecosystem is the wild west.

How would you classify a Windows desktop or a Linux desktop?

Re: But Macs "just work", right?

[Anonymous Coward]

It's always amusing when Apple fanbois point to vulnerabilities that require the ability to install from untrusted sources and scream about how insecure Android is. Really?

Yes, if you leave out the number '500,000' it sounds silly, doesn't it. It doesn't at all sound like the result of bad philosophies colliding, thus breeding bad behavior from a massive number of customers.

Oh, just wanted to mention since I'm somehow a douche for your laziness, you replied a full hour after the link you asked for was presented. Apple fanboys are accused of succumbing to the Reality Distortion Field, apparently Fandroids are especially vulnerable to SEP.

Re: But Macs "just work", right?

[Anonymous Coward]

The 90% of phones that don't though are probably at least 50% cheaper than the iPhone, and I'm sure if the announcement is true, vendors will begin to make the same guarantees for other Android phones too.

Now, the best thing about the walled garden, is that when a serious problem is found with the app after release, it can take Apple a long time to approve the update.

That's also excluding the fact that people on iPhone don't realise jailbreaking is basically exploiting vulnerabilities in the phone, and that there have been plenty of security issues discovered on iPhone (ranging from SSL related, to image parsing)

Re: But Macs "just work", right?

[BronsCon]

Yes, if you leave out the number '500,000' it sounds silly, doesn't it.

And the only reason the number of exploits from untrusted sources is 0 on non-jailbroken iOS is because you simply can't install from untrusted sources.

Since you seem to want to compare Apples to Androids, though, here is one that infected 100k+ iOS devices, no jailbreak or untrusted sources required. And another affecting 75k+ jailbroken iOS devices. I stopped searching after finding those two (which took a whole 30 seconds); that it was so easy to find those two tells me there's a lot more to be found if I wanted to invest another half-minute in it.

Let's see, 500k of 900 million Android devices, that's an infection rate of about 5.6%. I'll admit, that's not great, but let's see how iOS fares before we got all uppity, okay? I can't find "in use" numbers, only that Apple has sold over 800k; I know they're not all in use, so I'll do a quick calculation based on market share. Worldwide market share, that is, since the 500k number you're touting is worldwide. So, Android's 81.5% market share means that 1% of the market is a hair over 11 million devices; iOS holds 14.8% of the market, or 163.5 million devices. 175k infected, out of 163.5 million devices, that's a 10.7% infection rate.

So yes, sure, let's assume that other malware exists for iOS, sure there are almost 3x as many infected Android devices, but an iOS device appears to be almost 2x as likely to be infected. Factor in that other malware certainly does exist (every jailbreak is an exploit and many jailbreak utilities have been bundled with malware; little reported but anyone involved in the scene knows, always get your jailbreak tools direct from the author, but even that is no guarantee). In short, the 175k number I used is smaller than it should be, making the 10.7% infection rate I came up with a fair bit smaller than the real infection rate, as well.

As a user of a single phone and a single tablet, running the less-likely-infected platform means I'm less likely to be infected. Period. That said, I greatly prefer iOS over Android on a tablet and absolutely love my iPad. I don't do anything mission critical on either device, so my exposure is limited in any case, but I'm a little more lax with my more secure Android phone than I am with my less secure iPad.

It doesn't at all sound like the result of bad philosophies colliding, thus breeding bad behavior from a massive number of customers.

Correct. It really doesn't. unless you consider freedom a bad philosophy. Of course, with freedom comes responsibility, as in you are responsible for what happens when you misuse the freedom to install crap on your phone. Seriously, rather than volunteering to have our own freedoms stripped from us because we refuse to connect our actions with the consequences they bring, why don't we all just behave like the adults that we are and own out own liabilities? Android lets you do that, while iOS does not.

Oh, just wanted to mention since I'm somehow a douche for your laziness, you replied a full hour after the link you asked for was presented.

You're not a douche because I loaded the page long before that link was posted (not laziness, BTW), you're a douche for a whole slew of other reasons, many of which also apply to myself. So I didn't refresh the page before posting. We all do that, your point? Welcome to Slashdot.

Fandroids are especially vulnerable to SEP.

They also wouldn't own an iPad and two MacBook Pros. I guess you aimed your anti-Fandroid ray at the wrong guy.

Re: But Macs "just work", right?

[Anonymous Coward]

Yes, it is embarrasing laziness. Douche projection? And yes, your focus on one side supports the claim against you of bias despite your protestation that some of your best friends... I mean you say you have an iPad.

Hint: Your comically long-winded rant has a very obvious plot-hole. Suddenly you can use Google, but only when properly motivated.

Re: But Macs "just work", right?

[BronsCon]

Funny, the post you replied to was the result of my having used Google to track down the story myself, since I did not see your link. Interesting, you know, me being too lazy to Google it and all. Where's this plot hole?

Re: But Macs "just work", right?

[Anonymous Coward]

Uh, yeah, you went to Google after failing to scroll down a bit and being arm twisted into it. Great work there.

As for the plot hole, it really is obvious. I'll give you a hint: In my first post I criticized your objectivity. I described the very affliction that your long-winded, I suppose you'd call it a rebuttal, demonstrated quite hilariously.

Since technically that isn't really a hint because I've already told you this before, here's another. The number isn't one. You've overcome your problem once, let's see if you can do it again.

Re: But Macs "just work", right?

[BronsCon]

Uh, yeah, you went to Google after failing to scroll down a bit and being arm twisted into it. Great work there.

Failing to scroll? I loaded the page an hour before the link was posted and replied an hour after (without reloading the page) when I got around to it. I've already explained that; the link wasn't on the page to scroll down to, but nice try. As for arm-twisting, I replied to my own comment directly, before anyone else had replied to it in order to be able to twist my arm. Another good try, but you're not quite on the mark.

As for the plot hole, it really is obvious. I'll give you a hint: In my first post I criticized your objectivity.

Yes, you're arguing against me as a person, rather than my point. That tell me you have no fact-based argument.

I described the very affliction that your long-winded, I suppose you'd call it a rebuttal, demonstrated quite hilariously.

You mean that I googled around for some actual facts to post, then explained how those facts apply to reality? What affliction is that, then? Being a realist?

If you disagree with the point I am trying to make, which I have backed up with actual facts, then please, make your own counter point and back it up with your own actual, real, facts. Attacking me because you can't do that only makes your position look as weak as it you and I both know it actually is. Lucky for you, I respond because I find your attempts at trolling me every bit as amusing as you do.

Since technically that isn't really a hint because I've already told you this before, here's another. The number isn't one. You've overcome your problem once, let's see if you can do it again.

This makes no sense. If you used more bold text I'd think you were APK.

Re: But Macs "just work", right?

[Anonymous Coward]

The reason it doesn't make sense is that you feel you can do no wrong. The point I've been making all along is that you have a blind spot when it comes to the research that you do. You're willing to scrutinize one side, but not another, even to the extreme of trying to sell the excuse of not refreshing a page in a discussion forum for an hour. For example, you made your calculation of unfection based on the idea that there is only one bit of malware on Android. You didn't even try looking that up, you just wanted to find a number to lessen its impact. Nice objectivity, there.

Re: But Macs "just work", right?

[BronsCon]

Sorry for the late reply, Slashdot stopped notifying me about this thread.

I spent just as long looking for examples of Android malware as I did looking for examples of iOS malware. I admitted, early on, that neither was exhaustive. If you want exhaustive, I'll give it to you, but you won't like the results. Shoot me an email so I can get the entirety of my research and findings to you in a month or two when I'm done. Meanwhile, realize that you're the one with the blind spot; if you don't like my research, do your own and prove mine wrong, don't just point fingers and say "your methodology is flawed", sure it's flawed, I admitted as much at the start, but you still fail to disprove my findings.

As for your insinuation that I feel I can do no wrong... Really? Review my post history, I admit I'm wrong on here whenever someone actually shows me that I am, which happens, roughly, 5 or 6 times a year. If that number seems a bit low it's because I generally don't open my mouth unless I'm fairly certain I know what the hell I'm talking about. You should try it sometime.

My friend knows about this...

[ThatsDrDangerToYou]

His name is Bobby Tables.

https://xkcd.com/327/

I still laugh at this... am I an idiot? Don't answer that.

Re:My friend knows about this...

[Anonymous Coward]

Yes, you are an idiot, SQL injection has fuck all to do with the bug/exploit here.

Re:My friend knows about this...

[ZxCv]

One of the best xkcd's of all time

Re:My friend knows about this...

[digitig]

No, but input characters that are handled in a non-standard way have everything to do with it. Don't just think of the last bug; think about what you can learn from it to avoid the next one.

Re:My friend knows about this...

[Phusion]

You sound upset, maybe you need to get in your BMW and go visit your supermodel girlfriend for some comfort.

Re:My friend knows about this...

[Ravaldy]

Funny as hell.

Re:My friend knows about this...

[ThatsDrDangerToYou]

You sound upset, maybe you need to get in your BMW and go visit your supermodel girlfriend for some comfort.

Dude, don't tell him THAT! (quickly putting clothes on and scramming out the back door...)

Re:My friend knows about this...

[Anonymous Coward]

Yes!

Sorry... :-)

Re:My friend knows about this...

[haploc]

SQL doesn't, but input validation does.

Apple Watch

[danbob999]

Getting notifications on an Apple Watch also protects the iPhone from the bug.

They have to push sales of the iWatch some ways...

Re:Apple Watch

[Anonymous Coward]

I know you jest, but Apple Watch in its time available has sold more than all Android Wear watches in its entire time on the market.

Feature!!!

[Anonymous Coward]

It not a bug, it's a feature.

What is the string?

[danbob999]

They do not publish it in TFA.

Re:What is the string?

[Dog-Cow]

We can't tell you. It requires Unicode characters that /. won't render.

Re:What is the string?

[danbob999]

hex code would be fine

Re:What is the string?

[Coisiche]

The Guardian were probably too scared at the thought of an Apple lawsuit to publish the actual text.

Re:What is the string?

[Anonymous Coward]

Yeah, no kidding. The one bit of useful information and they don't goddamned include it.

Thankfully reddit has us covered. I know some Apptards that are going to be receiving texts from me this afternoon. Go ahead, tell me how your iPhone is superior to Android, I dare you.

Re:What is the string?

[Cro Magnon]

Would it crash /. ? :)

Re:What is the string?

[Anonymous Coward]

They already gave the broad technical parameters, so all one has to do is do an educated bruteforce on the messages. If this works for any iMessage, not just SMS, then it's not going to piss off the phone company either. One could also try intentionally invalid multi-byte sequences and see if the phone crashes even without trying to insert that ellipsis. Sounds like a few hours work tops.

Re:What is the string?

[mtbrandao]

Here.
https://www.reddit.com/r/apple/comments/37enow/about_the_latest_iphone_security_vulnerability/

We've come to a time that reddit posts are more infotmative then slashdot articles.

Re:What is the string?

[Anonymous Coward]

The string [or a string capable of reproducing the error] is on Reddit. Do a search.

Re:What is the string?

[25albert]

In hex, the string is:

506f 7765 7220 d984 d98f d984 d98f d8b5 d991 d8a8 d98f d984 d98f d984 d8b5 d991 d8a8 d98f d8b1 d8b1 d98b 20e0 a5a3 20e0 a5a3 6820 e0a5 a320 e0a5 a320 e586 97

It starts with "Power ", but I guess that's not important.

Re:What is the string?

[Guy Harris]

In hex, the string is:

506f 7765 7220 d984 d98f d984 d98f d8b5 d991 d8a8 d98f d984 d98f d984 d8b5 d991 d8a8 d98f d8b1 d8b1 d98b 20e0 a5a3 20e0 a5a3 6820 e0a5 a320 e0a5 a320 e586 97

That's the string encoded as UTF-8, so it's more like

50 6f 77 65 72 20 d9 84 d9 8f d9 84 d9 8f d8 b5 d9 91 d8 a8 d9 8f d9 84 d9 8f d9 84 d8 b5 d9 91 d8 a8 d9 8f d8 b1 d8 b1 d9 8b 20 e0 a5 a3 20 e0 a5 a3 68 20 e0 a5 a3 20 e0 a5 a3 20 e5 86 97

If we turn that into a sequence of (21-bit) Unicode code points, it becomes

000050 00006f 000077 000065 000072 000020 000644 00064f 000644 00064f 000635 000651 000628 00064f 000644 00064f 000644 000635 000651 000628 00064f 000631 000631 00064b 000020 000963 000020 000963

which, encoded as UTF-16, is

0050 006f 0077 0065 0072 0020 0644 064f 0644 064f 0635 0651 0628 064f 0644 064f 0644 0635 0651 0628 064f 0631 0631 064b 0020 0963 0020 0963

As UTF-16, there are no surrogate pairs, so the bug presumably isn't a problem with handling UTF-16-encoded Unicode characters bigger than 00FFFF.

I suspect that the string is probably being processed as UTF-16, because that's how CFString/NSString are encoded internally and because code handling UTF-8 that can't handle multi-byte characters couldn't handle anything other than ASCII.

U+0963 is DEVANAGARI VOWEL SIGN VOCALIC LL, which is a nonspacing mark; my guess is that it (or perhaps some other character in that sequence that's a combining character) is getting split, by the ellipsis, from the character with which it's supposed to combine, and that the rendering code is blowing up because of that.

If so, this has nothing to do with UTF-16 being too hard to handle correctly, or with the code not being able to handle characters that are "too many bytes", it has to do with sequences of characters sometimes having to be handled specially, and not just blithely split between characters.

It starts with "Power ", but I guess that's not important.

It might make the string long enough that the code displaying it on the main screen would abbreviate it and thus insert an ellipse.

Re:What is the string?

[Jack Griffin]

I've been trying to find it myself - for testing and verification of course.
I found this:


and this:
Power
h


but neither did anything.

haha just notice slashdot won't display the unicode.
See here: https://zhovner.com/tmp/killwe...
and here: http://www.ibtimes.com/text-ca...

Re:What is the string?

[Guy Harris]

That's the string encoded as UTF-8, so it's more like

50 6f 77 65 72 20 d9 84 d9 8f d9 84 d9 8f d8 b5 d9 91 d8 a8 d9 8f d9 84 d9 8f d9 84 d8 b5 d9 91 d8 a8 d9 8f d8 b1 d8 b1 d9 8b 20 e0 a5 a3 20 e0 a5 a3 68 20 e0 a5 a3 20 e0 a5 a3 20 e5 86 97

If we turn that into a sequence of (21-bit) Unicode code points, it becomes

000050 00006f 000077 000065 000072 000020 000644 00064f 000644 00064f 000635 000651 000628 00064f 000644 00064f 000644 000635 000651 000628 00064f 000631 000631 00064b 000020 000963 000020 000963

...with 000068 000020 000963 000020 000963 000020 005197 following it (I quit translating too early)

which, encoded as UTF-16, is

0050 006f 0077 0065 0072 0020 0644 064f 0644 064f 0635 0651 0628 064f 0644 064f 0644 0635 0651 0628 064f 0631 0631 064b 0020 0963 0020 0963

...with 0068 0020 0963 0020 0963 0020 5197 following it.

As UTF-16, there are no surrogate pairs, so the bug presumably isn't a problem with handling UTF-16-encoded Unicode characters bigger than 00FFFF.

Still true with the corrections.

Is it 2013 again?

[InfiniteBlaze]

This story feels familiar...maybe one of the best reasons to avoid iOS devices. https://www.youtube.com/watch?...

Re:Is it 2013 again?

[hippo]

No, it's 1985 again. Or even earlier. 1985 was when I found out an escape sequence that would reboot the HP100 portable computer my boss used to access the message system on the HP 3000 minicomputer. Cue me sending an email with it in the subject. The reboot took so long the messaging system logged you off and handily when you log in it prints the subjects of your unread emails and around you go again.

This kind of stuff never gets old.

Re:Is it 2013 again?

[Anonymous Coward]

A few years ago you could kill SMS functionality on Symbian phones by sending them a message containing a very long email address.

Re:Is it 2013 again?

[InfiniteBlaze]

Very cool, but I was referring specifically to the relatively recent vulnerabilities in relatively modern devices.

What next?

[hamsterz1]

"The bug is being used as a prank, with users taking to Twitter to vent their frustration after crashes. As with any glitch like this, it is that possible hackers could turn the bug into a method of attack beyond simple pranks." Seems to me if you can crash a device, you can perhaps "root" a device. Sounds like this is a test to see what can be done to an iOS device both now and in the future.

Re:What next?

[hamsterz1]

"The bug is being used as a prank, with users taking to Twitter to vent their frustration after crashes. As with any glitch like this, it is that possible hackers could turn the bug into a method of attack beyond simple pranks." Seems to me if you can crash a device, you can perhaps "root" a device. Sounds like this is a test to see what can be done to an iOS device both now and in the future.

PS Imagine if this was done to thousands of iOS devices simultaneously, what then?.

Re:What next?

[Anonymous Coward]

Maybe...just maybe...a lot of people just might stop buying (Cr)apples vastly overprice, poorly manufactured
  junk?!

Re:What next?

[hamsterz1]

Maybe...just maybe...a lot of people just might stop buying (Cr)apples vastly overprice, poorly manufactured junk?!

Yes indeed, and built with cheap labor at the Foxconn factory.")

CNR

[Anonymous Coward]

Trying around the office.

Clearly the work of the NSA

[Anonymous Coward]

If the ellipsis is placed in the middle of a set of non-Latin script characters, including Arabic, Marathi and Chinese, it causes the system to crash and the phone to reboot.

For example:

(in a non-Western language)
We know what we have to do next...

Crash!

How long till...

[gwstuff]

An sms that uploads the recipient's email and photos on bittorrent, or on top of a blockchain. That should be a trend setter...

Re:How long till...

[Dog-Cow]

1 trillion billion years.

Any other moronic questions?

Re:How long till...

[gwstuff]

Ha ha ha ha...

Not that it's funny or interesting in any way, but thought I'd give you the maximal boost in self-esteem that you were hoping for, Mr. "un-moron."

Re:How long till...

[hamsterz1]

An sms that uploads the recipient's email and photos on bittorrent, or on top of a blockchain. That should be a trend setter...

Some banks are advertising on bill boards, encouraging customers to use their phone, to send a text message to do their online banking. Just think about the security implications of using SMS to do ALL your online transactions.:(

Re:How long till...

[gwstuff]

Yeah, that was the point I was trying to get at. Most people take the privacy of their most intimate secrets for granted - they keep it in their email, on their mobile devices etc. And while these things are pretty well guarded, from a technological standpoint a single bug can lead to the mass subversion of a whole ecosystem. It seems to me that the day all of Gmail - or some other major email provider, or private data on everyone's iPhones, etc. is hacked and made public, will be an historic event "The day privacy died." IT should be alarming, but it's one step away, like many posted in this thread, bugs happen...

Re:How long till...

[Anonymous Coward]

If you want that, set up a free service similiar to dropbox. Then, sit at the server and look at all the stuff people voluntarily give you. Remember, they reserve the right to change the terms of the free service anytime - so they can do anything with stuff you upload.

For more fun, set up a free online password vault. Or better, run a dating site . . .

Re:How long till...

[Jack Griffin]

Yeah, that was the point I was trying to get at. Most people take the privacy of their most intimate secrets for granted -

Or they simply don't care as much as you do. Seriously, you think anyone really wants to see photos of your bum? Who is the market for all this tonnes and tonnes of useless information?
If all the world's secrets were published tomorrow I think the reaction would be "meh, what's for dinner?" It's actually worse if it only happens to one person, if happens to everyone then that becomes the new norm and no-one cares.

Nokia phones did this years ago.

[whoever57]

Years ago, I had a number of Nokia flip phones. I also converted emails to text messages and sent them to the phone (actually, probably MMS, not SMS), so that I could read my emails on a dumb phone.

However, every now and again, I would receive a "text of death". The phone would receive a text message, crash, reboot, attempt to download text messages again, crash .... etc.. It continued to do this until the network would decide to give up attempting to send that MMS message.

I had several phones of the same model and they all did this.

Re:Nokia phones did this years ago.

[Rinikusu]

See everyone? Apple doesn't invent anything! They just do it with more polish.

Re:Nokia phones did this years ago.

[timholman]

However, every now and again, I would receive a "text of death". The phone would receive a text message, crash, reboot, attempt to download text messages again, crash .... etc.. It continued to do this until the network would decide to give up attempting to send that MMS message.

I've got a better story than that. Back in the mid-80's, when I was working at IBM, we did almost all of our programming in REXX and APL2 using dumb terminals.

One of the features of the system was the ability to send a message to another user that would appear directly on his or her screen like a text message.

By accident, one of the guys in my group discovered that by sending a certain string of characters to another user, he could force the receipt's terminal to automatically log off. Predictably, this led to a campaign of various people sending the "message of death" to each other, hearing the recipient yell and curse, and then quickly closing any open file before the victim fired back with a message of his own. This went on for about two weeks before we all got tired of it.

And of course I could also talk about the REXX worm that shut down the entire IBM internal email system for more than a day, but that is another story. :-)

Everything old is new again.

Re:Nokia phones did this years ago.

[koan]

Wasn't there some Windows Net Send bugs too? I seem to remember screwing around with people back in the NT4 days.

Re:Nokia phones did this years ago.

[koan]

Polish? Wasn't that Arabic?

Re:Nokia phones did this years ago.

[sconeu]

You could do that on Unix System III with ADM-12 terminals as well.

Re:Nokia phones did this years ago.

[bd580slashdot]

I came here to comment on this. There are services and botnets that can send millions of simultaneous texts. I once read a blackhat idea of rebooting millions of phones over and over or all at once to see if it would crash the next layers of the networks. Maybe the towers couldn't handle it and would go down. And then ...

Re:Nokia phones did this years ago.

[Fnord666]

Don't forget messages with terminal control characters that set the font to black on a black background.

You shmucks!

[Anonymous Coward]

You can't crash my iphone: 214 289 9974...

Re:You shmucks!

[koan]

Or mine 867-5309.

Oh Jenny.

Crash

[nogginthenog]

Power h

Why is Apple's Unicode support so buggy?

[Anonymous Coward]

I mean seriously, why is it Apple again screwing up with Unicode? It's the third example of such crash that I recall, and probably there were more.

Re:Why is Apple's Unicode support so buggy?

[koan]

The Chinese market? I dunno...

Other messages that will crash an iPhone

[Anonymous Coward]

"Android is a superior OS"
"I think my iPhone has a bug"

I've always missed the IM Punter

[PongoX11]

AOL!

Arabic text

[Anonymous Coward]

So when your phone receives a very specific text in Arabic it... blows itself up?

Re:Arabic text

[dave420]

The future begs you to grow up.

Re:Arabic text

[Anonymous Coward]

I think it's funny apk makes you run every time http://linux.slashdot.org/comm...

Artefacts of the Steam Age of Computing (TM)

[Qbertino]

Shit like this are the artefacts from the steam age of computing.
As a web guy I deal with this every day. If I ever get around to building an OS and/plattform (Harhar) I'll force one text format and one only for all glyphs in existance (UTF seems like a good candidate).
Controll characters will be completely seperate.

Re:Artefacts of the Steam Age of Computing (TM)

[Anonymous Coward]

Congratulations. Now you've taken the complexity of a multi-codepoint character set (Unicode) and added the complexity of having to embed a completely *different* set of codepoints within the same stream of text.

Re:Artefacts of the Steam Age of Computing (TM)

[Guy Harris]

I'll force one text format and one only for all glyphs in existance (UTF seems like a good candidate).

To which UTF are you referring?

Message coming in from the ghost of Steve Jobs

[idontgno]

"You're reading it the wrong way."

Re:Message coming in from the ghost of Steve Jobs

[koan]

I want a new .sig, One that won't make me sick...
One that won't make me crash my phone, or feel like a dick

Oh Huey....

Did they already fix this?

[Charliemopps]

Did Apple already fix this? I immediately tried to crash every phone of every coworker who has an iPhone within earshot of me and it didn't work. Much to my disappointment. I'm now having to save face by harassing them with Pictures of Steve Job's license plateless car parked in multiple handicapped spots.

Re:Did they already fix this?

[Just Some Guy]

I immediately tried to crash every phone of every coworker who has an iPhone within earshot of me and it didn't work.

I too enjoy getting fired over stupid shit. Do you have any other suggestions I might try?

Re:Did they already fix this?

[StikyPad]

Were you using SMS or iMessage? This is probably fixable in iMessage -- they get routed through Apple's servers and could probably be sanitized so that the offending characters can be byte-aligned to avoid the crash -- but SMSes go directly through the carriers and would require an OS update.

Re:Did they already fix this?

[Jack Griffin]

What causing your co-workers phone to reboot is a sackable offence where you are? What if you accidentally kick the power cord out of their PC? Doesn't sound like a fun place to be. I did it here but it didn't work, people here were genuinely interested is this was for real or not.

Re:Did they already fix this?

[Anonymous Coward]

Huh? This isn't accident. Pretty sure if I purposefully kicked out the power cord of my co-worker's computers, I'd destroy their work and be quite adequately fireable.

I miss winnuke

[koan]

https://www.reddit.com/r/iphon...

Re:I miss winnuke

[Anonymous Coward]

>reddit
I miss Usenet.

My Treo 650 (Palm OS) gets garbage as SMS --??

[Anonymous Coward]

Is this any relation to the way SMS messages from (some) iPhones appear on the Treo message screen as a single non-ASCII garbage character?

It's unpredictable, but once someone's iPhone starts they can never again send me a SMS.

And as a dinosaur, I only started using SMS last year.

No, I don't want a new telephone, I'm happy with my Treo 650....

Like you knew better than me? LMAO... apk

[Anonymous Coward]

"Because nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)

FROM -> http://it.slashdot.org/comment...

SpyBot S&D does dimwit

(you FAIL #1)!

You LATER deny it's spybot's forums http://it.slashdot.org/comment...

Anyone can use it + see they do & MANY use that program stupid!

(you FAIL #2)!

---

NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!

(YOU FAIL #3)!

(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...

---

Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...

(you FAIL #4)!

YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!

"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)

FROM-> http://it.slashdot.org/comment...

(you FAIL #5)!

---

WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):

http://forums.pcpitstop.com/in...

(YOU FAIL #7)!

Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!

(You FAIL #8)!

Do YOU have *ANYTHING* like it to YOUR name/credit? No.

(YOU FAIL #9)!

---

Do you write a ware that noted security pros even seconded me on?? No.

(You FAIL #10)!

A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)

APK

P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me)... apk

Tell us you're a security engineer Bouldin

[Anonymous Coward]

"Because nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)

FROM -> http://it.slashdot.org/comment...

SpyBot S&D does dimwit

(you FAIL #1)!

You LATER deny it's spybot's forums http://it.slashdot.org/comment...

Anyone can use it + see they do & MANY use that program stupid!

(you FAIL #2)!

---

NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!

(YOU FAIL #3)!

(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...

---

Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...

(you FAIL #4)!

YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!

"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)

FROM-> http://it.slashdot.org/comment...

(you FAIL #5)!

---

WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):

http://forums.pcpitstop.com/in...

(YOU FAIL #7)!

Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!

(You FAIL #8)!

Do YOU have *ANYTHING* like it to YOUR name/credit? No.

(YOU FAIL #9)!

---

Do you write a ware that noted security pros even seconded me on?? No.

(You FAIL #10)!

A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)

APK

P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me)... apk

You don't understand security, period

[Anonymous Coward]

"Nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)

FROM -> http://it.slashdot.org/comment...

SpyBot S&D does dimwit

(you FAIL #1)!

Anyone can use it + see they do & MANY use that program stupid!

(you FAIL #2)!

---

NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!

(YOU FAIL #3)!

(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...

---

Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...

(you FAIL #4)!

YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!

"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)

FROM-> http://it.slashdot.org/comment...

(you FAIL #5)!

---

WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):

http://forums.pcpitstop.com/in...

(YOU FAIL #7)!

Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!

(You FAIL #8)!

Do YOU have *ANYTHING* like it to YOUR name/credit? No.

(YOU FAIL #9)!

---

Do you write a ware that noted security pros even seconded me on?? No.

(You FAIL #10)!

A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)

APK

P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me) - & you're a "security-engineer"after the above? LOL, not... apk

Re:You don't understand security, period

[Anonymous Coward]

Fuck off.

Re:You don't understand security, period

[Anonymous Coward]

Nobody cares. Everyone knows you're a complete idiot.

Re:You don't understand security, period

[Anonymous Coward]

Yeh, you're just good for a nostalgic laugh with your inferiority complex.

Re:You don't understand security, period

[Anonymous Coward]

Bouldin's understanding of security is inferior http://slashdot.org/comments.p... and after I read that I can safely make that statement based on Bouldin's own mistakes quoted that he made 10 times there against apk without a doubt.

Bouldin's "security defects" enumerated... apk

[Anonymous Coward]

"Nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)

FROM -> http://it.slashdot.org/comment...

SpyBot S&D does dimwit

(you FAIL #1)!

Anyone can use it + see they do & MANY use that program stupid!

(you FAIL #2)!

---

NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!

(YOU FAIL #3)!

(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...

---

Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...

(you FAIL #4)!

YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!

"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)

FROM-> http://it.slashdot.org/comment...

(you FAIL #5)!

---

WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):

http://forums.pcpitstop.com/in...

(YOU FAIL #7)!

Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!

(You FAIL #8)!

Do YOU have *ANYTHING* like it to YOUR name/credit? No.

(YOU FAIL #9)!

---

Do you write a ware that noted security pros even seconded me on?? No.

(You FAIL #10)!

A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)

APK

P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me) - & you're a "security-engineer"after the above? LOL, not... apk

Re:Bouldin's "security defects" enumerated... apk

[Anonymous Coward]

Ah, resident malware author and all round wanker APK.

Re:Bouldin's "security defects" enumerated... apk

[Anonymous Coward]

Ah an unidentifable not courageous ac loser limey projects he's a wanker!

Yahooooo!

[Anonymous Coward]

I'm having flashbacks of 90's Yahoo boot wars. Malicious text strings, sound bytes, bots, flooding, invite spamming, account locking, and illegal account name trading. Man those were some fun times.

In related news self-driving cars can be hacked

[WillAffleckUW]

Duh.

Exactly!

[Anonymous Coward]

I came here to say exactly this!

Why is everyone misusing the mantra of "always sanitize user input"? This is a generic messaging app. There is no invalid input!

If the application crashes because of assumptions about how to truncate messages (or because of assumptions that truncated messages will always contain complete multibyte sequences) then fix the assumptions!

Overlooked benefits of sanitization

[Anonymous Coward]

it's a parsing bug

Yes! correct!

what difference would sanitizing user input make...

I'm glad you asked! It might make a huge difference to Apple's revenue stream. Clearly Apple hasn't sufficiently monetized SMS/iMessage. Once "sanitization" is allowed -- once content is subject to being modified for conformity -- a whole new world will be within their reach.

"hey, bring some soda for the party" INVALID
"hey, bring some Coke for the party" SANITIZED

</tinfoilcynic>

Cool

[clam666]

Maybe this will also crash the NSA sniffing programs.

Awww: "Poo lil' Bouldin"'s cryin' now? apk

[Anonymous Coward]

YOU brought it on YOURSELF: "eat your words" http://slashdot.org/comments.p... and You're JUST like that OTHER "pseudo security engineer" raymorris I tore to SHREDS here http://it.slashdot.org/comment... with concrete, reputable & reliable, UNDENIABLE sources + facts & truth...

APK

P.S.=> Shouldn't have "tried me" Bouldin - I warned you, way, Way, WAY AHEAD OF TIME what the outcome would be... you FAIL, boy! apk

Re:Awww: "Poo lil' Bouldin"'s cryin' now? apk

[Anonymous Coward]

Get a life.

Re:Awww: "Poo lil' Bouldin"'s cryin' now? apk

[Anonymous Coward]

Bouldin you can't. Apk killed you totally here http://slashdot.org/comments.p... and you did it to yourself as was said.

Re:Awww: "Poo lil' Bouldin"'s cryin' now? apk

[dave420]

You realise we all know that it's you, APK. We know you chime in pretending to be some anonymous supporter of APK, but your writing style gives it away each time. Each and every time. You might as well have written "APK needs help" instead, as it has exactly the same effect, only it's actually honest.

Re:Awww: "Poo lil' Bouldin"'s cryin' now? apk

[Anonymous Coward]

Bouldin needs help after all the mistakes apk caught him in.

C++ Unicode Support

[Anonymous Coward]

C++ has UTF-8 string literals nowadays, you write them as u8"Text"

Re:C++ Unicode Support

[spitzak]

Or as just "text" on non-broken compilers. Compilers that translate the input into UTF-16 as part of the parsing are broken however.

You don't understand security, period

[Anonymous Coward]

"Nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)

FROM -> http://it.slashdot.org/comment...

SpyBot S&D does dimwit

(you FAIL #1)!

Anyone can use it + see they do & MANY use that program stupid!

(you FAIL #2)!

---

NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!

(YOU FAIL #3)!

(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...

---

Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...

(you FAIL #4)!

YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!

"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)

FROM-> http://it.slashdot.org/comment...

(you FAIL #5)!

---

WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):

http://forums.pcpitstop.com/in...

(YOU FAIL #7)!

Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!

(You FAIL #8)!

Do YOU have *ANYTHING* like it to YOUR name/credit? No.

(YOU FAIL #9)!

---

Do you write a ware that noted security pros even seconded me on?? No.

(You FAIL #10)!

A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)

APK

P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me) - & you're a "security-engineer"after the above? LOL, not... apk

laughing

[samantha]

The next time an Apple-head tells you that their walled garden is there to protect the user and improved their experience and make the device more dependable just laugh in their face.

This Prevents the Problem from Occuring

[Anonymous Coward]

The resolution to the problem, until Apple comes up with a fix, is to turn off Preview and Banners in Messages,

Go to Settings > Notifications > Messages

set "Alert Style" to "none' and turn off the switch for "Show Previews".

This will prevent the malicious text from being sent to the screen, which then fails to be able to complete the subroutine, causing a respring that then causes the iPhone to reboot and occasionally crash Messages.

You will still know when you are getting an incoming text from the "ding" [or what ever other noise you have assigned it} and the icon badge showing a new text message has come in... you just won't see a preview of it.

When Apple gets the fix distributed you can turn the setting back on.

Bouldin's "security defects" enumerated... apk

[Anonymous Coward]

"Nobody uses hosts files for security" - by bouldin (828821) on Thursday May 21, 2015 @05:53PM (#49746865)

FROM -> http://it.slashdot.org/comment...

SpyBot S&D does dimwit

(you FAIL #1)!

Anyone can use it + see they do & MANY use that program stupid!

(you FAIL #2)!

---

NOD32/ESET's says hosts = valuable security http://slashdot.org/comments.p... as I also "overturned a SECURITY expert" on a "false positive" on my Hosts program RIGHT there & he gave in!

(YOU FAIL #3)!

(Had to - MalwareBytes' employees VETTED my code & even host + HIGHLY RECOMMEND it for me near top of -> http://hosts-file.net/?s=Downl...

---

Mr. Oliver Day of Symantec/Norton/SecurityFocus does too http://www.securityfocus.com/c...

(you FAIL #4)!

YOU ALSO TRIED TO DENY it & it's there in PLAIN Black & White with his NAME on it!

"I don't see Oliver Day of SecurityFocus on there. Weren't you going to cite him?" - by bouldin (828821) on Thursday May 21, 2015 @08:43PM (#49747763)

FROM-> http://it.slashdot.org/comment...

(you FAIL #5)!

---

WHOSE INITIALS ARE ON THIS - WINNER IN 2008 (added proof of paid for good layered security article):

http://forums.pcpitstop.com/in...

(YOU FAIL #7)!

Via the layered security/defense in depth methods my security guide extolls? I've COMPLETELY shut down your "desperation" RARE edge cases you tried too!

(You FAIL #8)!

Do YOU have *ANYTHING* like it to YOUR name/credit? No.

(YOU FAIL #9)!

---

Do you write a ware that noted security pros even seconded me on?? No.

(You FAIL #10)!

A ware that not only secures you but ALSO SPEEDS YOU UP (e.g. unlike antivirus which is not as effective anymore vs. online modern threats, mine is, stopping sources of infestation BEFORE they can get into you, & IF in you, stopping their communications BACK to C&C servers too!)

APK

P.S.=> LMAO: "Bouldin's GOLDEN top 10 'greatest hits'" (fails vs. me) - & you're a "security-engineer"after the above? LOL, not... apk

AC posts to 'defend yourself' & illogic?... ap

[Anonymous Coward]

"ILLOGIC logic" + ad hominem attacks != a defense vs. http://slashdot.org/comments.p... showing your MASSIVE blunders on SECURITY Bouldin IN YOUR OWN WORDS QUOTED as UNDENIABLE PROOF thereof! as to my statement of FACT on that very account, lol!

(Man - after THAT debacle you brought on YOURSELF? Hey - there's NO WAY you can be a 'security engineer' & educated @ a GOOD school for it - lmao, no way, OR you just SUCK @ the field & are a green, wet-behind-the-ears ROOKIE NOOB... take your pick, either way? YOU FAIL!)

APK

P.S.=> You brought it on yourself vs. "The LORD of HOSTS"... apk

Bouldin's "eating his words" again too... apk

[Anonymous Coward]

MalwareBytes' hpHosts Admin (MalwareBytes TOP employee) hosts & recommends it -> http://hosts-file.net/?s=Downl... & MalwareBytes = BEST antivirus http://www.av-test.org/en/news... UNDER THE SUN!

(Clue: The ,b>man's SEEN & VERIFIED 100% that my sourcecode & program ARE SAFE, even has a copy he keeps for me...)

APK Hosts File Engine 9.0++ SR-2 32/64-bit -> http://start64.com/index.php?o...

Yes - He's a GOOD man & checked it, even helping me disprove SEVERAL false positives (since he knows the major antivirus companies' guys too)

So far, the ones I've turned over "false positives" on are:

Qihoo360
EmsiSoft
ArcaVir
ESET/NOD32 (see below)
Comodo
McAfee
Sophos

* So much for "security engineers" & "experts" like Bouldin especially vs. the likes of them "going MY way", fool...

APK

P.S.=> Bouldin, are YOU senile too? YOU KNOW THIS from Aryeh Goretsky of NOD32/ESET an enterprise class widely recognized GOOD antivirus (he posts on /. too, mind you): He was one I overturned (good guy though on it & FAIR) & HE TOLD YOU "hosts are a GOOD effective defense vs. malware"!

Refresh your FAILING fail memory -> http://slashdot.org/comments.p... , dolt... lol & "EAT YOUR WORDS"...

... apk

Re:Bouldin's "eating his words" again too... apk

[dave420]

If your software could block your spamming, I'd buy it. As it can't, I won't.

Re:Bouldin's "eating his words" again too... apk

[Anonymous Coward]

If what you use did as much as apk's ware you'd answer this http://linux.slashdot.org/comm... but you ran instead after trolling him like the troll you are Dave.

Bouldin's ac "defense" & "projecting"?

[Anonymous Coward]

See subject: You project you care after this http://slashdot.org/comments.p...

* The "unidentifiable ac posts" too? Please... talk about OBVIOUS that's "the best ya got" vs. "The LORD of Hosts" in myself, Bouldin...

APK

P.S.=> Once more: YOU brought all this ON YOURSELF & the Score = APK 16, Bouldin 0 since you can't prove my points on hosts wrong validly & technically AT ALL, lol... some 'security engineer' YOU are (not, no way, not after the above MESS you made of things)... apk

Debilitating exploit

[Anonymous Coward]

Completely possible to keep a phone restarting. Sending the message every 8 seconds results in a reboot loop. The only thing you can do at that point is find a place with no cell service to add the sender to the block list, or from a mac machine running continuity...

Nice job Apple, you have screwed up worse than Windows ever did. You made it possible for non-technical people to take down a system.

just going to leave this here

[Anonymous Coward]

http://pages.telemessage.com/acton/fs/blocks/