The Aftermath of a Fuzz Run: What to do about those Crashes?
Talkat Embedded Linux Conference + OpenIoT Summit North America 2017 · on Tuesday, 2017-02-21· at 10:30· Atrium Ballroom·
summary
Practical post-fuzz workflow for C/C++: minimize crash corpus with AFL cmin and per-case minimizers, dedupe files, then run AddressSanitizer and Valgrind to classify heap overflows, use the exploitable gdb extension and disable ASLR to reproduce, compile with -g -O0 and instrumented allocators, and use rr to reverse-step into the root cause. Examples: PHP null-deref patched as non-exploitable, Ruby regex heap overflow deemed exploitable but narrow surface, Dynomite off-by-one in string dup fixed after triage.
AI-written summary · about
chapters (22)
- 0:00Intro
- 0:21NeXT, Apple, Weblogic, BEA Systems, Azul Systems
- 3:211 Introduce/Review Memory Corruption Bugs 2 A Post Fuzz Run Workflow 3 Real World Examples
- 5:01Invalid Reads/Writes
- 6:09Stack vs Heap Corruption
- 7:54Use After Free
- 9:12Other Memory Bugs
- 10:23b: What is Exploitability?
- 12:10Does "exploitability" matter?
- 13:08Google Project Zero
- 14:44Many modern exploits are bug chains
- 14:58Surprisingly Exploitable
- 15:14C-Ares / Chrome OS Remote Code Execution
- 16:38Section 1c: Memory Corruption Mitigations
- 18:05ASLR Address Space Layout Randomization
- 21:23Minimize the Corpus of Crashes
- 23:39b: Memory Corruption Analysis Tools
- 25:28Valgrind (memcheck)
- 27:35Section 2c: Determine Exploitability / Find the Root Cause
- 28:26Identify critical memory locations
- 32:19PHP: Low invalid read
- 35:44Netflix Dynomite: Invalid Write
