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.
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)
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? :)
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.
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.
Both of which are WebKit wrappers on iOS.
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.
https://www.slashgear.com/nokia-curse-of-silence-sms-bug-pre...
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.
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.
Also the href attribute inside the <link rel="apple-touch-icon"> points to a HTML URL, but that returns a 404...
It is an i7, 16 GB total (7 GB free), and an SSD.
The lock ups came in waves but was able to close the tab when it was unlocked.
Just keep trying many until one hits.
Also, while sandboxing may be designed to prevent this, Messages is probably also designed not to crash on link sharing.
Well I don't think Apple really reads bug reports.
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.
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?
Opens imessage again with a message draft so that you can delete the conversation without fetching the linked bug
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.
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.
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.
view-source:https://web.archive.org/web/20180117063656/https://iabem97.github.io/chaiOS/
0x00007B90: A5CCBACD 8774CCB4 CD81CC8D CC92CD8C .....t..........
0x00007BA0: CD84CC86 CC8FCD8B CD97CD86 CC9BCC8F ................
0x00007BB0: CC8ECC95 CC87CC82 CC94CC9B CC92CC92 ................
0x00007BC0: CC86CD91 CD9BCC86 CC8ECCBD CC84CC8B ................
0x00007BD0: CC91CC88 CD9DCC81 CD81CC81 CC84CCBE ................
0x00007BE0: CC85CCBE CC86CC84 CD82CC86 CD9DCC89 ................
0x00007BF0: CC85CC87 CD8CCD9D CC81CC88 CCBFCC9A ................
0x00007C00: CC82CC86 CD8CCC90 CD9DCC82 CC9ACC80 ................
0x00007C10: CC93CC9B CD84CC89 CD82CD8A CCBECD8B ................
0x00007C20: CDA0CC83 CC8ACC8E CD98CC89 CD97CC80 ................
0x00007C30: CD80CC8A CC8FCDA0 CC80CC80 CD84CD80 ................
0x00007C40: CD8CCD92 CD92CD91 CC90CD98 CC83CC88 ................
0x00007C50: CD84CD9B CCBDCD9B CC84CC8D CDA0CC8C ................
0x00007C60: CC81CD97 CD8BCD86 CD9BCD91 CC8ECCAA ................
0x00007C70: CCA7CD87 CD95CCB1 CCA8CCBC CD9CCCA6 ................
0x00007C80: CCA6CC9D CCAFCCAA CC97CCA0 CC9ECD85 ................
0x00007C90: CCAACCA4 CCB2CCAB CD8ECCAB CD89CD8D ................
0x00007CA0: CCA2CCA8 CCAACC97 CCACCCA3 CCBACD93 ................
0x00007CB0: CC9ECCA9 CD87CCA8 CD96CCAF CCBACCA7 ................
0x00007CC0: CCB1CCBB CCA3CCAE CCABCCA7 CD96CCBA ................
0x00007CD0: CCAFCCA9 CCA0CCB2 CC96CD95 CCAACCAD ................
0x00007CE0: CD9ACCA8 CCB9CCB9 CCB0CCA0 CD88CCBA ................
0x00007CF0: CCA9CD9C CCA3CCA1 CCA0CD8D CC98CCA1 ................
0x00007D00: CCAFCCA1 CC9DCD87 CCA6CC9D CCBACCBA ................
0x00007D10: CCAACD9A CCBACD8D CD88CD93 CCB1CCBC ................
0x00007D20: CCA1CCB1 CCB3CCA4 CD9ACCB0 CCA9CCB2 ................
0x00007D30: CC9DCCAC CCADCCB9 CC9ECD89 CD89CD9C ................
0x00007D40: CCA5CCA8 CC9DCD89 CCBACCA2 CC9CCC9F ................
0x00007D50: CCA5CCBA CD8774CC B4CD81CC 8DCC92CD ......t.........
<!-- hello, this was written by Abraham Masri @cheesecakeufo -->
<!-- I discovered this bug in like 10 minutes -->
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...