71–80 of 113 posts
Earlier quoted context omitted.
What is that site? I have a working Apple ID and it won't even let me sign in.
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.
Earlier quoted context omitted.
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 com…
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.
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.
Both of which are WebKit wrappers on iOS.
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…
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
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…
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.
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…
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…
Earlier quoted context omitted.
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
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…
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)