Bug 622798 - [RFE] add logic to determine security impact of the crash
Summary: [RFE] add logic to determine security impact of the crash
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
low
medium
Target Milestone: ---
Assignee: Martin Milata
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: ABRTF18
TreeView+ depends on / blocked
 
Reported: 2010-08-10 12:59 UTC by Jiri Moskovcak
Modified: 2015-02-01 22:52 UTC (History)
12 users (show)

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: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.