Live data from Hacker News

'Text bomb' is latest Apple bug

bbc.com

81–90 of 113 posts

Re: 'Text bomb' is latest Apple bug

#81

Come to think of it, I believe I've heard of multiple "making the device render this text causes a crash" bugs for Apple devices, but never on any other platforms. Is this type of bug just that much more common on Apple devices, or are there plenty of other cases out there that I just don't know about?

In the 90s, there was a type of AOL punter (basically DOS attacks for AOL users) that would just IM people tons of html tags (eg hello but many more nested tags) and it would freeze aol trying to render it and kick people off the internet. They eventually fixed it.

Re: 'Text bomb' is latest Apple bug

#82
post #55

Anyone got any information on how the text rendering bug actually works (not just hand-waving it away as "oh it's UTF-8")? I can see that the file alternates between segments of: - Repetitions of the glyph "t̴́̍̒", which is a lowercase t with a combining tilde overlay, an acute accent, a vertical line above, and a turned comma above - Random-looking ASCII characters with lots of apostrophes (spelled as ' in the H…

This reminds me of the AOL "punters" we used to make back in the day.

When I was 13 I built a program called "BorG" that did a lot of fun stuff and animations (but the effects didn't freeze people for very long) and chatbots - and I charged $3 as shareware. Or $5 if you really liked it. I got about 100 people mailing me envelopes! And I used to grab some of that money when I wanted to buy pizza or food to hang out. Those were the days.

I wonder if anyone here used it? :)

Re: 'Text bomb' is latest Apple bug

#83

So a crashing bug in the text rendering framework is now worth an article in major publications? I stumbled over two or three of them in the last couple of years while debugging crash reports sent in by customers. Seems that text rendering is hard. Maybe fuzzing CoreText would be a worthwhile target to discover vulnerabilities?

Or take text rendering out of the kernel. The whole device shouldn't restart due to malformed text, that's just sloppy. If Microsoft can do it with Windows then Apple can do it on iOS.

Text rendering does not live in the kernel on macOS or iOS.

Re: 'Text bomb' is latest Apple bug

#84
post #64
post #61

Earlier quoted context omitted.

There's far more risk in software not crashing when it gets malformed or otherwise unexpected input. If an application crashes, it's memory space has been relinquished and its execution process aborted. Yes, something could've been spawned, but... in general crashing when something unexpected comes up is more sensible, desirable behaviour. (Or am I wrong? I'm not a professional programmer. I'm just reasoning from com…

The bug causing this crash might be exploitable. Think of a classic buffer overflow: if you overflow a buffer with all zeroes or random data, then the return address most likely gets overwritten with garbage that doesn't point to valid code or a mapped address and the process crashes. But if the attacker specially chose the data they put in the buffer, then they could choose to overwrite the return address with a val…

Yes I wrote a fuzzer once and was one of the guys that independently discovered the ancient NT 4.0 SP6 ”named pipe” vulnerability. I just tend to think that crashing on unexpected stuff is more sensible than any alternative (a kind of deny-by-default).

Re: 'Text bomb' is latest Apple bug

#85
post #5

Based on a web search, https://bogdanz.me/work/diddu.html might be a working mirror of the proof of concept. It appears to contain a 10MB long UTF-8 mess in both the og:title meta content and in a mailto: link. I'd guess it's supposed to crash iOS apps by either posting that link if it displays links in a thumbnail element using og:title or otherwise by pasting the huge mailto link contained in the webpage, or perhap…

That site caused Firefox 57 (64bit) to lock up on Windows 10... It is an i7, 16 GB total (7 GB free), and an SSD.

I have Firefox 58/64bit/Linux and it slowed down Firefox on my i5 with 16GB ram (2GB free) w/ HDD for about 1 second... it didn't lock it up because any action that I did on firefox was slowed down by about 1 second... other programs seemed fine too.

Re: 'Text bomb' is latest Apple bug

#86
post #74

Earlier quoted context omitted.

I find it unexpectedly hilarious that we now have issues that cannot be fully described without running the risk of crashing our machines. Its as if there are certain unholy words that could cause us to faint if we were to utter them.

Unicode basilisks?

https://en.wikipedia.org/wiki/BLIT_(short_story)

(Langford's story and followup in the links)

Re: 'Text bomb' is latest Apple bug

#87
post #74

Earlier quoted context omitted.

I find it unexpectedly hilarious that we now have issues that cannot be fully described without running the risk of crashing our machines. Its as if there are certain unholy words that could cause us to faint if we were to utter them.

Sounds right out of Gödel, Escher, Bach : Achilles : I see the dilemma now. If any record player—say Record Player X—is sufficiently high-fidelity, then when it attempts to play the song "I Cannot Be Played on Record Player X", it will create just those vibrations which cause it to break...So it fails to be Perfect. And yet, the only way to get around that trickery, namely for Record Player X to be of lower fidelity,…

I'm also thinking Snow Crash.

Re: 'Text bomb' is latest Apple bug

#88
post #53

Earlier quoted context omitted.

and yet again they don't care about older iOS versions for people who don't want to brick their phones with updates

How do you update software without updating it? I'm literally at a loss with how you would like them to resolve it if you don't want to install updates.

I assume he means backporting bugfixes to previous major releases.

Re: 'Text bomb' is latest Apple bug

#89
post #84
post #64

Earlier quoted context omitted.

The bug causing this crash might be exploitable. Think of a classic buffer overflow: if you overflow a buffer with all zeroes or random data, then the return address most likely gets overwritten with garbage that doesn't point to valid code or a mapped address and the process crashes. But if the attacker specially chose the data they put in the buffer, then they could choose to overwrite the return address with a val…

Yes I wrote a fuzzer once and was one of the guys that independently discovered the ancient NT 4.0 SP6 ”named pipe” vulnerability. I just tend to think that crashing on unexpected stuff is more sensible than any alternative (a kind of deny-by-default).

That depends on what is the mechanism that really causes the crash. If the crash on unexpected input is intentional, then all is good. If it is result of some random corruption of something, then you have problem.

Edit: spelling and grammar

Re: 'Text bomb' is latest Apple bug

#90
post #84
post #64

Earlier quoted context omitted.

The bug causing this crash might be exploitable. Think of a classic buffer overflow: if you overflow a buffer with all zeroes or random data, then the return address most likely gets overwritten with garbage that doesn't point to valid code or a mapped address and the process crashes. But if the attacker specially chose the data they put in the buffer, then they could choose to overwrite the return address with a val…

Yes I wrote a fuzzer once and was one of the guys that independently discovered the ancient NT 4.0 SP6 ”named pipe” vulnerability. I just tend to think that crashing on unexpected stuff is more sensible than any alternative (a kind of deny-by-default).

yes, it is, but I think you’ll agree that, without knowing what particularly defines the unexpected it is hard to tell whether it really is crashing on all unexpected stuff or crashing on most, and running the attacker’s code on other.

That’s what should make people worried a bit.

As to fuzzing: given the complexity of the code and the frequency at which bugs are found, I would expect Apple to fuzz their font rendering code 24/7. Do bugs still surface because there are that many, because the whole rendering engine changes that often, because of compiler bugs that do not show up in instrumented code, or because they don’t fuzz it themselves that well?

Post reply on HN