|
120
|
1 =======================================================
|
|
|
2 libFuzzer – a library for coverage-guided fuzz testing.
|
|
|
3 =======================================================
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
4 .. contents::
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
5 :local:
|
|
120
|
6 :depth: 1
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
7
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
8 Introduction
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
9 ============
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
10
|
|
120
|
11 LibFuzzer is in-process, coverage-guided, evolutionary fuzzing engine.
|
|
|
12
|
|
|
13 LibFuzzer is linked with the library under test, and feeds fuzzed inputs to the
|
|
|
14 library via a specific fuzzing entrypoint (aka "target function"); the fuzzer
|
|
|
15 then tracks which areas of the code are reached, and generates mutations on the
|
|
|
16 corpus of input data in order to maximize the code coverage.
|
|
|
17 The code coverage
|
|
|
18 information for libFuzzer is provided by LLVM's SanitizerCoverage_
|
|
|
19 instrumentation.
|
|
|
20
|
|
|
21 Contact: libfuzzer(#)googlegroups.com
|
|
|
22
|
|
|
23 Versions
|
|
|
24 ========
|
|
|
25
|
|
|
26 LibFuzzer is under active development so you will need the current
|
|
|
27 (or at least a very recent) version of the Clang compiler.
|
|
|
28
|
|
|
29 (If `building Clang from trunk`_ is too time-consuming or difficult, then
|
|
|
30 the Clang binaries that the Chromium developers build are likely to be
|
|
|
31 fairly recent:
|
|
|
32
|
|
|
33 .. code-block:: console
|
|
|
34
|
|
|
35 mkdir TMP_CLANG
|
|
|
36 cd TMP_CLANG
|
|
|
37 git clone https://chromium.googlesource.com/chromium/src/tools/clang
|
|
|
38 cd ..
|
|
|
39 TMP_CLANG/clang/scripts/update.py
|
|
|
40
|
|
|
41 This installs the Clang binary as
|
|
|
42 ``./third_party/llvm-build/Release+Asserts/bin/clang``)
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
43
|
|
120
|
44 The libFuzzer code resides in the LLVM repository, and requires a recent Clang
|
|
121
|
45 compiler to build (and is used to :doc:`fuzz various parts of LLVM itself
|
|
|
46 <FuzzingLLVM>`). However the fuzzer itself does not (and should not) depend on
|
|
|
47 any part of LLVM infrastructure and can be used for other projects without
|
|
|
48 requiring the rest of LLVM.
|
|
120
|
49
|
|
|
50
|
|
|
51 Getting Started
|
|
|
52 ===============
|
|
|
53
|
|
|
54 .. contents::
|
|
|
55 :local:
|
|
|
56 :depth: 1
|
|
|
57
|
|
|
58 Fuzz Target
|
|
|
59 -----------
|
|
|
60
|
|
|
61 The first step in using libFuzzer on a library is to implement a
|
|
|
62 *fuzz target* -- a function that accepts an array of bytes and
|
|
|
63 does something interesting with these bytes using the API under test.
|
|
|
64 Like this:
|
|
|
65
|
|
|
66 .. code-block:: c++
|
|
|
67
|
|
|
68 // fuzz_target.cc
|
|
|
69 extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
|
|
|
70 DoSomethingInterestingWithMyAPI(Data, Size);
|
|
|
71 return 0; // Non-zero return values are reserved for future use.
|
|
|
72 }
|
|
|
73
|
|
|
74 Note that this fuzz target does not depend on libFuzzer in any way
|
|
|
75 and so it is possible and even desirable to use it with other fuzzing engines
|
|
|
76 e.g. AFL_ and/or Radamsa_.
|
|
|
77
|
|
|
78 Some important things to remember about fuzz targets:
|
|
|
79
|
|
|
80 * The fuzzing engine will execute the fuzz target many times with different inputs in the same process.
|
|
|
81 * It must tolerate any kind of input (empty, huge, malformed, etc).
|
|
|
82 * It must not `exit()` on any input.
|
|
|
83 * It may use threads but ideally all threads should be joined at the end of the function.
|
|
|
84 * It must be as deterministic as possible. Non-determinism (e.g. random decisions not based on the input bytes) will make fuzzing inefficient.
|
|
|
85 * It must be fast. Try avoiding cubic or greater complexity, logging, or excessive memory consumption.
|
|
|
86 * Ideally, it should not modify any global state (although that's not strict).
|
|
121
|
87 * Usually, the narrower the target the better. E.g. if your target can parse several data formats, split it into several targets, one per format.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
88
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
89
|
|
121
|
90 Fuzzer Usage
|
|
|
91 ------------
|
|
|
92
|
|
|
93 Very recent versions of Clang (after April 20 2017) include libFuzzer,
|
|
|
94 and no installation is necessary.
|
|
|
95 In order to fuzz your binary, use the `-fsanitize=fuzzer` flag during the compilation::
|
|
|
96
|
|
|
97 clang -fsanitize=fuzzer,address mytarget.c
|
|
120
|
98
|
|
121
|
99 This will perform the necessary instrumentation, as well as linking in libFuzzer
|
|
|
100 library.
|
|
|
101 Note that linking in libFuzzer defines the ``main`` symbol.
|
|
|
102 If modifying ``CFLAGS`` of a large project, which also compiles executables
|
|
|
103 requiring their own ``main`` symbol, it may be desirable to request just the
|
|
|
104 instrumentation without linking::
|
|
|
105
|
|
|
106 clang -fsanitize=fuzzer-no-link mytarget.c
|
|
|
107
|
|
|
108 Then libFuzzer can be linked to the desired driver by passing in
|
|
|
109 ``-fsanitize=fuzzer`` during the linking stage.
|
|
|
110
|
|
|
111 Otherwise, build the libFuzzer library as a static archive, without any sanitizer
|
|
120
|
112 options. Note that the libFuzzer library contains the ``main()`` function:
|
|
|
113
|
|
|
114 .. code-block:: console
|
|
|
115
|
|
|
116 svn co http://llvm.org/svn/llvm-project/llvm/trunk/lib/Fuzzer # or git clone https://chromium.googlesource.com/chromium/llvm-project/llvm/lib/Fuzzer
|
|
|
117 ./Fuzzer/build.sh # Produces libFuzzer.a
|
|
|
118
|
|
|
119 Then build the fuzzing target function and the library under test using
|
|
|
120 the SanitizerCoverage_ option, which instruments the code so that the fuzzer
|
|
|
121 can retrieve code coverage information (to guide the fuzzing). Linking with
|
|
|
122 the libFuzzer code then gives a fuzzer executable.
|
|
|
123
|
|
|
124 You should also enable one or more of the *sanitizers*, which help to expose
|
|
|
125 latent bugs by making incorrect behavior generate errors at runtime:
|
|
|
126
|
|
|
127 - AddressSanitizer_ (ASAN) detects memory access errors. Use `-fsanitize=address`.
|
|
|
128 - UndefinedBehaviorSanitizer_ (UBSAN) detects the use of various features of C/C++ that are explicitly
|
|
|
129 listed as resulting in undefined behavior. Use `-fsanitize=undefined -fno-sanitize-recover=undefined`
|
|
|
130 or any individual UBSAN check, e.g. `-fsanitize=signed-integer-overflow -fno-sanitize-recover=undefined`.
|
|
|
131 You may combine ASAN and UBSAN in one build.
|
|
|
132 - MemorySanitizer_ (MSAN) detects uninitialized reads: code whose behavior relies on memory
|
|
|
133 contents that have not been initialized to a specific value. Use `-fsanitize=memory`.
|
|
|
134 MSAN can not be combined with other sanirizers and should be used as a seprate build.
|
|
|
135
|
|
|
136 Finally, link with ``libFuzzer.a``::
|
|
|
137
|
|
|
138 clang -fsanitize-coverage=trace-pc-guard -fsanitize=address your_lib.cc fuzz_target.cc libFuzzer.a -o my_fuzzer
|
|
|
139
|
|
121
|
140 .. _libfuzzer-corpus:
|
|
|
141
|
|
120
|
142 Corpus
|
|
|
143 ------
|
|
|
144
|
|
|
145 Coverage-guided fuzzers like libFuzzer rely on a corpus of sample inputs for the
|
|
|
146 code under test. This corpus should ideally be seeded with a varied collection
|
|
|
147 of valid and invalid inputs for the code under test; for example, for a graphics
|
|
|
148 library the initial corpus might hold a variety of different small PNG/JPG/GIF
|
|
|
149 files. The fuzzer generates random mutations based around the sample inputs in
|
|
|
150 the current corpus. If a mutation triggers execution of a previously-uncovered
|
|
|
151 path in the code under test, then that mutation is saved to the corpus for
|
|
|
152 future variations.
|
|
|
153
|
|
|
154 LibFuzzer will work without any initial seeds, but will be less
|
|
|
155 efficient if the library under test accepts complex,
|
|
|
156 structured inputs.
|
|
|
157
|
|
|
158 The corpus can also act as a sanity/regression check, to confirm that the
|
|
|
159 fuzzing entrypoint still works and that all of the sample inputs run through
|
|
|
160 the code under test without problems.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
161
|
|
120
|
162 If you have a large corpus (either generated by fuzzing or acquired by other means)
|
|
|
163 you may want to minimize it while still preserving the full coverage. One way to do that
|
|
|
164 is to use the `-merge=1` flag:
|
|
|
165
|
|
|
166 .. code-block:: console
|
|
|
167
|
|
|
168 mkdir NEW_CORPUS_DIR # Store minimized corpus here.
|
|
|
169 ./my_fuzzer -merge=1 NEW_CORPUS_DIR FULL_CORPUS_DIR
|
|
|
170
|
|
|
171 You may use the same flag to add more interesting items to an existing corpus.
|
|
|
172 Only the inputs that trigger new coverage will be added to the first corpus.
|
|
|
173
|
|
|
174 .. code-block:: console
|
|
|
175
|
|
|
176 ./my_fuzzer -merge=1 CURRENT_CORPUS_DIR NEW_POTENTIALLY_INTERESTING_INPUTS_DIR
|
|
|
177
|
|
|
178
|
|
|
179 Running
|
|
|
180 -------
|
|
|
181
|
|
|
182 To run the fuzzer, first create a Corpus_ directory that holds the
|
|
|
183 initial "seed" sample inputs:
|
|
|
184
|
|
|
185 .. code-block:: console
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
186
|
|
120
|
187 mkdir CORPUS_DIR
|
|
|
188 cp /some/input/samples/* CORPUS_DIR
|
|
|
189
|
|
|
190 Then run the fuzzer on the corpus directory:
|
|
|
191
|
|
|
192 .. code-block:: console
|
|
|
193
|
|
|
194 ./my_fuzzer CORPUS_DIR # -max_len=1000 -jobs=20 ...
|
|
|
195
|
|
|
196 As the fuzzer discovers new interesting test cases (i.e. test cases that
|
|
|
197 trigger coverage of new paths through the code under test), those test cases
|
|
|
198 will be added to the corpus directory.
|
|
|
199
|
|
|
200 By default, the fuzzing process will continue indefinitely – at least until
|
|
|
201 a bug is found. Any crashes or sanitizer failures will be reported as usual,
|
|
|
202 stopping the fuzzing process, and the particular input that triggered the bug
|
|
|
203 will be written to disk (typically as ``crash-<sha1>``, ``leak-<sha1>``,
|
|
|
204 or ``timeout-<sha1>``).
|
|
|
205
|
|
|
206
|
|
|
207 Parallel Fuzzing
|
|
|
208 ----------------
|
|
|
209
|
|
|
210 Each libFuzzer process is single-threaded, unless the library under test starts
|
|
|
211 its own threads. However, it is possible to run multiple libFuzzer processes in
|
|
|
212 parallel with a shared corpus directory; this has the advantage that any new
|
|
|
213 inputs found by one fuzzer process will be available to the other fuzzer
|
|
|
214 processes (unless you disable this with the ``-reload=0`` option).
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
215
|
|
120
|
216 This is primarily controlled by the ``-jobs=N`` option, which indicates that
|
|
|
217 that `N` fuzzing jobs should be run to completion (i.e. until a bug is found or
|
|
|
218 time/iteration limits are reached). These jobs will be run across a set of
|
|
|
219 worker processes, by default using half of the available CPU cores; the count of
|
|
|
220 worker processes can be overridden by the ``-workers=N`` option. For example,
|
|
|
221 running with ``-jobs=30`` on a 12-core machine would run 6 workers by default,
|
|
|
222 with each worker averaging 5 bugs by completion of the entire process.
|
|
|
223
|
|
|
224
|
|
|
225 Options
|
|
|
226 =======
|
|
|
227
|
|
|
228 To run the fuzzer, pass zero or more corpus directories as command line
|
|
|
229 arguments. The fuzzer will read test inputs from each of these corpus
|
|
|
230 directories, and any new test inputs that are generated will be written
|
|
|
231 back to the first corpus directory:
|
|
|
232
|
|
|
233 .. code-block:: console
|
|
|
234
|
|
|
235 ./fuzzer [-flag1=val1 [-flag2=val2 ...] ] [dir1 [dir2 ...] ]
|
|
|
236
|
|
|
237 If a list of files (rather than directories) are passed to the fuzzer program,
|
|
|
238 then it will re-run those files as test inputs but will not perform any fuzzing.
|
|
|
239 In this mode the fuzzer binary can be used as a regression test (e.g. on a
|
|
|
240 continuous integration system) to check the target function and saved inputs
|
|
|
241 still work.
|
|
|
242
|
|
|
243 The most important command line options are:
|
|
|
244
|
|
|
245 ``-help``
|
|
|
246 Print help message.
|
|
|
247 ``-seed``
|
|
|
248 Random seed. If 0 (the default), the seed is generated.
|
|
|
249 ``-runs``
|
|
|
250 Number of individual test runs, -1 (the default) to run indefinitely.
|
|
|
251 ``-max_len``
|
|
|
252 Maximum length of a test input. If 0 (the default), libFuzzer tries to guess
|
|
|
253 a good value based on the corpus (and reports it).
|
|
|
254 ``-timeout``
|
|
|
255 Timeout in seconds, default 1200. If an input takes longer than this timeout,
|
|
|
256 the process is treated as a failure case.
|
|
|
257 ``-rss_limit_mb``
|
|
|
258 Memory usage limit in Mb, default 2048. Use 0 to disable the limit.
|
|
|
259 If an input requires more than this amount of RSS memory to execute,
|
|
|
260 the process is treated as a failure case.
|
|
|
261 The limit is checked in a separate thread every second.
|
|
|
262 If running w/o ASAN/MSAN, you may use 'ulimit -v' instead.
|
|
|
263 ``-timeout_exitcode``
|
|
|
264 Exit code (default 77) used if libFuzzer reports a timeout.
|
|
|
265 ``-error_exitcode``
|
|
|
266 Exit code (default 77) used if libFuzzer itself (not a sanitizer) reports a bug (leak, OOM, etc).
|
|
|
267 ``-max_total_time``
|
|
|
268 If positive, indicates the maximum total time in seconds to run the fuzzer.
|
|
|
269 If 0 (the default), run indefinitely.
|
|
|
270 ``-merge``
|
|
|
271 If set to 1, any corpus inputs from the 2nd, 3rd etc. corpus directories
|
|
|
272 that trigger new code coverage will be merged into the first corpus
|
|
|
273 directory. Defaults to 0. This flag can be used to minimize a corpus.
|
|
|
274 ``-minimize_crash``
|
|
|
275 If 1, minimizes the provided crash input.
|
|
|
276 Use with -runs=N or -max_total_time=N to limit the number of attempts.
|
|
|
277 ``-reload``
|
|
|
278 If set to 1 (the default), the corpus directory is re-read periodically to
|
|
|
279 check for new inputs; this allows detection of new inputs that were discovered
|
|
|
280 by other fuzzing processes.
|
|
|
281 ``-jobs``
|
|
|
282 Number of fuzzing jobs to run to completion. Default value is 0, which runs a
|
|
|
283 single fuzzing process until completion. If the value is >= 1, then this
|
|
|
284 number of jobs performing fuzzing are run, in a collection of parallel
|
|
|
285 separate worker processes; each such worker process has its
|
|
|
286 ``stdout``/``stderr`` redirected to ``fuzz-<JOB>.log``.
|
|
|
287 ``-workers``
|
|
|
288 Number of simultaneous worker processes to run the fuzzing jobs to completion
|
|
|
289 in. If 0 (the default), ``min(jobs, NumberOfCpuCores()/2)`` is used.
|
|
|
290 ``-dict``
|
|
|
291 Provide a dictionary of input keywords; see Dictionaries_.
|
|
|
292 ``-use_counters``
|
|
|
293 Use `coverage counters`_ to generate approximate counts of how often code
|
|
|
294 blocks are hit; defaults to 1.
|
|
|
295 ``-use_value_profile``
|
|
|
296 Use `value profile`_ to guide corpus expansion; defaults to 0.
|
|
|
297 ``-only_ascii``
|
|
|
298 If 1, generate only ASCII (``isprint``+``isspace``) inputs. Defaults to 0.
|
|
|
299 ``-artifact_prefix``
|
|
|
300 Provide a prefix to use when saving fuzzing artifacts (crash, timeout, or
|
|
|
301 slow inputs) as ``$(artifact_prefix)file``. Defaults to empty.
|
|
|
302 ``-exact_artifact_path``
|
|
|
303 Ignored if empty (the default). If non-empty, write the single artifact on
|
|
|
304 failure (crash, timeout) as ``$(exact_artifact_path)``. This overrides
|
|
|
305 ``-artifact_prefix`` and will not use checksum in the file name. Do not use
|
|
|
306 the same path for several parallel processes.
|
|
|
307 ``-print_pcs``
|
|
|
308 If 1, print out newly covered PCs. Defaults to 0.
|
|
|
309 ``-print_final_stats``
|
|
|
310 If 1, print statistics at exit. Defaults to 0.
|
|
|
311 ``-detect_leaks``
|
|
|
312 If 1 (default) and if LeakSanitizer is enabled
|
|
|
313 try to detect memory leaks during fuzzing (i.e. not only at shut down).
|
|
|
314 ``-close_fd_mask``
|
|
|
315 Indicate output streams to close at startup. Be careful, this will
|
|
|
316 remove diagnostic output from target code (e.g. messages on assert failure).
|
|
|
317
|
|
|
318 - 0 (default): close neither ``stdout`` nor ``stderr``
|
|
|
319 - 1 : close ``stdout``
|
|
|
320 - 2 : close ``stderr``
|
|
|
321 - 3 : close both ``stdout`` and ``stderr``.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
322
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
323 For the full list of flags run the fuzzer binary with ``-help=1``.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
324
|
|
120
|
325 Output
|
|
|
326 ======
|
|
|
327
|
|
|
328 During operation the fuzzer prints information to ``stderr``, for example::
|
|
|
329
|
|
|
330 INFO: Seed: 1523017872
|
|
|
331 INFO: Loaded 1 modules (16 guards): [0x744e60, 0x744ea0),
|
|
|
332 INFO: -max_len is not provided, using 64
|
|
|
333 INFO: A corpus is not provided, starting from an empty corpus
|
|
|
334 #0 READ units: 1
|
|
|
335 #1 INITED cov: 3 ft: 2 corp: 1/1b exec/s: 0 rss: 24Mb
|
|
|
336 #3811 NEW cov: 4 ft: 3 corp: 2/2b exec/s: 0 rss: 25Mb L: 1 MS: 5 ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ChangeByte-
|
|
|
337 #3827 NEW cov: 5 ft: 4 corp: 3/4b exec/s: 0 rss: 25Mb L: 2 MS: 1 CopyPart-
|
|
|
338 #3963 NEW cov: 6 ft: 5 corp: 4/6b exec/s: 0 rss: 25Mb L: 2 MS: 2 ShuffleBytes-ChangeBit-
|
|
|
339 #4167 NEW cov: 7 ft: 6 corp: 5/9b exec/s: 0 rss: 25Mb L: 3 MS: 1 InsertByte-
|
|
|
340 ...
|
|
|
341
|
|
|
342 The early parts of the output include information about the fuzzer options and
|
|
|
343 configuration, including the current random seed (in the ``Seed:`` line; this
|
|
|
344 can be overridden with the ``-seed=N`` flag).
|
|
|
345
|
|
|
346 Further output lines have the form of an event code and statistics. The
|
|
|
347 possible event codes are:
|
|
|
348
|
|
|
349 ``READ``
|
|
|
350 The fuzzer has read in all of the provided input samples from the corpus
|
|
|
351 directories.
|
|
|
352 ``INITED``
|
|
|
353 The fuzzer has completed initialization, which includes running each of
|
|
|
354 the initial input samples through the code under test.
|
|
|
355 ``NEW``
|
|
|
356 The fuzzer has created a test input that covers new areas of the code
|
|
|
357 under test. This input will be saved to the primary corpus directory.
|
|
121
|
358 ``REDUCE``
|
|
|
359 The fuzzer has found a better (smaller) input that triggers previously
|
|
|
360 discovered features (set ``-reduce_inputs=0`` to disable).
|
|
120
|
361 ``pulse``
|
|
|
362 The fuzzer has generated 2\ :sup:`n` inputs (generated periodically to reassure
|
|
|
363 the user that the fuzzer is still working).
|
|
|
364 ``DONE``
|
|
|
365 The fuzzer has completed operation because it has reached the specified
|
|
|
366 iteration limit (``-runs``) or time limit (``-max_total_time``).
|
|
|
367 ``RELOAD``
|
|
|
368 The fuzzer is performing a periodic reload of inputs from the corpus
|
|
|
369 directory; this allows it to discover any inputs discovered by other
|
|
|
370 fuzzer processes (see `Parallel Fuzzing`_).
|
|
|
371
|
|
|
372 Each output line also reports the following statistics (when non-zero):
|
|
|
373
|
|
|
374 ``cov:``
|
|
|
375 Total number of code blocks or edges covered by the executing the current
|
|
|
376 corpus.
|
|
|
377 ``ft:``
|
|
|
378 libFuzzer uses different signals to evaluate the code coverage:
|
|
|
379 edge coverage, edge counters, value profiles, indirect caller/callee pairs, etc.
|
|
|
380 These signals combined are called *features* (`ft:`).
|
|
|
381 ``corp:``
|
|
|
382 Number of entries in the current in-memory test corpus and its size in bytes.
|
|
|
383 ``exec/s:``
|
|
|
384 Number of fuzzer iterations per second.
|
|
|
385 ``rss:``
|
|
|
386 Current memory consumption.
|
|
|
387
|
|
|
388 For ``NEW`` events, the output line also includes information about the mutation
|
|
|
389 operation that produced the new input:
|
|
|
390
|
|
|
391 ``L:``
|
|
|
392 Size of the new input in bytes.
|
|
|
393 ``MS: <n> <operations>``
|
|
|
394 Count and list of the mutation operations used to generate the input.
|
|
|
395
|
|
|
396
|
|
|
397 Examples
|
|
|
398 ========
|
|
|
399 .. contents::
|
|
|
400 :local:
|
|
|
401 :depth: 1
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
402
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
403 Toy example
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
404 -----------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
405
|
|
120
|
406 A simple function that does something interesting if it receives the input
|
|
|
407 "HI!"::
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
408
|
|
120
|
409 cat << EOF > test_fuzzer.cc
|
|
100
|
410 #include <stdint.h>
|
|
|
411 #include <stddef.h>
|
|
|
412 extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
413 if (size > 0 && data[0] == 'H')
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
414 if (size > 1 && data[1] == 'I')
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
415 if (size > 2 && data[2] == '!')
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
416 __builtin_trap();
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
417 return 0;
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
418 }
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
419 EOF
|
|
120
|
420 # Build test_fuzzer.cc with asan and link against libFuzzer.a
|
|
|
421 clang++ -fsanitize=address -fsanitize-coverage=trace-pc-guard test_fuzzer.cc libFuzzer.a
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
422 # Run the fuzzer with no corpus.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
423 ./a.out
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
424
|
|
120
|
425 You should get an error pretty quickly::
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
426
|
|
120
|
427 INFO: Seed: 1523017872
|
|
|
428 INFO: Loaded 1 modules (16 guards): [0x744e60, 0x744ea0),
|
|
|
429 INFO: -max_len is not provided, using 64
|
|
|
430 INFO: A corpus is not provided, starting from an empty corpus
|
|
|
431 #0 READ units: 1
|
|
|
432 #1 INITED cov: 3 ft: 2 corp: 1/1b exec/s: 0 rss: 24Mb
|
|
|
433 #3811 NEW cov: 4 ft: 3 corp: 2/2b exec/s: 0 rss: 25Mb L: 1 MS: 5 ChangeBit-ChangeByte-ChangeBit-ShuffleBytes-ChangeByte-
|
|
|
434 #3827 NEW cov: 5 ft: 4 corp: 3/4b exec/s: 0 rss: 25Mb L: 2 MS: 1 CopyPart-
|
|
|
435 #3963 NEW cov: 6 ft: 5 corp: 4/6b exec/s: 0 rss: 25Mb L: 2 MS: 2 ShuffleBytes-ChangeBit-
|
|
|
436 #4167 NEW cov: 7 ft: 6 corp: 5/9b exec/s: 0 rss: 25Mb L: 3 MS: 1 InsertByte-
|
|
|
437 ==31511== ERROR: libFuzzer: deadly signal
|
|
|
438 ...
|
|
|
439 artifact_prefix='./'; Test unit written to ./crash-b13e8756b13a00cf168300179061fb4b91fefbed
|
|
100
|
440
|
|
120
|
441
|
|
|
442 More examples
|
|
|
443 -------------
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
444
|
|
120
|
445 Examples of real-life fuzz targets and the bugs they find can be found
|
|
|
446 at http://tutorial.libfuzzer.info. Among other things you can learn how
|
|
|
447 to detect Heartbleed_ in one second.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
448
|
|
100
|
449
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
450 Advanced features
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
451 =================
|
|
120
|
452 .. contents::
|
|
|
453 :local:
|
|
|
454 :depth: 1
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
455
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
456 Dictionaries
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
457 ------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
458 LibFuzzer supports user-supplied dictionaries with input language keywords
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
459 or other interesting byte sequences (e.g. multi-byte magic values).
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
460 Use ``-dict=DICTIONARY_FILE``. For some input languages using a dictionary
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
461 may significantly improve the search speed.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
462 The dictionary syntax is similar to that used by AFL_ for its ``-x`` option::
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
463
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
464 # Lines starting with '#' and empty lines are ignored.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
465
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
466 # Adds "blah" (w/o quotes) to the dictionary.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
467 kw1="blah"
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
468 # Use \\ for backslash and \" for quotes.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
469 kw2="\"ac\\dc\""
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
470 # Use \xAB for hex values
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
471 kw3="\xF7\xF8"
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
472 # the name of the keyword followed by '=' may be omitted:
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
473 "foo\x0Abar"
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
474
|
|
120
|
475
|
|
|
476
|
|
|
477 Tracing CMP instructions
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
478 ------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
479
|
|
120
|
480 With an additional compiler flag ``-fsanitize-coverage=trace-cmp``
|
|
|
481 (see SanitizerCoverageTraceDataFlow_)
|
|
|
482 libFuzzer will intercept CMP instructions and guide mutations based
|
|
|
483 on the arguments of intercepted CMP instructions. This may slow down
|
|
|
484 the fuzzing but is very likely to improve the results.
|
|
|
485
|
|
|
486 Value Profile
|
|
|
487 -------------
|
|
|
488
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
489 *EXPERIMENTAL*.
|
|
120
|
490 With ``-fsanitize-coverage=trace-cmp``
|
|
|
491 and extra run-time flag ``-use_value_profile=1`` the fuzzer will
|
|
|
492 collect value profiles for the parameters of compare instructions
|
|
|
493 and treat some new values as new coverage.
|
|
|
494
|
|
|
495 The current imlpementation does roughly the following:
|
|
|
496
|
|
|
497 * The compiler instruments all CMP instructions with a callback that receives both CMP arguments.
|
|
|
498 * The callback computes `(caller_pc&4095) | (popcnt(Arg1 ^ Arg2) << 12)` and uses this value to set a bit in a bitset.
|
|
|
499 * Every new observed bit in the bitset is treated as new coverage.
|
|
|
500
|
|
|
501
|
|
|
502 This feature has a potential to discover many interesting inputs,
|
|
|
503 but there are two downsides.
|
|
|
504 First, the extra instrumentation may bring up to 2x additional slowdown.
|
|
|
505 Second, the corpus may grow by several times.
|
|
|
506
|
|
|
507 Fuzzer-friendly build mode
|
|
|
508 ---------------------------
|
|
|
509 Sometimes the code under test is not fuzzing-friendly. Examples:
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
510
|
|
120
|
511 - The target code uses a PRNG seeded e.g. by system time and
|
|
|
512 thus two consequent invocations may potentially execute different code paths
|
|
|
513 even if the end result will be the same. This will cause a fuzzer to treat
|
|
|
514 two similar inputs as significantly different and it will blow up the test corpus.
|
|
|
515 E.g. libxml uses ``rand()`` inside its hash table.
|
|
|
516 - The target code uses checksums to protect from invalid inputs.
|
|
|
517 E.g. png checks CRC for every chunk.
|
|
|
518
|
|
|
519 In many cases it makes sense to build a special fuzzing-friendly build
|
|
|
520 with certain fuzzing-unfriendly features disabled. We propose to use a common build macro
|
|
|
521 for all such cases for consistency: ``FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION``.
|
|
|
522
|
|
|
523 .. code-block:: c++
|
|
|
524
|
|
|
525 void MyInitPRNG() {
|
|
|
526 #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION
|
|
|
527 // In fuzzing mode the behavior of the code should be deterministic.
|
|
|
528 srand(0);
|
|
|
529 #else
|
|
|
530 srand(time(0));
|
|
|
531 #endif
|
|
|
532 }
|
|
|
533
|
|
|
534
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
535
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
536 AFL compatibility
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
537 -----------------
|
|
120
|
538 LibFuzzer can be used together with AFL_ on the same test corpus.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
539 Both fuzzers expect the test corpus to reside in a directory, one file per input.
|
|
120
|
540 You can run both fuzzers on the same corpus, one after another:
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
541
|
|
120
|
542 .. code-block:: console
|
|
|
543
|
|
|
544 ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
545 ./llvm-fuzz testcase_dir findings_dir # Will write new tests to testcase_dir
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
546
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
547 Periodically restart both fuzzers so that they can use each other's findings.
|
|
120
|
548 Currently, there is no simple way to run both fuzzing engines in parallel while sharing the same corpus dir.
|
|
|
549
|
|
|
550 You may also use AFL on your target function ``LLVMFuzzerTestOneInput``:
|
|
|
551 see an example `here <https://github.com/llvm-mirror/llvm/blob/master/lib/Fuzzer/afl/afl_driver.cpp>`__.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
552
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
553 How good is my fuzzer?
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
554 ----------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
555
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
556 Once you implement your target function ``LLVMFuzzerTestOneInput`` and fuzz it to death,
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
557 you will want to know whether the function or the corpus can be improved further.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
558 One easy to use metric is, of course, code coverage.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
559
|
|
121
|
560 We recommend to use
|
|
|
561 `Clang Coverage <http://clang.llvm.org/docs/SourceBasedCodeCoverage.html>`_,
|
|
|
562 to visualize and study your code coverage
|
|
|
563 (`example <https://github.com/google/fuzzer-test-suite/blob/master/tutorial/libFuzzerTutorial.md#visualizing-coverage>`_).
|
|
120
|
564
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
565
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
566 User-supplied mutators
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
567 ----------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
568
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
569 LibFuzzer allows to use custom (user-supplied) mutators,
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
570 see FuzzerInterface.h_
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
571
|
|
100
|
572 Startup initialization
|
|
|
573 ----------------------
|
|
|
574 If the library being tested needs to be initialized, there are several options.
|
|
|
575
|
|
120
|
576 The simplest way is to have a statically initialized global object inside
|
|
|
577 `LLVMFuzzerTestOneInput` (or in global scope if that works for you):
|
|
100
|
578
|
|
120
|
579 .. code-block:: c++
|
|
|
580
|
|
|
581 extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) {
|
|
|
582 static bool Initialized = DoInitialization();
|
|
|
583 ...
|
|
100
|
584
|
|
|
585 Alternatively, you may define an optional init function and it will receive
|
|
120
|
586 the program arguments that you can read and modify. Do this **only** if you
|
|
121
|
587 really need to access ``argv``/``argc``.
|
|
120
|
588
|
|
|
589 .. code-block:: c++
|
|
100
|
590
|
|
|
591 extern "C" int LLVMFuzzerInitialize(int *argc, char ***argv) {
|
|
|
592 ReadAndMaybeModify(argc, argv);
|
|
|
593 return 0;
|
|
|
594 }
|
|
|
595
|
|
120
|
596
|
|
|
597 Leaks
|
|
|
598 -----
|
|
100
|
599
|
|
120
|
600 Binaries built with AddressSanitizer_ or LeakSanitizer_ will try to detect
|
|
|
601 memory leaks at the process shutdown.
|
|
|
602 For in-process fuzzing this is inconvenient
|
|
|
603 since the fuzzer needs to report a leak with a reproducer as soon as the leaky
|
|
|
604 mutation is found. However, running full leak detection after every mutation
|
|
|
605 is expensive.
|
|
100
|
606
|
|
120
|
607 By default (``-detect_leaks=1``) libFuzzer will count the number of
|
|
|
608 ``malloc`` and ``free`` calls when executing every mutation.
|
|
|
609 If the numbers don't match (which by itself doesn't mean there is a leak)
|
|
|
610 libFuzzer will invoke the more expensive LeakSanitizer_
|
|
|
611 pass and if the actual leak is found, it will be reported with the reproducer
|
|
|
612 and the process will exit.
|
|
|
613
|
|
|
614 If your target has massive leaks and the leak detection is disabled
|
|
|
615 you will eventually run out of RAM (see the ``-rss_limit_mb`` flag).
|
|
|
616
|
|
|
617
|
|
|
618 Developing libFuzzer
|
|
|
619 ====================
|
|
|
620
|
|
121
|
621 LibFuzzer is built as a part of LLVM project by default on macos and Linux.
|
|
|
622 Users of other operating systems can explicitly request compilation using
|
|
|
623 ``-DLIBFUZZER_ENABLE=YES`` flag.
|
|
|
624 Tests are run using ``check-fuzzer`` target from the build directory
|
|
|
625 which was configured with ``-DLIBFUZZER_ENABLE_TESTS=ON`` flag.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
626
|
|
120
|
627 .. code-block:: console
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
628
|
|
121
|
629 ninja check-fuzzer
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
630
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
631
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
632 FAQ
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
633 =========================
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
634
|
|
120
|
635 Q. Why doesn't libFuzzer use any of the LLVM support?
|
|
|
636 -----------------------------------------------------
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
637
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
638 There are two reasons.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
639
|
|
120
|
640 First, we want this library to be used outside of the LLVM without users having to
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
641 build the rest of LLVM. This may sound unconvincing for many LLVM folks,
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
642 but in practice the need for building the whole LLVM frightens many potential
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
643 users -- and we want more users to use this code.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
644
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
645 Second, there is a subtle technical reason not to rely on the rest of LLVM, or
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
646 any other large body of code (maybe not even STL). When coverage instrumentation
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
647 is enabled, it will also instrument the LLVM support code which will blow up the
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
648 coverage set of the process (since the fuzzer is in-process). In other words, by
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
649 using more external dependencies we will slow down the fuzzer while the main
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
650 reason for it to exist is extreme speed.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
651
|
|
120
|
652 Q. What about Windows then? The fuzzer contains code that does not build on Windows.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
653 ------------------------------------------------------------------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
654
|
|
120
|
655 Volunteers are welcome.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
656
|
|
120
|
657 Q. When libFuzzer is not a good solution for a problem?
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
658 ---------------------------------------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
659
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
660 * If the test inputs are validated by the target library and the validator
|
|
120
|
661 asserts/crashes on invalid inputs, in-process fuzzing is not applicable.
|
|
|
662 * Bugs in the target library may accumulate without being detected. E.g. a memory
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
663 corruption that goes undetected at first and then leads to a crash while
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
664 testing another input. This is why it is highly recommended to run this
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
665 in-process fuzzer with all sanitizers to detect most bugs on the spot.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
666 * It is harder to protect the in-process fuzzer from excessive memory
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
667 consumption and infinite loops in the target library (still possible).
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
668 * The target library should not have significant global state that is not
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
669 reset between the runs.
|
|
120
|
670 * Many interesting target libraries are not designed in a way that supports
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
671 the in-process fuzzer interface (e.g. require a file path instead of a
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
672 byte array).
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
673 * If a single test run takes a considerable fraction of a second (or
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
674 more) the speed benefit from the in-process fuzzer is negligible.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
675 * If the target library runs persistent threads (that outlive
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
676 execution of one test) the fuzzing results will be unreliable.
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
677
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
678 Q. So, what exactly this Fuzzer is good for?
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
679 --------------------------------------------
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
680
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
681 This Fuzzer might be a good choice for testing libraries that have relatively
|
|
120
|
682 small inputs, each input takes < 10ms to run, and the library code is not expected
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
683 to crash on invalid inputs.
|
|
120
|
684 Examples: regular expression matchers, text or binary format parsers, compression,
|
|
|
685 network, crypto.
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
686
|
|
121
|
687
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
688 Trophies
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
689 ========
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
690 * GLIBC: https://sourceware.org/glibc/wiki/FuzzingLibc
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
691
|
|
120
|
692 * MUSL LIBC: `[1] <http://git.musl-libc.org/cgit/musl/commit/?id=39dfd58417ef642307d90306e1c7e50aaec5a35c>`__ `[2] <http://www.openwall.com/lists/oss-security/2015/03/30/3>`__
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
693
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
694 * `pugixml <https://github.com/zeux/pugixml/issues/39>`_
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
695
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
696 * PCRE: Search for "LLVM fuzzer" in http://vcs.pcre.org/pcre2/code/trunk/ChangeLog?view=markup;
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
697 also in `bugzilla <https://bugs.exim.org/buglist.cgi?bug_status=__all__&content=libfuzzer&no_redirect=1&order=Importance&product=PCRE&query_format=specific>`_
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
698
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
699 * `ICU <http://bugs.icu-project.org/trac/ticket/11838>`_
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
700
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
701 * `Freetype <https://savannah.nongnu.org/search/?words=LibFuzzer&type_of_search=bugs&Search=Search&exact=1#options>`_
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
702
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
703 * `Harfbuzz <https://github.com/behdad/harfbuzz/issues/139>`_
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
704
|
|
100
|
705 * `SQLite <http://www3.sqlite.org/cgi/src/info/088009efdd56160b>`_
|
|
|
706
|
|
|
707 * `Python <http://bugs.python.org/issue25388>`_
|
|
|
708
|
|
120
|
709 * OpenSSL/BoringSSL: `[1] <https://boringssl.googlesource.com/boringssl/+/cb852981cd61733a7a1ae4fd8755b7ff950e857d>`_ `[2] <https://openssl.org/news/secadv/20160301.txt>`_ `[3] <https://boringssl.googlesource.com/boringssl/+/2b07fa4b22198ac02e0cee8f37f3337c3dba91bc>`_ `[4] <https://boringssl.googlesource.com/boringssl/+/6b6e0b20893e2be0e68af605a60ffa2cbb0ffa64>`_ `[5] <https://github.com/openssl/openssl/pull/931/commits/dd5ac557f052cc2b7f718ac44a8cb7ac6f77dca8>`_ `[6] <https://github.com/openssl/openssl/pull/931/commits/19b5b9194071d1d84e38ac9a952e715afbc85a81>`_
|
|
100
|
710
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
711 * `Libxml2
|
|
120
|
712 <https://bugzilla.gnome.org/buglist.cgi?bug_status=__all__&content=libFuzzer&list_id=68957&order=Importance&product=libxml2&query_format=specific>`_ and `[HT206167] <https://support.apple.com/en-gb/HT206167>`_ (CVE-2015-5312, CVE-2015-7500, CVE-2015-7942)
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
713
|
|
100
|
714 * `Linux Kernel's BPF verifier <https://github.com/iovisor/bpf-fuzzer>`_
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
715
|
|
120
|
716 * Capstone: `[1] <https://github.com/aquynh/capstone/issues/600>`__ `[2] <https://github.com/aquynh/capstone/commit/6b88d1d51eadf7175a8f8a11b690684443b11359>`__
|
|
|
717
|
|
|
718 * file:`[1] <http://bugs.gw.com/view.php?id=550>`__ `[2] <http://bugs.gw.com/view.php?id=551>`__ `[3] <http://bugs.gw.com/view.php?id=553>`__ `[4] <http://bugs.gw.com/view.php?id=554>`__
|
|
|
719
|
|
|
720 * Radare2: `[1] <https://github.com/revskills?tab=contributions&from=2016-04-09>`__
|
|
|
721
|
|
|
722 * gRPC: `[1] <https://github.com/grpc/grpc/pull/6071/commits/df04c1f7f6aec6e95722ec0b023a6b29b6ea871c>`__ `[2] <https://github.com/grpc/grpc/pull/6071/commits/22a3dfd95468daa0db7245a4e8e6679a52847579>`__ `[3] <https://github.com/grpc/grpc/pull/6071/commits/9cac2a12d9e181d130841092e9d40fa3309d7aa7>`__ `[4] <https://github.com/grpc/grpc/pull/6012/commits/82a91c91d01ce9b999c8821ed13515883468e203>`__ `[5] <https://github.com/grpc/grpc/pull/6202/commits/2e3e0039b30edaf89fb93bfb2c1d0909098519fa>`__ `[6] <https://github.com/grpc/grpc/pull/6106/files>`__
|
|
|
723
|
|
|
724 * WOFF2: `[1] <https://github.com/google/woff2/commit/a15a8ab>`__
|
|
|
725
|
|
|
726 * LLVM: `Clang <https://llvm.org/bugs/show_bug.cgi?id=23057>`_, `Clang-format <https://llvm.org/bugs/show_bug.cgi?id=23052>`_, `libc++ <https://llvm.org/bugs/show_bug.cgi?id=24411>`_, `llvm-as <https://llvm.org/bugs/show_bug.cgi?id=24639>`_, `Demangler <https://bugs.chromium.org/p/chromium/issues/detail?id=606626>`_, Disassembler: http://reviews.llvm.org/rL247405, http://reviews.llvm.org/rL247414, http://reviews.llvm.org/rL247416, http://reviews.llvm.org/rL247417, http://reviews.llvm.org/rL247420, http://reviews.llvm.org/rL247422.
|
|
|
727
|
|
121
|
728 * Tensorflow: `[1] <https://da-data.blogspot.com/2017/01/finding-bugs-in-tensorflow-with.html>`__
|
|
120
|
729
|
|
|
730 * Ffmpeg: `[1] <https://github.com/FFmpeg/FFmpeg/commit/c92f55847a3d9cd12db60bfcd0831ff7f089c37c>`__ `[2] <https://github.com/FFmpeg/FFmpeg/commit/25ab1a65f3acb5ec67b53fb7a2463a7368f1ad16>`__ `[3] <https://github.com/FFmpeg/FFmpeg/commit/85d23e5cbc9ad6835eef870a5b4247de78febe56>`__ `[4] <https://github.com/FFmpeg/FFmpeg/commit/04bd1b38ee6b8df410d0ab8d4949546b6c4af26a>`__
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
731
|
|
121
|
732 * `Wireshark <https://bugs.wireshark.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&bug_status=INCOMPLETE&bug_status=RESOLVED&bug_status=VERIFIED&f0=OP&f1=OP&f2=product&f3=component&f4=alias&f5=short_desc&f7=content&f8=CP&f9=CP&j1=OR&o2=substring&o3=substring&o4=substring&o5=substring&o6=substring&o7=matches&order=bug_id%20DESC&query_format=advanced&v2=libfuzzer&v3=libfuzzer&v4=libfuzzer&v5=libfuzzer&v6=libfuzzer&v7=%22libfuzzer%22>`_
|
|
|
733
|
|
|
734 * `QEMU <https://researchcenter.paloaltonetworks.com/2017/09/unit42-palo-alto-networks-discovers-new-qemu-vulnerability/>`_
|
|
|
735
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
736 .. _pcre2: http://www.pcre.org/
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
737 .. _AFL: http://lcamtuf.coredump.cx/afl/
|
|
120
|
738 .. _Radamsa: https://github.com/aoh/radamsa
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
739 .. _SanitizerCoverage: http://clang.llvm.org/docs/SanitizerCoverage.html
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
740 .. _SanitizerCoverageTraceDataFlow: http://clang.llvm.org/docs/SanitizerCoverage.html#tracing-data-flow
|
|
120
|
741 .. _AddressSanitizer: http://clang.llvm.org/docs/AddressSanitizer.html
|
|
|
742 .. _LeakSanitizer: http://clang.llvm.org/docs/LeakSanitizer.html
|
95
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
743 .. _Heartbleed: http://en.wikipedia.org/wiki/Heartbleed
|
Kaito Tokumori <e105711@ie.u-ryukyu.ac.jp>
parents:
diff
changeset
|
744 .. _FuzzerInterface.h: https://github.com/llvm-mirror/llvm/blob/master/lib/Fuzzer/FuzzerInterface.h
|
|
120
|
745 .. _3.7.0: http://llvm.org/releases/3.7.0/docs/LibFuzzer.html
|
|
|
746 .. _building Clang from trunk: http://clang.llvm.org/get_started.html
|
|
|
747 .. _MemorySanitizer: http://clang.llvm.org/docs/MemorySanitizer.html
|
|
|
748 .. _UndefinedBehaviorSanitizer: http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
|
|
|
749 .. _`coverage counters`: http://clang.llvm.org/docs/SanitizerCoverage.html#coverage-counters
|
|
|
750 .. _`value profile`: #value-profile
|
|
|
751 .. _`caller-callee pairs`: http://clang.llvm.org/docs/SanitizerCoverage.html#caller-callee-coverage
|
|
|
752 .. _BoringSSL: https://boringssl.googlesource.com/boringssl/
|
|
121
|
753
|
