Comment by menacingly
7 years ago
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?
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.)
10 replies →
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.
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.