Comment by 1123581321
7 years ago
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.
7 replies →
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.