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

171–180 of 182 posts

Re: Picking Apart the Crashing iOS String

#171

Post by ktta »

Manishearth wrote: post #161
ktta wrote: post #122

Earlier quoted context omitted.

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

> 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. weeeellllll, not exactly. For example, spoken Marathi differs considerably from written Marathi, with vowels turning into other vowels, etc. My favorite example is the wo…

I would say the reason is due to people changing the pronunciation over time rather than it being part of the actual grammar.

Take for example Hyderabad. Looking at the Hindi spelling, it should be pronounced Hy-der-aa-bad. But it it pronounced more like Hai-dra-bad.

What I'm saying is that people made those changes which we got so used to in our day to day lives that most now regard them as the 'correct' pronunciation, but it isn't how they were supposed to be.

Re: Picking Apart the Crashing iOS String

#172

Post by Manishearth »

ktta wrote: post #171
Manishearth wrote: post #161

Earlier quoted context omitted.

> 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. weeeellllll, not exactly. For example, spoken Marathi differs considerably from written Marathi, with vowels turning into other vowels, etc. My favorite example is the wo…

I would say the reason is due to people changing the pronunciation over time rather than it being part of the actual grammar. Take for example Hyderabad. Looking at the Hindi spelling, it should be pronounced Hy-der-aa-bad. But it it pronounced more like Hai-dra-bad. What I'm saying is that people made those changes which we got so used to in our day to day lives that most now regard them as the 'correct' pronunciati…

This isn't any different from what happens to pronunciation in English. The difference between English and Indic languages is simply that this has happened a lot more with English (also English kinda gets its words from all over the place)

Pronunciation changes over time. Things which may have been highly phonetic may lose this property over time.

Re: Picking Apart the Crashing iOS String

#173

Post by peoplewindow »

thezoq2 wrote: post #145
dom96 wrote: post #143

Earlier quoted context omitted.

Wouldn't any language with exceptions work here? You just define an indexing operator that throws an exception instead of crashing and handle that exception outside the unicode handling function.

The advantage of rusts error handling is that it is explicit. The compiler knows that a function might result in an error and forces the programmer to deal with it, or pass it along. In an exception based language you might forget to deal with the error and have it crash "higher up" in the code. I also suspect that there might be a performance benefit but I could be completely wrong about that

It's actually slower to not use exceptions and what you describe is not an advantage - exceptions also force you to deal with it or pass it along, if the exception is checked. Bounds check failures aren't of course because that would be incredibly inconvenient and unwieldy, and anyway, you'd just pass it all the way up the stack to some much higher level point which is the only place you can sanely do something (like not render the string at all).

Re: Picking Apart the Crashing iOS String

#174

Post by PopsiclePete »

torstenvl wrote: post #107

I cannot trigger this crash on iOS 10.3.2, despite repeated attempts. I can reliably crash friends' phones by iMessage for all friends on iOS 11. That suggests to me that Apple made changes to CoreText, and did not perform adequate regression testing. All software has bugs. I understand that. But I suspect a large part of power users' and developers' growing frustration with Apple is that they keep introducing severe…

>Honestly, how do you not have a stringent regression testing requirement for changes to the "Core" of the operating system?

I have never had the fortune of working for a manager who prioritized quality over (sometimes imagined even) random dead-lines.

Developers' complaints sound like gibberish to them ("Plus, they always complain, such perfectionists!") and when the shit hits the fan, sometimes years later, well, it might not even be their problem - they've been promoted by then, fucking up another unfortunate team.

Re: Picking Apart the Crashing iOS String

#175

Post by Piskvorrr »

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

Unfortunately, enumerating badness just a stopgap measure - as this seems, so far, to triggered by a specific combination of character classes, it at least possible that there a non-malicious yet crashy string: what now, if the Knights of Ni cannot stand to hear it, but if it a part of the message? The recipient might feel that something not right with the message, and the sender might not even know that the message has censored because a part of it seems to harmful tó intermediary code. (See what I have doing here?)

Re: Picking Apart the Crashing iOS String

#176

Post by Piskvorrr »

paulriddle wrote: post #148
torstenvl wrote: post #107

I cannot trigger this crash on iOS 10.3.2, despite repeated attempts. I can reliably crash friends' phones by iMessage for all friends on iOS 11. That suggests to me that Apple made changes to CoreText, and did not perform adequate regression testing. All software has bugs. I understand that. But I suspect a large part of power users' and developers' growing frustration with Apple is that they keep introducing severe…

Well. Is it really bad to have bugs though? I think it can be good, it's free advertising it gets people's attention for some time. Which is good. Even being hacked is good, you can always turn it into PR. Maybe Apple doesn't need this as much, but 99.9% of other companies do. Perhaps even, security consultancies should provide a new kind of service "fake hacking", which is really a PR campaign. You introduce a bug w…

Ooh, so that's what Therac did? Or perhaps mangle the drive-by-wire software so that the stopping distance is just 10% longer - a few extra feet never killed anyone, eh? Or something non-life-threatening: silently truncate all passwords to 8 characters, not like anyone would abuse this to compromise the user (and it's the user's problem anyway, not the vendor's).

