Not all crashes are equal. Some are the result of bugs which under different circumstances can be exploited as security vulnerabilities. For example, stack corrupting bugs are much more likely to be exploitable than division by zero.

ABRT contains a tool which analyzes coredumps and decides whether the bug which caused the coredump is likely to be exploitable. This tool is run on every recorded coredump, and the result of the analysis is saved in the exploitable element in the problem directory.

The main part of this tool is the gdb python plugin called abrt-gdb-exploitable.

In order to be used, it needs to be loaded from a running gdb session:

python execfile("/path/to/abrt-gdb-exploitable")

If it loads successfully, a new gdb command becomes available:

abrt-exploitable [RATING] [OUTFILE]

This command can be run on a live process or on a core dump.

If process didn't receive any signal, the command will emit a

Can't get signal no and do exploitability analysis

message to standard error.

If command is unable to make a guess about the reason why the signal was received, then it will emit a

Exploitability analysis came up empty

message to standard error.

Otherwise, it will emit the following message to standard output:

Likely crash reason: STRING
Exploitable rating (0-9 scale): N

where STRING explains why the signal was sent, and N shows how likely is this to be a result of an exploitable bug in the process. 0 means that it doesn't look dangerous at all, 9 means that the tool is virtually certain it is an exploitable bug.

If RATING is specified, the message is only emitted if N >= RATING.

If OUTFILE is specified, the message is written to the OUTFILE instead of standard output.

In order to be able to analyze core dumps, the tool needs that the kernel which produced the core dump, and the gdb should be sufficiently recent to provide $_siginfo variable.