• Fuzzing ZBar barcode scanning library: Fuzzing is a successful technique for finding security bugs and is popular but not always used. The ZBar library was fuzzed despite a limited time budget, finding serious bugs like an out-of-bounds stack buffer write and a memory leak.

  • Assessing fuzzing state: Determine if software is fuzzed by checking the repository for fuzzing mentions and looking at oss-fuzz projects. ZBar was barely fuzzed or not fuzzed at all.
  • Instrumenting the build: Build ZBar with sanitizer and fuzzer instrumentation using Nix. Modify the existing build by setting the compiler to Clang, adding dependencies, and disabling stripping and tests.
  • Identifying the target: The fuzzing target was the function that decodes barcode data from an image. Start with a simple harness and adjust as needed. Enlarge the input image when coverage stalls.
  • Diagnosing crashes: The stack buffer out-of-bounds write bug was independently reported and fixed. The memory leak bug can lead to a denial-of-service attack. The root cause is missing memory cleanup in error paths.

• Lessons learned:

  • Fuzz unsafe code even with limited time.
  • Cut out unnecessary features to limit attack vectors.
  • Add sanitizer instrumentation to builds, especially AddressSanitizer. It can catch critical vulnerabilities and save time on fuzzing.
• Reproducing the research: Save the fuzzing harness and Nix file. Build with nix-build and run the fuzzer. The postInstall phase ensures the harness has llvm-symbolizer for diagnosing.

Overall, fuzzing can be a powerful tool for finding security bugs, and even with limited time and resources, significant issues can be discovered. Configuring and instrumenting builds correctly is crucial for successful fuzzing.