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

121–130 of 182 posts

Re: Picking Apart the Crashing iOS String

#121

Post by Manishearth »

tinix wrote: post #116
Manishearth wrote: post #86

Earlier quoted context omitted.

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, w…

The problem is not with the characters themselves though, it's with how CoreText processes and parses the unicode symbols. Don't get me wrong, I know fonts can be malicious, even... but given the history[0] here, with these unicode[1] issues... I think it's pretty safe to say the issue is not with a specific font, per-se, but with CoreText and unicode parsing. For example, when I ran OSX on my old macbook pro, I used…

I'm not talking about malicious fonts, but font stacks are complicated regardless of the encoding being fed in.

You seem to think I'm blaming it on the font. I'm not. I'm blaming it on the font stack (CoreText)

I avoided using the term "unicode" to refer to a bug in the font stack because font stack bugs don't always have to be specific to unicode.

You keep saying "unicode parsing"; that's a meaningless term in this context.

> Yet on your blog you allude to just that with the left/right comments, though, to be fair, you state that you really don't know the problem:

That doesn't have to do with endianness or BOM, that's a totally different kind of ordering. It's ordering of the code points, not the code units.

> This is claimed to be a dissection of the issue, but there is not even a stack trace present, and yet you joke about that...

It's a dissection of the string. Not a full debugging of the issue.

Re: Picking Apart the Crashing iOS String

#122

Post by ktta »

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…

Telugu is my native language. Here's how I learnt it.

There's two types of letters. One type is used as an addendum to the other type. The first type are called vowels and the second consonants (I'd say that's mischaracterization but whatever). In this[1] picture, the top half of the alphabets are the type which are the addendum part, and the bottom part are the 'primary' ones.

So how it goes is that one of the bottom always comes with one on the top. Most often it tends to be the very first vowel, which is pronounced 'a:', and it is the default way letters are learnt(pronunciation chart[2] for each of the vowels).

So each of the consonants (the bottom part) can be used with any one on the top. Let's take the very first consonant. It is pronounced 'ka'(because by default, consonants are accompanied with the first 'vowel' which is 'a:'). Now, lets take a look at the the bottom part of picture [2]. That same consonant is pronounced differently when accompanied with each of the first one. For example: kaa, kee, kuu, etc. The first half the the pronunciation is the same, but the second half, is replaced which whatever vowel's symbol is attached as an addendum. Also notice the the center part of the alphabet hardly changes visually between changes in vowels.

Not to throw a lot at once, but there's another part. Each of the consonants can again be used as addendum to any other consonant (which always comes with a vowel). Take a look at this[3]. Notice the little tick at the top you saw in [2] is still there? That picture contains the letters 'ka', which each of the consonants being tacked on. The vowel is always still there. That's because, as I said consonants always come with a vowel attached. The consonant addendum is optional though.

Congratulations, you can now pronounce (almost all of) Telugu (and almost any Devanagari script using this same play book). It is because these scripts are deterministic, and there is a single pronunciation unlike English and many other languages.

[1]:https://www.telugucorner.com/images/aksharamulu.jpg

[2]: https://www.omniglot.com/images/writing/telugu_vwl.gif

[3]: https://www.omniglot.com/images/writing/telugu_conjuncts.gif

Re: Picking Apart the Crashing iOS String

#123

Post by userbinator »

enzanki_ars wrote: post #65
gsich wrote: post #60

Earlier quoted context omitted.

Use Hackintosh or a VM.

Given that Apple does not design their OS to work on anything but their hardware, the pain I would incur trying to set up either option is just not worth it. Unless someone has published a stable and updated pre-built VM for macOS, it just seems like nothing but trouble.

Not so long ago I was pleasantly surprised by how easy it was to setup a Hackintosh VM in VirtualBox --- all I did was create a VM with the default settings, add the all-important SMCDeviceKey, insert a completely stock El Capitan ISO, and it booted up and installed on the first try. All on hardware that was as non-Apple as it gets (a ThinkPad.)

