Fuzz Testing

Fuzz testing, or fuzzing which is a form of software testing that involves providing invalid, unexpected or random data input to the software application in an attempt to make it crash  (Rouse, 2016).  The concept behind fuzz testing is that software can have a lot of different bugs relating to data input.  For example, the input includes of different kinds of integers, character strings, floats and other variables which, if not entered correctly, may cause the software application to crash. A common example is an integer field that is meant to accommodate a few specific numbers such as one through five, but where a user can enter any integer because of the generic setup of the input field or control. Entering a value higher than five can cause the software application to crash (Techopedia, 2016).  From a security standpoint, if the fuzz testing causes the software application to crash it has a number of security concerns, least of which is the denial of service or availability or more severely the vulnerability that caused the crash could lead to exploitation by an attacker (Allen, 2010).  Fuzz testing is often employed as a form of black box testing, or testing a software application without knowing how the code works or how the software was designed (Beal, V, 2016).

In order to fuzz test a software application a program called a fuzzer is used.  A fuzzer generates and injects random data into a program and program stack to detect bugs or vulnerabilities.  The type of vectors that a fuzzer can inject into a program can be broken up into four categories: numbers such as integers, chars such as urls or command line inputs, metadata such as user-input and pure binary. Some “known to be dangerous” values of these categories are the following: for numbers, zeros or negative numbers; for chars, interpretable characters; and for binary, random ones. (OWASP, 2016 June 23).  Any type of inputs can be fuzz tested, file formats, network protocols, environment variables, API calls, keyboard and mouse events. Even other items that are not input can be fuzzed such as shared memory or the contents of databases (2016 Nov. 21, “Fuzz testing”).

Focusing back on Fuzzers, below is a short list of some open source fuzzers:

  • Afl-fuzz  –  designed to be practical with minimum effort requiring virtually no configuration, seamlessly handling complex real world cases such as image parsing. afl-fuzz uses genetic algorithms and compile-time instrumentation to discover test cases that trigger new internal states in the targeted binary (Zalewski, M., 2016).
  • Hodor Fuzzer – a general use fuzzer that can be configured to use known-good input and delimiters in order to fuzz specific locations.  It is designed to be a go between, being easier to use than a proper fuzzer that requires a lot of configuration (John, J., Hollembaek, B. and Arana, F., 2016 Aug. 30).
  • Sulley – a fuzzing framework and engine that consists of multiple extension-able components.  The developer’s goal is to simplify data representation, transmission and instrumentation.  Sulley not only focuses on data generation but also monitors the test target, capable of reverting to a good known state and automatically determine what unique sequence of test cases trigger faults (Sears, R., 2016 Oct. 17).

References: