Toward Facilitating Root Cause Localization in Fuzzing
Katsunori Aoki
The University of Tokyo

Takahiro Shinagawa
The University of Tokyo

aoki@os.ecc.u-tokyo.ac.jp

shina@ecc.u-tokyo.ac.jp

Abstract:

1 Background

2 Previous Root Cause Analysis• Fuzzing is a method to find vulnerabilities• Symbolic execution [1]Root cause◦ It finds a lot crashes automatically by◦ Collect conditions to trigger crash during execution

generating inputs

Path explosion problem◦• Root cause analysis is difficult• Statistical Crash Analysis [2]◦ Fuzzers only reports crash location

😡

◦ Compare behavior of predicates using similar inputs

Crash location◦ Root cause is often far from crash location

Binary-level information and high false positive rate◦😡

3 Human friendly data flow graph (DFG)
Our goal:(a-1) Mutation-based fuzzers
generates slightly different inputs

Quickly and easily understand root cause
Key ideas:(a) Difference of DFG between crashed and normal execution(b) Adding lexical information at the source code level

4 Implementation(a-2) Difference in data ﬂow graphs
is likely to be closer to root cause

Input Aacdef

Input A

Input A'a B cdef

Input A'b(c) facilitate reading of semantic information

L :(char)(b) Extract lexical information from source code

magic[1] :(char)

Condition :()if (magic[1] != ‘L’ )• Lexical information extraction: source code instrumentation using LLVM
• Data flow tracing: created ourself from scratch

5 Preliminary experiments
Evaluation dataset:

Result (4 cases):• Magma [3] : Reproduces known software vulnerabilities• (Distance 0) Case 1, 2: patch point was control flow governing◦ Provides (non-)crash inputs as artifacts

the boundary of difference• (Distance 0) Case 3: patch point was tangent to the boundary

Evaluation method:• (Distance 1) Case 4: a sanitization patch was applied to a

• Measure distance between data flow difference and patch point
How to read graph:

PDF015

PNG007

Case 4

Case 1

Data flow difference
Compare data flows of (non-)crash inputs,and highlight nodes which (dis)appears inother graph.

point at distance 1 from the boundary

Patch point (Distance 0 from boundary)(Omittied)

objDict :(ObjType)

type :(Object *)This is dict type Object!"#$%%&'()&*%(+,-%.

Expected stream type

Patch point (Distance 1 from boundary)

Patch point (where the patch actually applied)!"#$%%$&'(!)*+#,$

Crash point

type: (objType)if (!m_objStr.isStream())
return false;

Crash pointtype != objStream

objStream :(ObjType)

Crash point

Case 1: libpng PNG007

Case 4: popper PDF015• In all cases,
Condition :()6 Future work
• Evaluate our approach in more crash cases• Evaluate whether our approach eases root cause analysis
compared to manual analysis and previous studies◦ no need to follow data flow far from the boundary◦ patch point located near the boundary

References[1] C. Yagemann et al. ARCUS: Symbolic Root Cause Analysis of Exploits inProduction Systems. In Proc. 30th USENIX Security Symposium, Aug. 2021.
[2] T. Blazytko et al. AURORA: Statistical Crash Analysis for Automated Root
Cause Explanation. In Proc. 29th USENIX Security Symposium, Aug. 2020.
[3] A. Hazimeh et al. Magma: A Ground-Truth Fuzzing Benchmark. Proc. ACM
Meas. Anal. Comput. Syst., 4(3), Dec. 2020.