The only thing that I found somewhat confusing and perhaps a bit un-Apple was the fact that the installer would not prompt me to partition and format the HDD first, but was perfectly happy to let me try to select and then fail to install onto the install media itself (with an odd "not enough space" message); I had to use the Disk Utility to do that before going back to the installer. I've always wondered why --- even Windows' installer includes partitioning and formatting as one of its steps.

Re: Picking Apart the Crashing iOS String

#124

Post by jcheng »

Manishearth wrote: post #83
rlanday wrote: post #81

Earlier quoted context omitted.

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 o…

Nit: it's "Malayalam". I noticed the same typo in your blog post.

Re: Picking Apart the Crashing iOS String

#125

Post by userbinator »

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 useless to them --- or in cases like this, even a liability. It would greatly reduce the number of affected devices, especially with bugs like this having possible security implications, if the text rendering system were more modular and perhaps divided into separate optional components: Latin (maybe not optional), CJK, and other complex scripts. I know Windows has/had a similar feature:

https://msdnshared.blob.core.windows.net/media/TNBlogsFS/Blo...

This way, those who have no need for anything other than Latin scripts get the simple and hopefully much less buggy rendering algorithm, while those who do need the others can do so without unnecessarily burdening everyone else.

Re: Picking Apart the Crashing iOS String

#126

Post by cakoose »

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, so making web pages that crash isn't as exciting as it is in Core Text in general.

To allocate memory in a loop, you need some control over the JS. Websites try hard not to serve untrusted JS.

But websites serve untrusted text without a second thought. For example, I could post a comment on a news article and cause the article to be unviewable by anyone with a vulnerable browser.

Re: Picking Apart the Crashing iOS String

#127

Post by Manishearth »

jcheng wrote: post #124
Manishearth wrote: post #83

Earlier quoted context omitted.

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 o…

Nit: it's "Malayalam". I noticed the same typo in your blog post.

lol I keep making this mistake. Thanks.

Re: Picking Apart the Crashing iOS String

#128

Post by GirlsCanCode »

tomjakubowski wrote: post #89
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.

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

The Rust zealots are awake!

Re: Picking Apart the Crashing iOS String

#129

Post by Someone1234 »

Manishearth wrote: post #103
Someone1234 wrote: post #94

Earlier quoted context omitted.

As someone who can read both Devanagari and English/Latin script, I'm just curious, when you read Devanagari does the text size need to be larger for good comprehension? There seems more subtlety with the word structure, like tiny little flicks which seem to have significant meaning. While Latin-like script has characters like the comma/full-stop, and modifiers like the dot on the i, these are far rarer than Devanaga…

Not really, I can read at normal text sizes. But it is somewhat annoying (much like how tiny English can be readable but annoying to read) and used to have my default font size bumped up by one in my browser. I currently have it bumped up quite a bit for Chinese because I really have trouble with the "tiny little flicks" problem in Chinese. The consonants of Devanagari are easy to tell apart; they are pretty differen…

That was really interesting. Thank you for the insight!

Re: Picking Apart the Crashing iOS String

#130

Post by imron »

Manishearth wrote: post #103
Someone1234 wrote: post #94

Earlier quoted context omitted.

As someone who can read both Devanagari and English/Latin script, I'm just curious, when you read Devanagari does the text size need to be larger for good comprehension? There seems more subtlety with the word structure, like tiny little flicks which seem to have significant meaning. While Latin-like script has characters like the comma/full-stop, and modifiers like the dot on the i, these are far rarer than Devanaga…

Not really, I can read at normal text sizes. But it is somewhat annoying (much like how tiny English can be readable but annoying to read) and used to have my default font size bumped up by one in my browser. I currently have it bumped up quite a bit for Chinese because I really have trouble with the "tiny little flicks" problem in Chinese. The consonants of Devanagari are easy to tell apart; they are pretty differen…

> I currently have it bumped up quite a bit for Chinese

It really annoys me when websites/apps keep the same font size for Chinese that they use for English. 8pt Chinese is awful to read.

Post reply on HN