yay! would be a very cool feature!

One thing should to be clarified. The above mentioned algorithm is at the assembly language level rather than syscall or function call. That will also make it platform specific. And what is bad on x86_64 might not affect ARM or PPC. And they could have things not accounted for in the above algorithm.

Is there going to be a way around this? Without running the app inside something like valgrind, I can't think of an easy way to tell if a crash is dangerous or not without looking at assembly.

There are likely some instances where you could inspect a syscall, or possibly even a function call, but let's say you have a line in C similar to:

array1[attacker_controlled_variable] = array2[somevar];

That crash could be the result of either an invalid read or write. In the case of invalid read, we may not even call it a security flaw.

The vast majority of security flaws we fix are not the direct result of bad syscalls or misused functions, they are things like invalid free and bad arithmetic (leading to the above sort of issue).

Moved to abrt server-side projects -> reassigning to kklic

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

FYI:

The CERT Linux Triage Tools 1.0 have been released as open-source software and are available for download here:

http://www.cert.org/vuls/discovery/triage.html

The tools include a Python-based GDB extension called "exploitable" that can be used to classify application errors in a manner similar to !exploitable on Microsoft Windows or CrashWrangler on Apple OS X. You can learn more about the tools and how to use them in my recent blog post:

http://www.cert.org/blogs/certcc/2012/04/cert_triage_tools_10.html

Basic implementation has been added in 27c6994ee2b7a5bbc2f0158b8710a0d36950be1b, available in abrt-2.1.6.