Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Picking Apart the Crashing iOS String

manishearth.github.io

Post reply on HN
Print view View original

141–150 of 182 posts

Re: Picking Apart the Crashing iOS String

#141

Post by zatkin »

arvinsim wrote: post #118
torstenvl wrote: post #107

I cannot trigger this crash on iOS 10.3.2, despite repeated attempts. I can reliably crash friends' phones by iMessage for all friends on iOS 11. That suggests to me that Apple made changes to CoreText, and did not perform adequate regression testing. All software has bugs. I understand that. But I suspect a large part of power users' and developers' growing frustration with Apple is that they keep introducing severe…

> Honestly, how do you not have a stringent regression testing requirement for changes to the "Core" of the operating system? By not managing expectations and deadlines properly. Especially if schedules are overriden from a manager who is not aware of the ramifications of changing something in the core.

And this is about to change, according to some recent news: https://www.bloomberg.com/news/articles/2018-02-12/how-apple...

Re: Picking Apart the Crashing iOS String

#142

Post by zxxon »

pjmlp wrote: post #140
zxxon wrote: post #138

Earlier quoted context omitted.

Huh? C is fast (compared to Swift) because using it doesn't imply sprinkling lots of sugar (like ARC) into the resulting machine code. Simpler languages like Fortran can turn into even faster code than a C implementation. UB optimizations aren't that relevant for real-world performance.

Code generated by C compilers is fast in 2018. Code generated by C compilers for C64, Spectrum, Atari, Atari ST, Amiga, Mac, CP/M, MS-DOS, Windows 3.x, Nintendo, MegaDrive,... systems meant many times the code would be 80% like this: void some_func(/* params */) { asm { /* actual "C" code as inline Assembly */ } } Lots of Swift sugar also gets optimized away, and there is plenty of room to improvement. The code that…

Why bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly.

>> The code that current C compilers don't generate, many times is related to taking advantage of UB

Compilers are really smart in optimizing things that aren't relevant to the real world.

