Why is application crash considered insecure?

Question

If an application crashes, the program stops and there is nothing anyone can do about it, other than starting the program again.

Crash is a bad behaviour in general and should be avoided, but why are they seen as security vulnerability?

Answer 1

1. It crashed because some input was not processed correctly. An attacker may try to find the code path that leads to the faulty procedure and attempt to execute arbitrary code through potential vulnerabilities.

2. Crashes may give an attacker valuable information about the system and its internal details.

3. Crashes may create temporary vulnerabilities or leave unprotected files (e.g. memory dumps) that may be exploited.

4. (Thanks and a hat tip go to Ladadadada) The application that crashes needs to be restarted, which obviously takes time (even with watchdogs and symmetric failover schemes). If an attacker replicates the conditions leading to the crash your service will suffer from prolonged outage (Denial-of-service) which means financial, reputation, and other losses.

Answer 2

As previous answer have covered most of the scenario in which attacker can get direct benefit by analyzing application crashes. I will recommend read on "Analyze Crashes to Find Security Vulnerabilities in Your Apps". Analyzing crashes for security vulnerabilities may require low level programming skills. As shown in figure 1 every exploit may not lead to security vulnerability and defines a investigation path for analyzing application crashes.

• 

Answer 3

To generalise Deer Hunter's answer:

• If an application crashes, it means that what is happening is not expected, and not understood.
• If it is not expected and not understood, you have no way of knowing whether it is safe.
• You must therefore assume that it is not safe.

Note that simply catching and discarding an unexpected exception is also insecure and not to be done. Terminating the process is better than continuing in an unexpected inconsistent state.

This is essentially the distillate of Feynman's Appendix:

(...) erosion and blow-by are not what the design expected. They are warnings that something is wrong. The equipment is not operating as expected, and therefore there is a danger that it can operate with even wider deviations in this unexpected and not thoroughly understood way. The fact that this danger did not lead to a catastrophe before is no guarantee that it will not the next time, unless it is completely understood.

You can find the full document here:

• http://history.nasa.gov/rogersrep/v2appf.htm

This is recommended reading for all software developers, particularly those who have the habit of catching exceptions which they do not fully understand.

Answer 4

An application crash is the result of an unexpected and unhandled behaviour. This means there is a bug in the application that crashed, and numerous bugs leads to vulnerabilities.

One of the most dangerous kind of crash is ths crash due to memory corruption (Segmentation fault). This kind of bugs can often be exploited to make the vulnerable application execute an arbitrary (malicius) piece of code.

Moreover a way to crash a software can be used in denial of service attacks.

Answer 5

You are merging two different events: stopping and crashing

• If an application really stops cleanly it can no longer do any harm
• If an application crashes it can show all kinds of undefined and unexpected behavior as show in other answers. 'Stopping' is only one outcome. It may also start using 100% of the CPU indefinitely, leading to all kinds of other problems.

Answer 6

Certain types of crashes are known as "Access Violations" these are the Crashes/Anomaly which "violates" the rule defined by programmers who wrote system/software/operating-system or defined by programmers who wrote compilers which makes executables.

Suppose attacker(Neo) finds a crash into one of the software(Matrix) he can use that crash to "violate" the rule(rules witch are defined for Matrix) and he can use that crash to take control over system(Matrix) and now He want to do malicious activity(Turn off the matrix) for that he knows a API call ,but that API call is controlled/guarded by another program/antivirus(Agent Smith), but since he got the full control over system(matrix) he can close Antivirus(Agent Smith) and now he can close the system(Matrix)

Since this will affect confidentiality, integrity, and availability of the system these crashes are called as Security Issues.

Answer 7

Many application crashes -not all of them, but many- involve the machine executing something that it shouldn't have. The machine jumps into something that it thinks is supposed to be code, but it's actually zeroed-out or random data (or at least data that hasn't been prepared as code). The machine tries to look at this data as code, but it doesn't make any sense as code, so the machine doesn't know what to do. When that happens, the application crashes.

But the thing about bugs is that if you know how to trigger them, you can trigger them deliberately. Sometimes, depending on how the bug works, you can even control what data the machine jumps into. That possibility is what makes security folks nervous: if you can make the machine jump into data that doesn't make any sense, and you can control what that data is, then you could make the machine jump into something that does make sense. Once you've got that set up, you could make the machine do more or less whatever you want.

Not every application crash works this way. @AliAhmad's answer shows the basics of how to tell what can and what can't. But because the consequences of an unsafe crash can be so severe, every crash has to be checked out to see if it's "safe" or not.