Menu
Fuzzing

What Is Feedback-Based Fuzzing?

Feedback-based fuzzing is a modern fuzzing technique used for security and stability testing of the codebase. The software under test is fed with a series of inputs, which are purposefully mutated in the testing process. The testing tool gets feedback about the code covered during the execution of inputs. Unlike traditional or black-box fuzzing, feedback-based fuzzing explores the program state efficiently and discovers bugs hidden deep in the code.

Code stocks filter

Advanced Technology

CI Fuzz utilizes several state-of-the-art fuzzing engines: libFuzzer with Sanitizers, AFL++, and honggfuzz, as well as other modern bug detection techniques, such as concolic execution. Additionally to the instrumentation, we use static code analysis to improve the effectiveness of the fuzzer. This allows CI Fuzz to provide enhanced fuzzing guidance, e.g. by using static analysis to learn which data structures are expected.

Demo plugin

IDE Plugin

The configuration of CI Fuzz is done via an IDE plugin which automates the preparation of the project so they can be fuzzed and helps the developer set up fuzz-targets. The user can interactively see which parts of the code were already covered by CI Fuzz, supply additional input grammars for fuzzing structured data and browse issues found by fuzz tests. This can be done by replying the problem in debugging mode to quickly understand and fix the issue.

Stairs filter

Continuous Integration

CI Fuzz integrates easily into a standard CI/CD workflow such as Jenkins. The fuzz tests are run automatically with each new commit and bugs are reported promptly. To increase the power of the fuzzing back-end, tests can be seamlessly scaled on-demand on a Kubernetes cluster.

Why Fuzz Testing?

Unit and integration tests are essential parts of the software development process. However, they have several limitations:

  • They need to be written manually by the developer and consequently cost time
  • They are based on predefined inputs and expected outputs and are not designed to find unknown bugs
  • They only execute a limited set of paths in code
  • New tests need to be created as soon as new code is added

Fuzzing is an alternative testing technique originated in the 1980s. The basic idea behind fuzzing is simple: provide random input to the program and report if it crashes. If the software does not crash, repeat with new random input. The problem with the random input method is that it can take a very long time to find relevant inputs, making this technique suitable to only the most simple and shallow bugs. 

In 2016, american fuzzy lop (AFL) improved fuzzing by considering the coverage, i.e. the share of traversed code paths in the generation of new inputs. AFL and other coverage-based fuzzers could discover far more paths of a program than “dumb” fuzzers.

The next major improvement in the world of fuzzing came in the form of Sanitizers that detect more types of errors than just crashes. The AddressSanitizer, for example, monitors memory access akin to valgrind (but a lot faster), while the ThreadSanitizer watches for race conditions between multiple threads. Using Sanitizers for fuzzing was made even more practical with the advent of libFuzzer, due to smart handling of the large virtual memory requirements of the AddressSanitizer.

In short, the combination of coverage information with sanitizers is what we call modern fuzzing. 

Our testing suite simplifies the setup and enables any company to benefit from these modern, sophisticated fuzzing technologies.

Get a live demo of how feedback-based fuzzing works

Request a Demo