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

41–50 of 182 posts

Re: Picking Apart the Crashing iOS String

#41

Post by Manishearth »

jcranmer wrote: post #18
brian-armstrong wrote: post #4

The broader question is, I think, how can any textual sequence cause a crash. Text should be regarded very skeptically by the text renderer. What could this be doing that it invokes a crash? Where else is this team not being careful? It reeks of process problems.

Latin text gives people a misleading idea as to how simple text is. For Latin, each character is generally an independent unit with independent metrics isolated from its environment, with a small set of exceptions to this rule (ligatures). East Asian ideographs bring up interesting questions about what constitutes a character, with Unicode "solving" the problem by saying "every distinct rendering is a distinct charac…

> Indic scripts go far beyond this by needing to treat entire consonant clusters as single rendered glyphs.

FWIW, Arabic does this too, just that most default Arabic fonts don't. https://www.google.com/get/noto/#nastaliq-aran contains a bunch of specialized ligatures (and is overall a very complicated font).

I always say: There's a reason a lot of the folks working on font shaping are Persian/Arabic speakers :)

Re: Picking Apart the Crashing iOS String

#42

Post by blackflame7000 »

Diggsey wrote: post #11

My guess would be that it's some aspect of measuring the text that is causing the crash: when you click in an editable text box, there is code to track down where the cursor should be placed. This is done by measuring various sub-strings of the whole line. If measuring the sub-strings gives surprising results (sub-strings being visibly longer for example), this could cause the algorithm to fail in any number of inter…

Auto-Correct Perhaps?

Re: Picking Apart the Crashing iOS String

#43

Post by dkarl »

jcranmer wrote: post #18
brian-armstrong wrote: post #4

The broader question is, I think, how can any textual sequence cause a crash. Text should be regarded very skeptically by the text renderer. What could this be doing that it invokes a crash? Where else is this team not being careful? It reeks of process problems.

Latin text gives people a misleading idea as to how simple text is. For Latin, each character is generally an independent unit with independent metrics isolated from its environment, with a small set of exceptions to this rule (ligatures). East Asian ideographs bring up interesting questions about what constitutes a character, with Unicode "solving" the problem by saying "every distinct rendering is a distinct charac…

So far, if I understand correctly, nobody knows of a sequence of characters you could write down in any language that would trigger a crash when encoded in Unicode in a straightforward way. That suggests that the invariant being assumed may come, ironically, from a deep understanding of the scripts rather than ignorance.

Re: Picking Apart the Crashing iOS String

#44

Post by minimaxir »

gwern wrote: post #35
minimaxir wrote: post #30

Earlier quoted context omitted.

A good example of test sequences causing weird behavior/crashes are RTL languages (like Hebrew and Arabic) and CJK characters (Chinese/Japanese/Korean), which have UI implications as well. While working at Apple in Software QA, both of these cases in part inspired me to create the Big List of Naughty Strings years ago: https://github.com/minimaxir/big-list-of-naughty-strings

Are you adding OP's strings to the list?

After the crashes are fixed on iOS, sure.

Re: Picking Apart the Crashing iOS String

#45

Post by kibwen »

sigjuice wrote: post #27
kibwen wrote: post #12

Has anyone yet traced this to a specific syscall? Seems like the perfect opportunity for whipping up a fuzzer to spit arbitrary unicode into the system and see what else crashes.

Most likely none of this involves syscalls directly. Are there any syscalls that concern themselves with unicode, besides perhaps filesystem related syscalls?

Yeah I'm being a bit loose in my terminology, by "syscall" I really just mean tracing it to some specific function call(s) in a vendor-provided library (as I assume the problem must be on Apple's end) to expedite the process of fuzzing.

Re: Picking Apart the Crashing iOS String

#46

Post by jsjohnst »

kens wrote: post #38

Not directly related to the crash, but I have a question about Telugu and similar scripts: How do their speakers think about the structure of the script? Do they consider each vowel and consonant a separate "thing" that just happens to get written as a complex grapheme, or is the grapheme the unit you think about and it just happens to be made up of smaller parts? I.e https://en.wikipedia.org/wiki/Telugu_script#Conso…

I’m curious too. Koreans, for example, think in an alphabet similar to ours (actually fewer letters), but it forms into a grapheme. I don’t think that is the case here, but don’t know for sure.

Re: Picking Apart the Crashing iOS String

#47

Post by enzanki_ars »

thephyber wrote: post #32
enzanki_ars wrote: post #25

Earlier quoted context omitted.

Would that even be possible on iOS for non Apple employees? My idea would be just to create a program that continually creates Unicode strings and display them on screen with a pause before creating and displaying the next. Record the screen and see if any thing exciting happens. Would never end, if there was a SETI @ Home style program for it with insentives for running it would be cool.

> Would that even be possible on iOS for non Apple employees? iOS emulator (part of XCode) might be enough.

Ah. Forgot that existed for some reason. (Windows/Linux user that gets screwed out of programming for my own phone. Hate that....)

Re: Picking Apart the Crashing iOS String

#49

Post by jcranmer »

Manishearth wrote: post #41
jcranmer wrote: post #18

Earlier quoted context omitted.

Latin text gives people a misleading idea as to how simple text is. For Latin, each character is generally an independent unit with independent metrics isolated from its environment, with a small set of exceptions to this rule (ligatures). East Asian ideographs bring up interesting questions about what constitutes a character, with Unicode "solving" the problem by saying "every distinct rendering is a distinct charac…

> Indic scripts go far beyond this by needing to treat entire consonant clusters as single rendered glyphs. FWIW, Arabic does this too, just that most default Arabic fonts don't. https://www.google.com/get/noto/#nastaliq-aran contains a bunch of specialized ligatures (and is overall a very complicated font). I always say: There's a reason a lot of the folks working on font shaping are Persian/Arabic speakers :)

I didn't know about Arabic having more ligatures than a few common ones (e.g., Allah).

That said, there's a reason that I want to learn Arabic.

Re: Picking Apart the Crashing iOS String

#50

Post by jcranmer »

brian-armstrong wrote: post #8
spaceywilly wrote: post #5

Earlier quoted context omitted.

My question was, why was there not a unit test for this? It seems like it would be trivial to step through every character combination for each language they support and make sure it doesn't cause a crash.

I don't know if I agree with that. The sequence here is something like 5 or 6 characters. There's some tens of thousands of unicode characters, which suggests something like (10000) 6 combinations to test. Fuzzing might be more fruitful, but even then I'm skeptical it can find obscure crashes. There's no replacement for defensive programming.

Concolic execution as a form of whitebox fuzzing is a very effective way to generate these kinds of crashes, especially if the crash is simple enough that it's the input stream that's generating it, and not positioning the program into a very specific state to get this kind of input string to crash it.
Post reply on HN