index.md (1861B)
1 +++ 2 title = 'Fuzzing' 3 +++ 4 # Fuzzing 5 Looking for bugs: code review, static analysis, testing 6 - these are hard to scale 7 8 Fuzzing/fuzz testing: 9 - find vulnerabilities by repeatedly testing program with modified inputs 10 - different kinds of fuzzers 11 12 Different types of fuzzers: 13 - input: 14 - mutational 15 - mutate seed inputs to create new test inputs 16 - common mutations: 17 - bit flip: flip nth bit of input (e.g. AFL fuzzer) 18 - byte flip: flip nth byte of input 19 - arithmetic: add n, subtract n, multiply by n, etc. 20 - insert/delete n bytes in input 21 - cross-over: combine two inputs (e.g. Vuzzer) 22 - ideally want to select fitness: discard unsuccessful inputs 23 - fitness e.g. does input execute new code, does input get us close to some target code 24 - problem: many invalid inputs because lack of input format 25 - generative (know full input grammar) 26 - learn/create format/model on input, use it to generate new inputs 27 - problem: hard to get right input format, might miss bugs related to invalid inputs 28 - strategy: feedback, no feedback 29 - app transparency: black-box, grey-box, white-box 30 - black-box: only interface known. difficult to access effectiveness 31 - white-box: all is known. better understanding of effect of input, but slow and harder to scale 32 - grey-box: use some knowledge 33 - objective: guided/targeted, coverage-based 34 - coverage-based: the more code we cover, the more bugs we find (e.g. AFL, VUzzer) 35 - target: try to reach specific set of targets (e.g. Parmesan) 36 - hybrid: aim for targets while increasing coverage 37 38 Improving traditional fuzzing: 39 - apply heuristics to: 40 - mutate better 41 - learn good inputs 42 - apply analysis to understand application behavior 43 44 VUzzer: 45 46 