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 HTML)
- Short sequences of spaces, non-breaking spaces, and zero-width joiners
- Occasional emoji
The "t̴́̍̒"s manage to slow down my terminal and glitch its rendering a bit. Is it that they're unexpectedly tall? But we've had zalgo-text for a while and it hasn't actually crashed devices.
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.
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, even more directly ensures that it is not Perfect. It seems that every record player is vulnerable to one or the other of those frailties, and hence all record players are defective. (p77)
I don't think anyone ever intended for text rendering to be a "sufficiently powerful formal system" like second-order logic, number theory, or like Hofstadter says the human brain is. I would hope that, in the absence of bugs, rendering text X on computer system Y would be a plain old computable function.
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.
Okay, I have at least a guess about the type of thing that's going on, after seeing what it did to Firefox (which it at least didn't crash).
Various GUI elements such as title bars, tooltips, and thumbnails of links to Web pages, will try to fit the text they're given in a certain amount of space. If the text is too wide, it'll show some amount of text followed by "...". (I wonder if they're prepared for the text to be too tall.)
I saw Firefox rendering the long sequence of t̴́̍̒ characters in the mailto: link. It was being kerned in a way that made it nearly a solid black smear of pixels.
My guess is that apps are trying to determine how much of this text to show to fit within a certain width (and height?), and this text messes with a kerning algorithm in a way that makes it computationally very difficult to decide. I still don't know what's going on with the rest of the text, and why it can read 20 MB of text without making a final decision.
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?
Not just simple text, it's UTF-8. Rendering these UTF-8 "text bombs" seems to DoS several applications. This particular one crashes the messages app in iOS, crashes the tab in Chrome, and locks up FireFox. It also crashes several text editors which support UTF-8. Opens quickly in notepad, but takes several minutes in wordpad and it very laggy when scrolling.
There have been numerous crash-bugs for the Windows font renderer, and even security exploits using it (especially before windows 10, as earlier than that font rendering was performed in the kernel's space rather than user-land). I wouldn't be surprised to learn of issues (at least of the falling over variety) in common Linux rendering engines and for other OSs too.
FreeType used to ignore TrueType hint bytecode to avoid infringing on related patents, but those patents expired in 2010 and FreeType's interpreter is now enabled by default.
More of a potential problem than an existing one but I know potential issues have shapped how fonts are delivered on Android :
A recent version of the OS + support lib added the possibility to reference a font in your app in order to have it downloaded (if necessary) and applied to your views.
IIRC It is restricted to one font delivery system only allowing fonts available on Google fonts. Not because of a power grab, but because fonts are not just graphics but also run a bunch of code.
So unrestricted access would have been a big security hole.
If you want more details, the font team talked about it at length during an Android Developer Backstage podcast episode.
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 <h3><h3><h3>hello</h3></h3></h3> but many more nested tags) and it would freeze aol trying to render it and kick people off the internet. They eventually fixed it.
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 perhaps only the e-mail address.
Same for me, except on Windows 7. CPU spiked to 100% and I warmed up my hands with the extra heat :). Closing the tab and waiting a minute or so (the usual thing I do for cpu/memory intensive pages like this) didn't work. I had to completely restart Firefox to get it back to normal.
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.
The linked blog assures people that this can't be used to access data. Once something is crashing an app/OS, can you really say that? I mean, can you be sure there's no one clever enough to capitalize on the underlying software error leading to this state?
Don’t know any details about this one, but some bugs are just not exploitable beyond denial of service. If all you can do is provoke an action that makes the OS kill the process immediately, for example. Like a null pointer dereference under the right circumstances.
That would be a general issue with app crashing, and a huge deal worth it’s own series of articles. iOS’ sandboxing makes it so unlikely this exists, it’s not worth mentioning and the sensational writing might be counterproductive to getting the actual issue fixed. To use an analogy, it’d be like mentioning that someone could hack Google in an article about Gmail downtime.
I see your point, but I actually think users should be _more_ alarmed when an input makes software crash, for just this reason. They tend to think of it as a harmless annoyance.
Also, while sandboxing may be designed to prevent this, Messages is probably also designed not to crash on link sharing.
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 common sense.)
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 valid memory address and make the process execute the attacker's own code.
If software written in C/C++ crashes and it's not because of a null pointer dereference specifically, then it's realistic to worry about whether it might be because of an exploitable bug (like a buffer overflow, a double-free, etc). One common way for people to try to find exploitable bugs is to script a program to re-run with random input data to figure out which inputs crash it, and then they debug the crashes to see if they're caused by exploitable bugs.
The text-segment of the code containing the machine instructions is in read-only memory. You won't be able to overflow a heap variable with the intention of writing to the text-segment of memory without causing a segfault.
In order to do ROP, you need to chain together gadgets of code segments which means you need to be able to see the source code/binary. This doesn't reveal any information about the call stack nor the available libraries to chain together ROP. And that's if stack canaries haven't screwed things up already.
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.
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?
You're not wrong. AgentME is correct, that crashes can be exploitable, but it is definitely more dangerous for software to continue after its data is corrupted.
The Erlang programming language, in fact, is built around the idea that as soon as you see data you don't expect, you crash, and an external process will start you back up in a known good state.
The SMS app is itself "data", and it is probably the most sensitive data on my phone other than my keychain. You don't have to take a step back and say "Google": ignore you have a way to DoS someone's usage of Gmail, you can still note that "this can't be used to access data from Gmail".
The sandbox prevents an exploit in one app from accessing data in another. It doesn't stop an exploit from accessing data in the same app, like the Messages app.
They do if you file them at radar.apple.com. I've had back and forths with them on some video card performance issues after sleep after filing a report there.
Radar is Apple’s internal bug tracking system. Outsiders have limited access to it. I believe bugreport.apple.com is the path for submitting bugs as an external developer.
https://support.apple.com/en-us/HT201220 has a section for “Security and privacy researchers”. The process is to send mail to product-security@apple.com, optionally encrypted by Apple Product Security's PGP key. A developer account is not required.
Since this page is the top search engine hit for several obvious searches (for example “report apple security vulnerability”), hopefully Mr Masri reported it there.
If you submit a report on bugreport.apple.com, it will be triaged and (if necessary) passed on to the appropriate team to asses. I fixed several external user reported bugs when I worked at apple. You have to have a developer account to use bugreport. Now that I have retired, I use it. The people triaging do not know I used to be at apple. Not all the issues I report get resolved, just because they are probably low priority. But the important ones are dealt with, usually quite quickly.
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 think what they're getting at it, release an iOS 10.3.4 or whatever so that people who don't want iOS 11 can still avoid this bug. They did this once before, around iOS 6 I believe, when the security certificate for Facetime ran out.
And it's understandable. iOS 11 made my iPhone 7 - the newest one at the time - so unusable I sold it and got a different phone. It went from a good, snappy phone, to a slow mess that took seconds more to open or switch apps, crashed all the time, had UI glitches all over the place, and was so slow it couldn't play locally downloaded audio without stuttering and slowing down. Ew.
I'm not sure either Y Combinator News nor the linked site are "major publications".
It is news, because there's a _completely passive_ way to crash a device, and crashes nearly always will allow for unauthorized code execution, given enough resources to work on the problem. You could launch a DOS attack on phones this way, and we all know that Cell Phones are how we're warned about emergencies, etc.
For what it's worth, Microsoft Edge, my default browser, had no problems with this page.
There was an issue a few years ago where you could send a UTF-8 code to crash whatever app was currently open on an iPhone. I guess this might be the same issue but slightly different?
This again? It's eerily similar to https://m.huffpost.com/us/entry/7452324 (sorry for the mobile link). Only one other comment mentions the bug from 2015 that surprise, crashes the phone in the same way. It looks like this person just worked around the patch to cause it again.
I've noticed that iOS will only perform requests to links in iMessage if and only if the sender is in your contacts. If an unknown sender iMessages you a URL, iOS will not perform a request.
Considering that this text causes issues on other platforms than just Apple (with differing levels of severity), I would posit that it's unfair to characterize this as an "Apple bug".
Their lock screen crashing bug from iOS 11 that was fixed with 11.1 came back with 11.2 and I want to throw the thing out the window. Every time I hit the power button it crashes and have to type out the pin.
<!-- hello, this was written by Abraham Masri @cheesecakeufo -->
<!-- I discovered this bug in like 10 minutes -->
If the entire code in the page was whipped up in 10 minutes, then a large part might well be some repetitive copy-paste of a core part...Not exactly sure what this core part does...but given the obvious lack of printable ascii characters (code is way above '0x7F' ), it looks that it could be some unicode type of thing, which then is a bit reminiscing of an old iOS bug back in 2015, as described at this link,
also notice the high frequency of 0xCC and 0xCD throughout the code, which are respectively Breakpoint and INT on x86 architecture -- with its 0xCD's always followed by a single byte whose value is less than 0xA0 -- possibly x86 was used as author's development platform...
Yes, that's what I meant by "some unicode type of thing.... reminiscing to an old bug emerged two years ago" in my last post...
But on the hand, note the strong pattern of "0xCC" and "0xCD" (could be a coincidence to the x86 Breakpoint/INT code), pacing at a fixed distance throughout the code, as well as the numeric characteristics those parameters (or simply garbage code) to the "0xCC" and "0xCD" exhibit. I just feel that if there are certain numeric relations among those code chunks (for instance, all falling within a certain relatively narrow range, as all the parameters to "0xCD" are less than 0xA0 but above 0x80, a width of 32 units), it probably tells something (assuming it has been crafted in that way, with a meaningful purpose) -- but of course, my chunking method might be wrong and each character point (or instruction) might be longer 2 bytes...
And also note that a 12-MB buffer data devised within 10 minutes always seems to be a bit brute force -- so buffer overrun is quite likely in such case; and then out-of-bound data triggers some unhandlable action (as the app crashes) throughout all the exception handling stack -- in the simplistic scenario, would be a segfault -- but of course, that cheesecakeufo could do a bit more exploration with this buffer overrun -- but I guess that normally takes more than 10 minutes, for normal people....
I stopped working on this bug -- it would be a luxury to play a whole afternoon with this puzzle...do you have any further findings? Well, if I had more time, I probably would change the code a little and open it on an extra device, and see if there are any different effects...
The fact that the embellished t's form these big overlapping blocks makes me think that it's hitting the worst-case behavior of some text layout algorithm.
I don't understand what all the hex digits and apostrophes are for, though.
each displayed lines of characters in that twitter image is exactly the same...they only shift their position a bit.
it looks like the black shades over the character lines are the vestiges left by the non-ascii characters at the beginning of the code.
the displayed part is not just ascii hex and apostrophes characters, there are also punctuation characters there...My guess is that if they are displayed, then that means the system has already successfully handled them and their triggered actions have been contained in defined system behaviors...
I don't have a spare ios system at hand right now to do more testing on this bug (if the bug is inside the library code and not at the API level, then an emulator usually would not be able to replicate the problem in the same way a real system produces)...
hence I can only make guesses...if I had a spare one, I would try to modify the content of code and see what would happen (do things such as reducing the code size -- most of the code are repetitive -- and see what would happen if we only retain the core part; or only retain the first half of the entire code -- those 0xCC and 0xCD part; or only retain the second half, those displayable ascii chars)...trim the code down to smaller units and test on them individually (in the same sense as modular testing).
Because this is completely passive -- you don't have to click on anything or do anything -- this is news. Stop being an apologist for your favorite company.
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 HTML)
- Short sequences of spaces, non-breaking spaces, and zero-width joiners
- Occasional emoji
The "t̴́̍̒"s manage to slow down my terminal and glitch its rendering a bit. Is it that they're unexpectedly tall? But we've had zalgo-text for a while and it hasn't actually crashed devices.
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)
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, even more directly ensures that it is not Perfect. It seems that every record player is vulnerable to one or the other of those frailties, and hence all record players are defective. (p77)
I'm also thinking Snow Crash.
Similarly (and also featured in a Hofstadter book), there's the short story "The Riddle of the Universe and Its Solution" by Christopher Cherniak. https://en.wikipedia.org/wiki/The_Riddle_of_the_Universe_and...
I don't think anyone ever intended for text rendering to be a "sufficiently powerful formal system" like second-order logic, number theory, or like Hofstadter says the human brain is. I would hope that, in the absence of bugs, rendering text X on computer system Y would be a plain old computable function.
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? :)
Okay, I have at least a guess about the type of thing that's going on, after seeing what it did to Firefox (which it at least didn't crash).
Various GUI elements such as title bars, tooltips, and thumbnails of links to Web pages, will try to fit the text they're given in a certain amount of space. If the text is too wide, it'll show some amount of text followed by "...". (I wonder if they're prepared for the text to be too tall.)
I saw Firefox rendering the long sequence of t̴́̍̒ characters in the mailto: link. It was being kerned in a way that made it nearly a solid black smear of pixels.
My guess is that apps are trying to determine how much of this text to show to fit within a certain width (and height?), and this text messes with a kerning algorithm in a way that makes it computationally very difficult to decide. I still don't know what's going on with the rest of the text, and why it can read 20 MB of text without making a final decision.
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?
Not just simple text, it's UTF-8. Rendering these UTF-8 "text bombs" seems to DoS several applications. This particular one crashes the messages app in iOS, crashes the tab in Chrome, and locks up FireFox. It also crashes several text editors which support UTF-8. Opens quickly in notepad, but takes several minutes in wordpad and it very laggy when scrolling.
> crashes the tab in Chrome, and locks up FireFox
Both of which are WebKit wrappers on iOS.
References to WordPad and notepad suggest they were not running Chrome or Firefox on iOS.
> but never on any other platforms
There have been numerous crash-bugs for the Windows font renderer, and even security exploits using it (especially before windows 10, as earlier than that font rendering was performed in the kernel's space rather than user-land). I wouldn't be surprised to learn of issues (at least of the falling over variety) in common Linux rendering engines and for other OSs too.
The Windows bugs are usually tied into executing TTF hint bytecode which is ignored by Freetype.
FreeType used to ignore TrueType hint bytecode to avoid infringing on related patents, but those patents expired in 2010 and FreeType's interpreter is now enabled by default.
http://freetype.sourceforge.net/patents.html
I suppose because SMS/messages is tightly integrated with the operating system. It goes from the baseband, through the kernel.
Nokia's had one.
https://www.slashgear.com/nokia-curse-of-silence-sms-bug-pre...
>or are there plenty of other cases out there that I just don't know about?
Yeah, go on IRC sometime and you’ll probably find out relatively quick.
Plenty of magic strings that break things on various platforms, hardly just an OS X thing.
More of a potential problem than an existing one but I know potential issues have shapped how fonts are delivered on Android :
A recent version of the OS + support lib added the possibility to reference a font in your app in order to have it downloaded (if necessary) and applied to your views.
IIRC It is restricted to one font delivery system only allowing fonts available on Google fonts. Not because of a power grab, but because fonts are not just graphics but also run a bunch of code.
So unrestricted access would have been a big security hole.
If you want more details, the font team talked about it at length during an Android Developer Backstage podcast episode.
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 <h3><h3><h3>hello</h3></h3></h3> but many more nested tags) and it would freeze aol trying to render it and kick people off the internet. They eventually fixed it.
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 perhaps only the e-mail address.
Hah. View-Source takes forever to load (in Vivaldi). Wget says it's a 20 MB file. Opening it in Joe in Cygwin kills the Cygwin process. Neat.
Also the href attribute inside the <link rel="apple-touch-icon"> points to a HTML URL, but that returns a 404...
Could someone just use some sort of fuzzing software to generate these?
Just keep trying many until one hits.
You can, but the number of possible inputs is huge and fuzzing won't prove that no such input exists.
Can confirm, just crashed my friends iPhone X. Required a hard reboot, was locked up completely.
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.
It didn't completely lock up on W7 FF 57.
The lock ups came in waves but was able to close the tab when it was unlocked.
Same for me, except on Windows 7. CPU spiked to 100% and I warmed up my hands with the extra heat :). Closing the tab and waiting a minute or so (the usual thing I do for cpu/memory intensive pages like this) didn't work. I had to completely restart Firefox to get it back to normal.
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.
This is arguably spam. The "link to fix iMessage if it crashes" just opens up a ton of ads with women in lingerie.
The linked blog assures people that this can't be used to access data. Once something is crashing an app/OS, can you really say that? I mean, can you be sure there's no one clever enough to capitalize on the underlying software error leading to this state?
Don’t know any details about this one, but some bugs are just not exploitable beyond denial of service. If all you can do is provoke an action that makes the OS kill the process immediately, for example. Like a null pointer dereference under the right circumstances.
That's kind of what I was thinking, but it sounds like you or I know about as much about the cause of the bug as the person offering assurances.
That would be a general issue with app crashing, and a huge deal worth it’s own series of articles. iOS’ sandboxing makes it so unlikely this exists, it’s not worth mentioning and the sensational writing might be counterproductive to getting the actual issue fixed. To use an analogy, it’d be like mentioning that someone could hack Google in an article about Gmail downtime.
I see your point, but I actually think users should be _more_ alarmed when an input makes software crash, for just this reason. They tend to think of it as a harmless annoyance.
Also, while sandboxing may be designed to prevent this, Messages is probably also designed not to crash on link sharing.
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 common sense.)
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 valid memory address and make the process execute the attacker's own code.
If software written in C/C++ crashes and it's not because of a null pointer dereference specifically, then it's realistic to worry about whether it might be because of an exploitable bug (like a buffer overflow, a double-free, etc). One common way for people to try to find exploitable bugs is to script a program to re-run with random input data to figure out which inputs crash it, and then they debug the crashes to see if they're caused by exploitable bugs.
The text-segment of the code containing the machine instructions is in read-only memory. You won't be able to overflow a heap variable with the intention of writing to the text-segment of memory without causing a segfault.
But with ROP, there's usually no need to write into the text-segment to execute arbitrary code.
In order to do ROP, you need to chain together gadgets of code segments which means you need to be able to see the source code/binary. This doesn't reveal any information about the call stack nor the available libraries to chain together ROP. And that's if stack canaries haven't screwed things up already.
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
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?
You're not wrong. AgentME is correct, that crashes can be exploitable, but it is definitely more dangerous for software to continue after its data is corrupted.
The Erlang programming language, in fact, is built around the idea that as soon as you see data you don't expect, you crash, and an external process will start you back up in a known good state.
Depends on what we mean by crash.
If program gives up and exits on receipt of unexpected input, that can be perceived as a "crash" by the user but it's not exploitable.
If it's crashing because execution suddenly jumped somewhere it shouldn't be, and the OS killed it, that's more worriesome.
The SMS app is itself "data", and it is probably the most sensitive data on my phone other than my keychain. You don't have to take a step back and say "Google": ignore you have a way to DoS someone's usage of Gmail, you can still note that "this can't be used to access data from Gmail".
The sandbox prevents an exploit in one app from accessing data in another. It doesn't stop an exploit from accessing data in the same app, like the Messages app.
- Mr Masri said he "always reports bugs" before releasing them.
Well I don't think Apple really reads bug reports.
They do if you file them at radar.apple.com. I've had back and forths with them on some video card performance issues after sleep after filing a report there.
What is that site? I have a working Apple ID and it won't even let me sign in.
You have to have a (free) developer account.
Radar is Apple’s internal bug tracking system. Outsiders have limited access to it. I believe bugreport.apple.com is the path for submitting bugs as an external developer.
Do any outsiders have access to radar itself? As a developer, when I log into radar.apple.com I'm redirected to bugreport.apple.com
I'll try resubmit my bug here and see how it goes. thanks!
https://support.apple.com/en-us/HT201220 has a section for “Security and privacy researchers”. The process is to send mail to product-security@apple.com, optionally encrypted by Apple Product Security's PGP key. A developer account is not required.
Since this page is the top search engine hit for several obvious searches (for example “report apple security vulnerability”), hopefully Mr Masri reported it there.
If you submit a report on bugreport.apple.com, it will be triaged and (if necessary) passed on to the appropriate team to asses. I fixed several external user reported bugs when I worked at apple. You have to have a developer account to use bugreport. Now that I have retired, I use it. The people triaging do not know I used to be at apple. Not all the issues I report get resolved, just because they are probably low priority. But the important ones are dealt with, usually quite quickly.
Fixed in the latest beta: https://www.macrumors.com/2018/01/17/apple-seeds-ios-11-2-5-...
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.
Yeah I still haven't updated one of my iOS devices because quite a few good apps haven't been updated to be compatible with iOS 11
I think what they're getting at it, release an iOS 10.3.4 or whatever so that people who don't want iOS 11 can still avoid this bug. They did this once before, around iOS 6 I believe, when the security certificate for Facetime ran out.
And it's understandable. iOS 11 made my iPhone 7 - the newest one at the time - so unusable I sold it and got a different phone. It went from a good, snappy phone, to a slow mess that took seconds more to open or switch apps, crashed all the time, had UI glitches all over the place, and was so slow it couldn't play locally downloaded audio without stuttering and slowing down. Ew.
This really shits me about updates to phones and other devices like my TV.
I always cringe a bit when there's an update because the companies never provide any way to downgrade if you're not happy after.
It's not only Apple responsible, I wish there was some kind of consumer protections.
There should always be a way for a consumer to get a product back to the state is was at the time of purchase.
I'm really curious to know how you think they can possibly do that without you having to update your phone. Care to explain?
see @ClassyJacket response basically release ios 10.3.4
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.
I'm not sure either Y Combinator News nor the linked site are "major publications".
It is news, because there's a _completely passive_ way to crash a device, and crashes nearly always will allow for unauthorized code execution, given enough resources to work on the problem. You could launch a DOS attack on phones this way, and we all know that Cell Phones are how we're warned about emergencies, etc.
For what it's worth, Microsoft Edge, my default browser, had no problems with this page.
The BBC is the largest broadcaster in the world.
My iPhone X wont even open imessages after trying to delete two texts with this message, i would say its a pretty big problem
I believe the solution present on this linked page will help you: https://www.vincedes3.com/save.html
Opens imessage again with a message draft so that you can delete the conversation without fetching the linked bug
Warning - this link has dozens of not work appropriate ads on it now.
Agh, apologies, missed those with my adblocker
There was an issue a few years ago where you could send a UTF-8 code to crash whatever app was currently open on an iPhone. I guess this might be the same issue but slightly different?
This again? It's eerily similar to https://m.huffpost.com/us/entry/7452324 (sorry for the mobile link). Only one other comment mentions the bug from 2015 that surprise, crashes the phone in the same way. It looks like this person just worked around the patch to cause it again.
I've noticed that iOS will only perform requests to links in iMessage if and only if the sender is in your contacts. If an unknown sender iMessages you a URL, iOS will not perform a request.
Not making any sort of comment on this issue or Apple, but I’m sure glad every bug I write isn’t covered in the news.
Sounds like AOL punters. Fate X anyone?
Right? I remember spamming people with h1 tags, then seeing them go offline. Welp, was fun for 5 minutes.
AOL sent my dad an e-mail :(
Considering that this text causes issues on other platforms than just Apple (with differing levels of severity), I would posit that it's unfair to characterize this as an "Apple bug".
Their lock screen crashing bug from iOS 11 that was fixed with 11.1 came back with 11.2 and I want to throw the thing out the window. Every time I hit the power button it crashes and have to type out the pin.
I still have the issue where if I access the camera from the lock screen it randomly renders my phone unlockable
Anyone have the clode?
Here's an archived version: http://web.archive.org/web/20180117063656/https://iabem97.gi...
https://mega.nz/#!X4piUYwA!zXH1vCliaO00V2v2554vegCnXzQ69jdAX...
11.7MB HTML file. It crashes the tab in Chrome 65.0.3324.2 64-bit and locks up Firefox 58.0 64-bit on Windows for me.
Works on my ff 58.0b16 win10 64bit
I tried to repeat the test in FF and you're right, it does not lock it up, but once I click in the black area of the page, it becomes unresponsive.
a mirror of the page could be found here...
google chrome browser seems to have disabled the display of the content but other browsers may still be fine with it...
if viewed in a hex editor, this same block of patterns repeated over and over again...seemingly to be an effort to overrun the buffer....
The author comment at the top of the page says,
If the entire code in the page was whipped up in 10 minutes, then a large part might well be some repetitive copy-paste of a core part...Not exactly sure what this core part does...but given the obvious lack of printable ascii characters (code is way above '0x7F' ), it looks that it could be some unicode type of thing, which then is a bit reminiscing of an old iOS bug back in 2015, as described at this link,
https://www.reddit.com/r/iphone/comments/37eaxs/um_can_someo...
also notice the high frequency of 0xCC and 0xCD throughout the code, which are respectively Breakpoint and INT on x86 architecture -- with its 0xCD's always followed by a single byte whose value is less than 0xA0 -- possibly x86 was used as author's development platform...
The pattern of bytes above 0x7F isn't anything to do with x86 architecture. It's UTF-8, the most common way to encode Unicode in bytes.
You'll have more success understanding what it's doing if you decode it from UTF-8 first.
Yes, that's what I meant by "some unicode type of thing.... reminiscing to an old bug emerged two years ago" in my last post...
But on the hand, note the strong pattern of "0xCC" and "0xCD" (could be a coincidence to the x86 Breakpoint/INT code), pacing at a fixed distance throughout the code, as well as the numeric characteristics those parameters (or simply garbage code) to the "0xCC" and "0xCD" exhibit. I just feel that if there are certain numeric relations among those code chunks (for instance, all falling within a certain relatively narrow range, as all the parameters to "0xCD" are less than 0xA0 but above 0x80, a width of 32 units), it probably tells something (assuming it has been crafted in that way, with a meaningful purpose) -- but of course, my chunking method might be wrong and each character point (or instruction) might be longer 2 bytes...
And also note that a 12-MB buffer data devised within 10 minutes always seems to be a bit brute force -- so buffer overrun is quite likely in such case; and then out-of-bound data triggers some unhandlable action (as the app crashes) throughout all the exception handling stack -- in the simplistic scenario, would be a segfault -- but of course, that cheesecakeufo could do a bit more exploration with this buffer overrun -- but I guess that normally takes more than 10 minutes, for normal people....
I stopped working on this bug -- it would be a luxury to play a whole afternoon with this puzzle...do you have any further findings? Well, if I had more time, I probably would change the code a little and open it on an extra device, and see if there are any different effects...
I saw a tweet about what it looks like (in some piece of software that at least manages to render something): https://twitter.com/BagusAlexandria/status/95347388267712921...
The fact that the embellished t's form these big overlapping blocks makes me think that it's hitting the worst-case behavior of some text layout algorithm.
I don't understand what all the hex digits and apostrophes are for, though.
each displayed lines of characters in that twitter image is exactly the same...they only shift their position a bit.
it looks like the black shades over the character lines are the vestiges left by the non-ascii characters at the beginning of the code.
the displayed part is not just ascii hex and apostrophes characters, there are also punctuation characters there...My guess is that if they are displayed, then that means the system has already successfully handled them and their triggered actions have been contained in defined system behaviors...
I don't have a spare ios system at hand right now to do more testing on this bug (if the bug is inside the library code and not at the API level, then an emulator usually would not be able to replicate the problem in the same way a real system produces)...
hence I can only make guesses...if I had a spare one, I would try to modify the content of code and see what would happen (do things such as reducing the code size -- most of the code are repetitive -- and see what would happen if we only retain the core part; or only retain the first half of the entire code -- those 0xCC and 0xCD part; or only retain the second half, those displayable ascii chars)...trim the code down to smaller units and test on them individually (in the same sense as modular testing).
Where is my textbombattack.com website and cute logo?
So shipping software has an obscure bug that can cause a crash. Why is this news?
Because Apple once prided itself as a company that made computers that "just worked".
I like how you wrote all that in the past tense.
If the shoe fits... :-(
Sad to see how the mighty have fallen
Because this is completely passive -- you don't have to click on anything or do anything -- this is news. Stop being an apologist for your favorite company.
Apple products don't have malware