People interested in this bug may also be interested in "An Introduction to Writing Systems & Unicode." Part 3[1] in particular discusses complex scripts.
Picking Apart the Crashing iOS String
71–80 of 182 posts
Re: Picking Apart the Crashing iOS String
#72Earlier quoted context omitted.
This sequence begins the Telugu word for "knowledge" so maybe someone texted that to someone and it went viral from there. This is, of course, only speculation.
Does the word include the zwnj character? How do you input it?
Huge oversight on my part, the string starts with 0xC1C, 0xC4D, 0xC1E, 0xC3E i.e. without the ZWNJ. I'm stumped
https://en.wiktionary.org/wiki/%E0%B0%9C%E0%B1%8D%E0%B0%9E%E...
Re: Picking Apart the Crashing iOS String
#73Has 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.
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.
This is also an issue in macOS, which is a lot easier to test on.
Re: Picking Apart the Crashing iOS String
#74Earlier quoted context omitted.
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.
The bug is in CoreText, a C library that Apple uses for text rendering.
Re: Picking Apart the Crashing iOS String
#75What 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…
The crash seems to be in CoreText. CoreText is embedded/linked in Messages, Spotlight, Springboard, etc. CoreText is written in C. The fix would be to rewrite CoreText in a memory safe language like Swift. This would be “hard”. Or put CoreText in an XPC container. This would both be “hard” and result in terrible performance. For more details on how hard C, memory management, systems programming, and operating system…
Putting a buggy system in a memory safe environment is certainly not 'the fix'. The fix is to find the precise bug or architectural deficiency and fix it.
Re: Picking Apart the Crashing iOS String
#76What 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…
The crash seems to be in CoreText. CoreText is embedded/linked in Messages, Spotlight, Springboard, etc. CoreText is written in C. The fix would be to rewrite CoreText in a memory safe language like Swift. This would be “hard”. Or put CoreText in an XPC container. This would both be “hard” and result in terrible performance. For more details on how hard C, memory management, systems programming, and operating system…
It's harder than that. Even if you sandbox the code, then it could still happen that some particularly wacky layout code never terminates.
Re: Picking Apart the Crashing iOS String
#77Earlier quoted context omitted.
you'd think you'd want to make sure they didn't cause hard crashes. Any Apple people want to chime in? Why wasn't the general bug -- where there could be even the possibility of a "text crash" -- fixed?
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 language many would call "unsafe." You are now technically wrong, which is the best kind!
Exceptions can be caught in C++, Objective-C, and in Swift. You can even do this for C. There is apparently a history of similar bugs where certain data crash processes in iOS. Depending on how you count, this is either #3 (strings) or #5.
https://www.theverge.com/2018/2/15/17015654/apple-iphone-cra...
Given that, why wouldn't Apple take steps to make sure that certain critical processes are architecturally immune to this sort of thing? Springboard going away is pretty horrendous. Messages app, given that it's a core functionality for a phone, is almost as bad.
if they're using an unsafe language, there's always the possibility of more such issues.
There are software projects where certain things simply can't be allowed to happen, ever. Apparently, Apple isn't operating at that level.
Re: Picking Apart the Crashing iOS String
#78What 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…
The crash seems to be in CoreText. CoreText is embedded/linked in Messages, Spotlight, Springboard, etc. CoreText is written in C. The fix would be to rewrite CoreText in a memory safe language like Swift. This would be “hard”. Or put CoreText in an XPC container. This would both be “hard” and result in terrible performance. For more details on how hard C, memory management, systems programming, and operating system…
There are usually less dramatic fixes like changing all the array accesses to be checked, or putting pages that will trigger a fault around the buffers that the library uses, and handling the fault hitting those buffers generates.
Re: Picking Apart the Crashing iOS String
#79What 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. And then when it goes wrong you're violating array bounds which is a crashable offense.
I agree that it's stupid to have code that causes crashes here. My only defense is that I had a lot of other work to do and complex test pathological cases only affect a fraction of users, none of whom were the ones yelling at me about other bugs. I am rooting for Servo, where they are using a language that defends against bad programmers like me.
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. Of course crashes can often be escalated into RCE, but the Chrome sandbox was there to mitigate that.
Re: Picking Apart the Crashing iOS String
#80Earlier quoted context omitted.
The crash seems to be in CoreText. CoreText is embedded/linked in Messages, Spotlight, Springboard, etc. CoreText is written in C. The fix would be to rewrite CoreText in a memory safe language like Swift. This would be “hard”. Or put CoreText in an XPC container. This would both be “hard” and result in terrible performance. For more details on how hard C, memory management, systems programming, and operating system…
Putting a buggy system in a memory safe environment is certainly not 'the fix'. The fix is to find the precise bug or architectural deficiency and fix it.
It's easier to failsafe something than make things perfect
Even better, when you failsafe you plan for the (unknown) future.
That's why we have circuit breakers, hydraulic and electric fuses, pressure relief valves, etc. Because no one thinks they can know all things that can go wrong in the future (with catastrophic consequences) and plan for that