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

151–160 of 182 posts

Re: Picking Apart the Crashing iOS String

#151

Post by beojan »

thezoq2 wrote: post #146
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.

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.

So it's really no better than C++, where containers have a `.at` function that does bounds-checking and throws an exception if out of bounds.

Re: Picking Apart the Crashing iOS String

#152

Post by dkarl »

Manishearth wrote: post #105
dkarl wrote: post #43

Earlier quoted context omitted.

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.

No, the crashy Bengali sequences are reasonable to have; like I mentioned ZWNJ has semantic meaning with bengali vowels.

I am judging by this statement in the blog post:

In Bengali and Oriya specifically, a ZWNJ can be used to force a different vowel form when used before a vowel (e.g. রু vs র‌ু), however this bug seems to apply to vowels for which there is only one form

This seems to say that the ZWNJ has a meaning before vowels that have different forms, but the crash happens with vowels that only have one form, where the ZWNJ has no effect. Maybe I am misreading?

Re: Picking Apart the Crashing iOS String

#154

Post by vxNsr »

crumbshot wrote: post #99
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…

Someone posted a crash report: https://gist.github.com/steipete/a759b56dc1b5d94ba5b3c03ddd0... Looks like a heap corruption, leading to a failure when allocating memory later on: Application Specific Information: abort() called *** error for object 0x604000673e00: Invalid pointer dequeued from free list Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff73a30e3e __pthread_kill…

This char string will crash safari on my up to date Mac.

Re: Picking Apart the Crashing iOS String

#155

Post by LeifCarrotson »

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…

> And then when it goes wrong you're violating array bounds which is a crashable offense.

Why is this a crashable offense? Probably a bit naive as a C# application developer, not a system developer, but shouldn't all this code be in the equivalent of a try/catch? If it throws an out-of-bounds error, just log the error and return, rendering what you've got.

Re: Picking Apart the Crashing iOS String

#156

Post by Manishearth »

dkarl wrote: post #152
Manishearth wrote: post #105

Earlier quoted context omitted.

No, the crashy Bengali sequences are reasonable to have; like I mentioned ZWNJ has semantic meaning with bengali vowels.

I am judging by this statement in the blog post: In Bengali and Oriya specifically, a ZWNJ can be used to force a different vowel form when used before a vowel (e.g. রু vs র‌ু), however this bug seems to apply to vowels for which there is only one form This seems to say that the ZWNJ has a meaning before vowels that have different forms, but the crash happens with vowels that only have one form, where the ZWNJ has no…

Yeah, you are.

I'm saying that this crash _also_ applies to vowels with one form.

র‌ু was the original Bengali crash, and that has two forms. I'm saying it's less likely to be related to the zwnj-vowel interaction because it also occurs for vowels where such interaction doesn't exist.

Re: Picking Apart the Crashing iOS String

#157

Post by Manishearth »

imron wrote: post #130
Manishearth wrote: post #103

Earlier quoted context omitted.

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.

If you use Firefox or Chrome you can change default font sizes in preferences on a per-language basis. You can also change the default font used. It's pretty useful, lets me replace shitty system fonts with better ones and also bump up the size for Chinese.

It does not apply to text using absolute font-sizes however, just text that uses things like font-size:medium (or inherits the document default font size, which is also medium)

Re: Picking Apart the Crashing iOS String

#158

Post by Manishearth »

LeifCarrotson wrote: post #155
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…

> And then when it goes wrong you're violating array bounds which is a crashable offense. Why is this a crashable offense? Probably a bit naive as a C# application developer, not a system developer, but shouldn't all this code be in the equivalent of a try/catch? If it throws an out-of-bounds error, just log the error and return, rendering what you've got.

Systems languages like C++ and C don't usually do error handling that way. You do have try/catch in C++ but folks often disable it.

And even if you don't disable it, out of bounds array access will cause segfaults, not exceptions (unless you're using some abstraction over arrays).

Re: Picking Apart the Crashing iOS String

#159

Post by Manishearth »

logicallee wrote: post #149
semi-extrinsic wrote: post #139

Earlier quoted context omitted.

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

Though it seems like providers have not yet figured out the full set of crashy things (an overly conservative thing to do would be to filter out zwnjs in for the three languages listed). Twitter blocks the original one but not any Bengali variants; গ্য + zwnj + a bengali vowel will still crash it.

Re: Picking Apart the Crashing iOS String

#160

Post by Manishearth »

jsjohnst wrote: post #46
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.

Not Korean, but the Korean case is different, a bit. Korean syllable blocks are viewed as syllable blocks -- a new concept, whereas Indic consonant clusters are simultaneously viewed as letters of their own and fundamentally composed of more letters.
Post reply on HN