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

81–90 of 182 posts

Re: Picking Apart the Crashing iOS String

#81

Post by rlanday »

Manishearth wrote: post #28
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…

Well, the crash occurs for Spotlight without me clicking anything or having any cursors anywhere. But yeah, this is one of my theories about it. One of the previous crashes had to do with an Arabic string which got longer when you truncated it, which made snipping it to display in a notification have bugs. It's interesting to see it's causing a segfault , i'd expect measuring bugs to cause clean assertions or shitty…

UAX 29 doesn't really describe how to handle Indic text very well.

http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries

> Grapheme clusters can be tailored to meet further requirements. Such tailoring is permitted, but the possible rules are outside of the scope of this document. One example of such a tailoring would be for the aksaras, or orthographic syllables, used in many Indic scripts. Aksaras usually consist of a consonant, sometimes with an inherent vowel and sometimes followed by an explicit, dependent vowel whose rendering may end up on any side of the consonant letter base. Extended grapheme clusters include such simple combinations.

> However, aksaras may also include one or more additional prefixed consonants, typically with a virama (halant) character between each pair of consonants in the sequence. Such consonant cluster aksaras are not incorporated into the default rules for extended grapheme clusters, in part because not all such sequences are considered to be single “characters” by users. Indic scripts vary considerably in how they handle the rendering of such aksaras—in some cases stacking them up into combined forms known as consonant conjuncts, and in other cases stringing them out horizontally, with visible renditions of the halant on each consonant in the sequence. There is even greater variability in how the typical liquid consonants (or “medials”), ya, ra, la, and wa, are handled for display in combinations in aksaras. So tailorings for aksaras may need to be script-, language-, font-, or context-specific to be useful.

For example, in Chrome, we added an extra rule to not allow grapheme clusters to be split after Indic virama characters, but later had to modify the rule to not apply to Tamil viramas:

https://chromium-review.googlesource.com/c/chromium/src/+/84...

I don't know the exact cause of this crash, but I can see why Apple might be running into trouble with their logic for these languages. I suspect their algorithm for computing grapheme clusters has a bug causing an inconsistency somewhere.

Re: Picking Apart the Crashing iOS String

#82

Post by rlanday »

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…

Why does any bug result in a crash rather than just random unexpected behavior? There's a limit to how much it's practical to isolate things. For example, Chrome uses different processes to render different web pages, so a crash in one renderer shouldn't affect the others, but it doesn't parse HTML in one process, compute layout in another, execute JavaScript in another, and so on.

Re: Picking Apart the Crashing iOS String

#83

Post by Manishearth »

rlanday wrote: post #81
Manishearth wrote: post #28

Earlier quoted context omitted.

Well, the crash occurs for Spotlight without me clicking anything or having any cursors anywhere. But yeah, this is one of my theories about it. One of the previous crashes had to do with an Arabic string which got longer when you truncated it, which made snipping it to display in a notification have bugs. It's interesting to see it's causing a segfault , i'd expect measuring bugs to cause clean assertions or shitty…

UAX 29 doesn't really describe how to handle Indic text very well. http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries > Grapheme clusters can be tailored to meet further requirements. Such tailoring is permitted, but the possible rules are outside of the scope of this document. One example of such a tailoring would be for the aksaras, or orthographic syllables, used in many Indic scripts. Aksaras usually co…

Yeah, I'm aware, I've been arguing for UAX 29 to handle consonant clusters for a while. The current draft has handling for it: http://www.unicode.org/reports/tr29/tr29-32.html#Virama

However, given that some Brahmic scripts prefer explicit viramas (Malyalam, also Thai I think), this will probably be restricted to Brahmic scripts where joining is always preferred (even if not possible).

I'd been testing UAX 29 stuff out before and Apple seems to follow the spec. For example, Chrome and Firefox seem to do special handling for e.g. flag emoji (distinguishing between regional indicator pairs that render as a flag vs those which don't -- i.e the ones which don't correspond to a country code). But Apple follows the spec rigidly. In particular it does not consider joined consonants to form a single EGC.

I could be wrong on that, though.

Re: Picking Apart the Crashing iOS String

#84

Post by Manishearth »

jcranmer wrote: post #49
Manishearth wrote: post #41

Earlier quoted context omitted.

> 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.

Yeah, the common ones are lam-alif showing لا , and alif-lam-lam-heh showing الله .

But for example خ/ح/چ at the end of a word often form cool ligatures, and the dots on ب/پ/ت often go to interesting places, and سے forms a cool ligature where it uses the other form of the bari yeh and the س forms little teeth marks up top. (Some of these are Urdu-specific; I can read regular Arabic but I have more experience trying to read Urdu calligraphy)

Arabic calligraphy can be pretty involved.

Re: Picking Apart the Crashing iOS String

#86

Post by Manishearth »

tinix wrote: post #57
TazeTSchnitzel wrote: post #7

Earlier quoted context omitted.

There are more possible character sequences than there are stars in the sky.

Why does everyone assume only this one specific character combination causes the issue? Generalists can't generalize, I guess. IOS/OSX are notoriously bad at unicode parsing... These have been problems for YEARS and there are many many known character combinations that cause these types of issues. You seriously think every character has unique code to process it? Of course not... there are general subsystems that pro…

I don't say "unicode" because I'm not certain it has to do specifically with unicode handling, and not a font stack bug (that would occur on other encodings). One of the previous crashes, for example, had nothing to do with unicode -- it had to do with the fact that some arabic strings get larger, visually, when you shorten them. Folks these days say "unicode" when talking about anything relevant to non-Latin text, which munges up the issue, which is why I specifically avoiding saying that word.

BOM or endianness don't seem to be relevant to this bug.

Re: Picking Apart the Crashing iOS String

#87

Post by gok »

evmar wrote: post #79
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…

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.

Re: Picking Apart the Crashing iOS String

#88

Post by jopsen »

evmar wrote: post #79
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…

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…

> PS: If a web page wants to crash, it easily do so by allocating memory in a loop,

isn't this also a bug :)

And probably want we should fix.. I think all browsers are susceptible, though last I tried in Firefox one had to not just allocate but also fill the memory with garbage.

Re: Picking Apart the Crashing iOS String

#89

Post by tomjakubowski »

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.

Rust would significantly help to prevent the escalation of this crash into an RCE.

Re: Picking Apart the Crashing iOS String

#90

Post by mrob »

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.

Fully sandboxing an unsafe renderer might have unacceptable performance. E.g. you'd have to reset the internal state after every call, otherwise invalid text on a phishing website might be able to subvert the renderer to make it render text in the URL bar to read something different.
Post reply on HN