Closed Bug 513427 Opened 15 years ago Closed 12 years ago

Enable Socorro to do the same analysis as !exploitable on incoming crash reports to help triage more efficiently

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 794540

People

(Reporter: gkw, Unassigned)

Details

Shaver and I met at SFO airport and discussed the possibility of integrating !exploitable with Socorro. Should we?
See bug 497731 for what we can do with our current data. I think the "!exploitable" tool would mostly add false positives.
(In reply to comment #0) > Shaver and I met at SFO airport and discussed the possibility of integrating > !exploitable with Socorro. Should we? So let's say I want to target the 30% users that use Ff, having the exploitable data exposed would make my work easier. I think It would be worth automating if some of the data can be hidden - ie having rigths in the socorro Interface.
Help me understand what "integrating !exploitable with Socorro" means. Does it mean using the same techniques that !exploitable uses on the client side, or actually using the !exploitable tool, or using the existing data and doing further analysis on the server?
I was referring to doing the same analysis that !exploitable does, but doing them bsaed on incoming crash reports to help triage security-interesting crashes more efficiently.
Summary: Integrate !exploitable into Socorro → Enable Socorro to do the same analysis as !exploitable on incoming crash reports to help triage more efficiently
While the PROBABLY_EXPLOITABLE and UNKNOWN results from !exploitable contain close to zero information, I think the EXPLOITABLE cases are reliable. If we can improve the analysis of the crash so that we have more confidence in the results I think this would be a good idea. In addition, wouldn't the same techniques be applicable to Linux and Mac OS X as well?
When does !exploitable say crashes are EXPLOITABLE?
(In reply to comment #6) > When does !exploitable say crashes are EXPLOITABLE? See bug 493240, bug 506701 and bug 510230 as examples.
The rules from the source's exploitable_rules.h have the following comments: // Rule: If the event in the debugger is not an exception, we are unable to continue any further with our // Rule: Illegal instruction exceptions indicate that program flow has been controlled by an attacker // Rule: Privileged instruction exceptions indicate that program flow has been controlled by an attacker // Rule: All Guard Page exceptions must be fixed // Rule: Stack Buffer Overruns (/GS Exceptions) must be fixed // Rule: Heap Corruption is considered exploitable // Rule: All DEP violations in kernal mode are exploitable // Rule: DEP violations in user mode are exploitable if not near null // Rule: DEP violations in user mode are probably exploitable if not near null // Rule: All user mode Write Access violations are exploitable if not near null // Rule: All user mode Write Access violations are probably exploitable if near null // Rule: Kernel mode first chance write exceptions are exploitable if the address is in kernel memory // Rule: Kernel mode second chance write exceptions are exploitable // Rule: AVs at the instruction pointer are exploitable if in kernel mode // Rule: AVs at the instruction pointer are exploitable if not near null in user mode // Rule: AVs at the instruction pointer are probably exploitable if near null in user mode // Rule: AVs on control flow are considered exploitable in the kernel // Rule: AVs on control flow are considered exploitable in user mode if not near null // Rule: AVs on control flow are considered probably exploitable in user mode if near null // Rule: Read AVS in a block move are considered probably exploitable // Rule: Read AVS in a block move are considered probably exploitable // Rule: Read AVS in a block move are considered probably exploitable // Rule: Tainted information used to control branch addresses is considered probably exploitable // Rule: Tainted information used to control the target of a later write is probably exploitable // Rule: User Mode Read AVs near null are considered probably not exploitable // Rule: First chance read AVs from user memory in the kernel are not considered exploitable // Rule: First chance write AVs from user memory in the kernel are not considered exploitable // Rule: Divide By Zero is not considered exploitable // Rule: Divide By Zero is not considered exploitable // Rule: Breakpoints are considered probably not exploitable, but should not occur in production code // Rule: Breakpoints are considered probably not exploitable, but should not occur in production code // Rule: Bug checks that we don't have special case handling for should be called out separately // Rule: If the stack contains unknown symbols in user mode, call that out // Rule: Kernel Mode Read AVs near NULL are considered to have an unknown exploitability // Rule: Tainted information used to control the source of a later block move unknown, but called out explicitly // Rule: First Chance Read AVS in a block move in the kernel are called out as unknown // Rule: Tainted information used as an argument to a function is an unknown risk, but called out explicitly // Rule: Tainted information returned from a function is an unknown risk, but called out explicitly // Rule: Tainted information used to control branch selection is an unknown risk, but called out explicitly
I think we are mostly doing what is requested with this bug in semi-automated testing that tomcat is doing. we harvest unique sets of urls from the incoming crash reports, then load those with a !exploitable enabled build. I think tomcat has scaled the system to grind though around 4000-5000 page loads a day and we get better at finding the most interesting sets of urls as the process gets refined. I can't see how we would ever scale a system to assess exploitability on the 190,000+ incoming crashes we see every day. The process has turned up many interesting bugs, and clint has a roadmap to make additional automation improvements to what tomcat is doing now. hiding this bug for now. I not sure that tipping our hand on the idea of running exploitability assessment tools against our crash data and crash bugs is a great idea. we need to try and run faster in this area to stay ahead of bad guys.
Group: webtools-security
Component: Socorro → General
Product: Webtools → Socorro
Is this still something that is wanted? If so, somebody's going to have to give us more information.
Christian Holler has done some investigations in roughly such a direction, he might know more.
I've been briefly experimenting with using !exploitable on our minidumps and it semed to work (If I remember correctly, I even got this working in an automated way on Linux using wine+windbg+socorro raw dumps). I don't know about the quality of the results though. However, as bc mentioned in comment 5, it seems that some results could help triaging crash reports more quickly.
Note that Ted has a tool which operates on Windows minidumps produced by breakpad which provides a high, medium, low classification: http://hg.mozilla.org/users/tmielczarek_mozilla.com/exploitable/ It has been reliable in my usage in crash automation on Bughunter.
That exploitable tool is using the code that lives in the Breakpad tree: http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/exploitability_win.cc It only currently knows how to handle Windows crashes, but that's no different than !exploitable.
I'm not sure why this bug is marked security-sensitive anyway, it doesn't describe a security issue or have any secutity-sensitive information in it.
Depends on: 794540
Umm, this (comment #13 and 14) is live now, IMHO, this is a dupe of that bug.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Yes with bug 794540 fixed, now we dance! Let's move on to getting human readable reports, filed as bug 819426 and: https://projects.mozilla.org/browse/BA-92
Opening up as per comment 15.
Group: webtools-security
No longer depends on: 794540
You need to log in before you can comment on or make changes to this bug.