Effective Bug Discovery
Kernel-Mode Coverage Analysis
vf
vf@nologin.org
Last modified: 9/23/2006
If we knew what it was we were doing, it would not be called research, would it?
Albert Einstein
1
Contents
1 Foreword
3
2 Introduction
5
2.1 The status of vulnerability research . . . . . . . . . . . . . . . . .
5
2.2 The problem with fuzzing . . . . . . . . . . . . . . . . . . . . . .
5
2.3 Expectations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3 Q&A
7
3.1 What is code coverage?
. . . . . . . . . . . . . . . . . . . . . . .
7
4 Hypothesis: Code Coverage and Fuzzing
9
4.1 Process and Kernel Stalking . . . . . . . . . . . . . . . . . . . . .
9
4.2 Stalking and Fuzzing Go Hand in Hand . . . . . . . . . . . . . .
10
5 Implementation
11
5.1 Stalking Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
5.2
Installing the Stalker . . . . . . . . . . . . . . . . . . . . . . . . .
12
5.3
Installing Debug Stalk . . . . . . . . . . . . . . . . . . . . . . . .
13
5.4 Stalking with Kernel Debug . . . . . . . . . . . . . . . . . . . . .
13
5.4.1 Part I . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.5 Analyzing the output . . . . . . . . . . . . . . . . . . . . . . . . .
16
5.5.1 Part II . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.6 Part III
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
6 Conclusion and Future Work
23
2
Chapter 1
Foreword
Abstract: Sophisticated methods are currently being developed and imple-
mented for mitigating the risk of exploitable bugs. The process of researching
and discovering these vulnerabilities in modern code will, in time, become less
extensive. Therefore, research technologies are changing to accommodate the
shift in vulnerability discovery. Code coverage analysis implemented in con-
junction with fuzz testing reveals faults within a binary file that would have
otherwise remained undiscovered by either method alone. This paper suggests
a research method for more effective runtime binary analysis using the afore-
m