AntiFuzz: Impeding Fuzzing Audits of Binary Executables

Fuzzing is one of the most widely used and successful methods of finding security vulnerabilities in software programs. Fuzzing tools automatically and randomly generates input to a program, and run the program using these inputs until it crashes. These crashes usually indicate the presence of a security vulnerability that can be exploited by an attacker.

But fuzzing can also be used by attackers who want to exploit the program. Can we therefore make our program difficult to fuzz so an attacker can not detect any hidden vulnerability in our program? To find out, the authors of this paper developed strategies that make fuzzing a program difficult. They identified some assumptions that existing fuzzing tools depend on to work successfully then developed a tool, AntiFuzz, that can be used to modify the target program and impede fuzzing. Some assumptions and counter-measures include:

1. Fuzzers try to generate inputs that can transverse all parts of the program code using coverage information. Hence, if we can make our program return false coverage information, fuzzing would be significantly impeded. To achieve this, AntiFuzz returns different, fake coverage information for each input to the program.

2. Fuzzers monitor the operating system in order to detect program crashes. To counter this, AntiFuzz sends fake crash signals to the operating systems.

3. Fuzzers need to execute the program many times per second in order to operate efficiently. Since most of the input generated by the fuzzers is malformed, AntiFuzz slows the program down when it detects such inputs. While this slowdown would not be noticed by a normal user, it can significantly impede the efficient operation of the fuzzer.

To see if their approach actually worked, the authors used four different state-of-the-art fuzzers to fuzz a set of target programs which contained several bugs. Their results show that AntiFuzz successfully prevented the detection of all bugs previously detected when all the counter-measures were applied.

I love their approach to impeding fuzzing because it combines multiple measures. However, by making the publicly deployed and accessible version of a program resistant to fuzzing, this would restrict the fuzzing operation to only the program developers, impeding the detection of security vulnerabilities by security researchers and white hat hackers who also rely on fuzzing.