Bug 622798

Summary: [RFE] add logic to determine security impact of the crash
Product: [Fedora] Fedora Reporter: Jiri Moskovcak <jmoskovc>
Component: abrtAssignee: Martin Milata <mmilata>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: anton, bressers, dfediuck, dvlasenk, fche, iprikryl, jmoskovc, jrieden, mtoman, rvokal, sgrubb, thoger
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-04 09:07:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 756771    

Description Jiri Moskovcak 2010-08-10 12:59:56 UTC
There is an algorithm from some people from Apple used in their CrashWrangler to determine the security impact of the detected crash. ABRT should provide such feature to inform the user and help the developer to prioritize the bug.

The is described here:
http://marc.info/?l=fuzzing&m=124708504011033&w=2

Comment 1 Anton Arapov 2010-08-10 13:09:06 UTC
yay! would be a very cool feature!

Comment 2 Steve Grubb 2011-05-24 21:16:16 UTC
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.

Comment 3 Josh Bressers 2011-05-31 15:44:41 UTC
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).

Comment 4 Jiri Moskovcak 2011-11-03 09:01:30 UTC
Moved to abrt server-side projects -> reassigning to kklic

Comment 5 Fedora Admin XMLRPC Client 2011-12-19 17:43:03 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Fedora Admin XMLRPC Client 2011-12-19 17:45:56 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Steve Grubb 2012-04-25 15:50:20 UTC
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

Comment 8 Martin Milata 2013-10-04 09:07:57 UTC
Basic implementation has been added in 27c6994ee2b7a5bbc2f0158b8710a0d36950be1b, available in abrt-2.1.6.