For example, this code would reduce to "return 32" in most modern compilers:

  int return32(){
    int x=1;
    for (int i=0; i
Does that make impact in real-world code? Almost certainly not, it's a contrived case. Most UB cases fall into the same category.

>> They also generate extra code for handling stuff like floating point emulation though.

Not necessarily.

Re: Picking Apart the Crashing iOS String

#143

Post by dom96 »

gok wrote: post #87
evmar wrote: post #79

Earlier quoted context omitted.

I wrote some similar bugs to this in the complex text handling in Chrome. In text layout you do a lot of indexing into various arrays -- like the array of code units of the input string, or an array of metadata collected per-code point, or an array of data collected per-grapheme. Oftentimes those arrays are all the same length (like in simple text like Chinese) and mixing up which index to use where is no problem. An…

How would using Rust help this case? An out of bounds array would still lead to a crash, and thus a DoS in the crashing application. You could sandbox the text rendering into its own process to solve that, but then you could do that using unsafe languages anyway.

Wouldn't any language with exceptions work here? You just define an indexing operator that throws an exception instead of crashing and handle that exception outside the unicode handling function.

Re: Picking Apart the Crashing iOS String

#144

Post by annabellish »

stcredzero wrote: post #77
ghusbands wrote: post #62

Earlier quoted context omitted.

You realize that there's no such thing as "don't ever crash" fix, right? Maybe they added some defensive code and maybe they didn't, but if they're using an unsafe language, there's always the possibility of more such issues.

You realize that there's no such thing as "don't ever crash" fix, right? You answered universally for all contexts, ever, everywhere. That's a usually quite a foolish thing to do. In ObjectStudio Smalltalk, there was actually a place where you could define an empty lambda as the "top-level" exception handler. Once you did that, all Smalltalk exceptions did nothing. There you go: a "don't ever crash" fix, in a languag…

Yikes. Instead of having heap corruption which immediately causes a hard failure, you want heap corruption which is silently ignored and (?????) happens on a device in which people access banking and all their personal identity stuff?

Re: Picking Apart the Crashing iOS String

#145

Post by thezoq2 »

dom96 wrote: post #143
gok wrote: post #87

Earlier quoted context omitted.

How would using Rust help this case? An out of bounds array would still lead to a crash, and thus a DoS in the crashing application. You could sandbox the text rendering into its own process to solve that, but then you could do that using unsafe languages anyway.

Wouldn't any language with exceptions work here? You just define an indexing operator that throws an exception instead of crashing and handle that exception outside the unicode handling function.

The advantage of rusts error handling is that it is explicit. The compiler knows that a function might result in an error and forces the programmer to deal with it, or pass it along.

In an exception based language you might forget to deal with the error and have it crash "higher up" in the code.

I also suspect that there might be a performance benefit but I could be completely wrong about that

Re: Picking Apart the Crashing iOS String

#146

Post by thezoq2 »

gok wrote: post #87
evmar wrote: post #79

Earlier quoted context omitted.

I wrote some similar bugs to this in the complex text handling in Chrome. In text layout you do a lot of indexing into various arrays -- like the array of code units of the input string, or an array of metadata collected per-code point, or an array of data collected per-grapheme. Oftentimes those arrays are all the same length (like in simple text like Chinese) and mixing up which index to use where is no problem. An…

How would using Rust help this case? An out of bounds array would still lead to a crash, and thus a DoS in the crashing application. You could sandbox the text rendering into its own process to solve that, but then you could do that using unsafe languages anyway.

An out of bounds access doesn't have to lead to a crash. For most types in the standard library, the [] operator crashes but the "get" function returns Result which you can deal with.

Re: Picking Apart the Crashing iOS String

#147

Post by pjmlp »

zxxon wrote: post #142
pjmlp wrote: post #140

Earlier quoted context omitted.

Code generated by C compilers is fast in 2018. Code generated by C compilers for C64, Spectrum, Atari, Atari ST, Amiga, Mac, CP/M, MS-DOS, Windows 3.x, Nintendo, MegaDrive,... systems meant many times the code would be 80% like this: void some_func(/* params */) { asm { /* actual "C" code as inline Assembly */ } } Lots of Swift sugar also gets optimized away, and there is plenty of room to improvement. The code that…

Why bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly. >> The code that current C compilers don't generate, many times is related to taking advantage of UB Compilers are really smart in optimizing things that aren't relevant to the…

> wWhy bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly.

To clear up the myth among young generations that C compilers always generated fast code, regardless of the platform.

As for something more modern, in 1998, C code quality was still at a similar level to other system's languages, before they started to fade away thanks to the increase in UNIX, Linux and BSD adoption

For example, given that Delphi and C++ Builder share the same backend, their generated code was quite similar, even if it would require disabling some of the Delphi's security checks.

> Not necessarily.

Sure, it all depends on the CPU being targeted.

Re: Picking Apart the Crashing iOS String

#148

Post by paulriddle »

torstenvl wrote: post #107

I cannot trigger this crash on iOS 10.3.2, despite repeated attempts. I can reliably crash friends' phones by iMessage for all friends on iOS 11. That suggests to me that Apple made changes to CoreText, and did not perform adequate regression testing. All software has bugs. I understand that. But I suspect a large part of power users' and developers' growing frustration with Apple is that they keep introducing severe…

Well. Is it really bad to have bugs though? I think it can be good, it's free advertising it gets people's attention for some time. Which is good. Even being hacked is good, you can always turn it into PR. Maybe Apple doesn't need this as much, but 99.9% of other companies do. Perhaps even, security consultancies should provide a new kind of service "fake hacking", which is really a PR campaign. You introduce a bug which is kind of severe but not really detrimental. It's better if it allows to compromise a user. Publish tutorials, videos, tweet about it, create panic, make it cool to abuse the system. Give it a name, create a dedicated web page. And then you squash the bug, you fix it. People will remember that you fix stuff, so your company and product must be good because you care.

Re: Picking Apart the Crashing iOS String

#149

Post by logicallee »

semi-extrinsic wrote: post #139
lloeki wrote: post #95

Earlier quoted context omitted.

From what I gathered so far this doesn't hit the kernel but the process. It seems to turn out that on iOS one of such processes happens to be Springboard, hence the UI (but not the kernel) gets a kick and restarts. Maybe I missed something though.

That's right, there's no kernel crash AFAICT. Pissed my niece the hell off though, that I could remotely disable her Messenger.

Well she's right to be pissed if you did that.

On the other hand I had the same thought (but better self-restraint than you) - however I was thinking "nah, scrubbing bad messages server side is just an s/badstring// and I am sure the major non-encrypted messenger apps (where the server knows the strings) added that server-side, so people couldn't crash their contacts' apps, which the app company might get blamed for. This kind of hotfix shouldn't have negative effects, I'm sure there are already a few server-side manipulations of text (stuff like adding a space to very long lines, maybe a blacklist of certain malicious URL's that sort of thing.)

So I'm surprised your message was delivered as sent (if it's not encrypted end to end), unless you did this right when the news broke.

Re: Picking Apart the Crashing iOS String

#150

Post by signal11 »

userbinator wrote: post #125
jrochkind1 wrote: post #31

What I'm really curious about is how bugs/errors in the iOS typesetting algorithm result in a crash, rather than just wrong or nonsense typesetting -- and how the last time this happened, they appearently just fixed the specific case, but not the ability of bugs/errors in the typesetting algorithm to crash the system. I am not surprised there will be errors/bugs in the typesetting algorithm, as the OP demonstrates, t…

this stuff is extraordinarily complicated to do for every language/all of unicode. Perhaps this sounds a bit Anglocentric, but isn't it unfortunate that this string crashes the devices even of those people who have never heard of and likely won't ever need to use the language it's written in? The majority of people use a tiny fraction of Unicode --- the parts that cover the languages they use; everything else is usel…

ಠ_ಠ

Many users in latin-alphabet locales use other character-sets all the time ¯\_(ツ)_/¯

[This post brought to you by KANNADA LETTER TTHA and KATAKANA LETTER TU.]

Post reply on HN