Irony aside: you are, perhaps unintentionally, omitting from your narative all and any damage that would be caused by such a deliberate bug - the vendor is usually the only one who can fix it, but not the only one who can exploit it. Also, what of unpatched devices, and of liability (you are introducing a backdoor, intentionally)? And realistically, your original change might introduce more holes than you bargained for, or the fix might. This is a horrible idea on so many levels, even discounting it's inherent evil.

Re: Picking Apart the Crashing iOS String

#177

Post by torstenvl »

PopsiclePete wrote: post #174
torstenvl wrote: post #107

I cannot trigger this crash on iOS 10.3.2, despite repeated attempts. I can reliably crash friends' phones by iMessage for all friends on iOS 11. That suggests to me that Apple made changes to CoreText, and did not perform adequate regression testing. All software has bugs. I understand that. But I suspect a large part of power users' and developers' growing frustration with Apple is that they keep introducing severe…

>Honestly, how do you not have a stringent regression testing requirement for changes to the "Core" of the operating system? I have never had the fortune of working for a manager who prioritized quality over (sometimes imagined even) random dead-lines. Developers' complaints sound like gibberish to them ("Plus, they always complain, such perfectionists!") and when the shit hits the fan, sometimes years later, well, i…

My comment is slightly rhetorical. "Bad management" and/or "misplaced company values" are the answers, and they're exactly my point. Apple has lost touch with the perfectionism that made it so wonderful.

I think perhaps Tim Cook doesn't realize that Apple didn't create all this emotional loyalty from artists just by having pretty boxes and wallpaper, but by cultivating a kindred spirit with them. And to do that, you have to actually care about the quality of your work on a fundamental level.

Re: Picking Apart the Crashing iOS String

#178

Post by bawana »

I went to the Apple Store in Burlington, MA yesterday (2/16/2018) None of the 'geniuses' there knew about this bug or how to fix it. They reminded me of microsoft drones following a troubleshooting script. 1) Reboot the phone 2) reset the phone 3) do a dfu restore..

After they did this my phone would not recognize its sim card. You see my phone originally had AT&T service. Then I switched to sprint some months back. I guess the dfu restore ended up relocking my phone to AT&T. At least that's what the Apple geniuses said. Then they said I had to go to a sprint store.

This is the first time I was disappointed with Apple's human help. I remember past experiences going in there with a frayed power supply cord - they gave me a new one. On other occasions they replaced my phone when they couldn't fix it. They never spent more than 30 mins trying to fix a problem and always fixed it. Their knowledge was deep. This time their opinions were confabulatory - for example one guy said 'your phone does not have the antennae to work with sprint' EVEN THOUGH I reminded him I walked into the store with a working iPhone using sprint. Another one said that sprint jailbroke my phone and that's how they got it to work. WRONG. Another one said that the phone was 'soft unlocked' and relocked itself after the DFU restore. I felt sad for Apple because I know that's not what they were about.

Then I suggested they replace my phone, the manager lady's eyes bugged out, her voice became stern and said ' There is no scenario where you walk out of here with a different phone'. This is the first time they wasted 5 hours of my time and actually caused me to have more trouble than what I walked in with.

Galaxy here I come. or maybe pixel2

Re: Picking Apart the Crashing iOS String

#179

Post by logicallee »

Piskvorrr wrote: post #175
logicallee wrote: post #149

Earlier quoted context omitted.

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

Unfortunately, enumerating badness just a stopgap measure - as this seems, so far, to triggered by a specific combination of character classes, it at least possible that there a non-malicious yet crashy string: what now, if the Knights of Ni cannot stand to hear it, but if it a part of the message? The recipient might feel that something not right with the message, and the sender might not even know that the message…

So, you're right - and the point you raise at the end (with your illustrative example) is a good one. It would be wrong for HN software to silently not deliver your message to me without telling you - just because tó was on some blacklist for some reason.

If it's possible to write "Your message could not be delivered" when messages match the blacklist (even leaving the sender to guess at what they did wrong) it would be better.

As a practical matter if you haven't built the infrastructure into your clients to tell the sender that their message won't be delivered, none of the choices the platform operator has seem great:

- Silently drop a few kinds of messages without informing sender. Seems bad for the reason you outlined.

- Silently modify messages before delivery, modifying them so they won't crash clients. This seems potentially very wrong.

- Deliver messages even if you know for sure they will crash the client upon view

Doesn't seem great to me either.

I guess the real solution is to have robust forced-upgrade on the client (after all, it's your software, you're responsible for it and if you build it to include updates that it is on you) but some users object to that and I suppose they could be justified - it is also a massive responsibility.

I guess there really aren't any perfect answers here.

Re: Picking Apart the Crashing iOS String

#180

Post by Manishearth »

ollin wrote: post #119

Does anyone have a link to a thorough reverse-engineering of the bug from someone decompiling/source-diving? I tried replicating it on High Sierra out of curiosity (single text file with the broken character, opened in TextEdit to cause a crash) and noticed that the crash doesn't happen in consistently the same way each time (I got 8 crashes in a calloc call in CoreText's OTL::CoverageBitmap::Reset, 4 crashes in a ma…

http://www.cloudscan.me/2018/02/coretext-crash-osx-10133-lld...
Post reply on HN