Menu

CVE Hunting with Fuzzing: Testing Open-Source Components

published 2020-04-28, written by Christian Hartlage

Executive Summary

Software developers extend their existing frameworks and often write new source code from scratch. They cannot risk shipping vulnerable software to their customers. The software company SodgeIT GmbH from Balingen, Germany, has high-security demands and thus invests a high amount of time in security testing. sodgeIT recognized the advantages of the testing platform CI Fuzz making security testing more efficient and effective and wanted to convince themselves of the results in practice in a pilot project. The results can be summarized with their testimonial:

“With CI Fuzz we found a software solution we almost started to develop ourselves! Nice work Code Intelligence.” - Götz Martinek (Managing Director, sodgeIT)

Challenge

To define the scope for a pilot, the company decided to test the open-source barcode generator ZINT.

About ZINT

ZINT is a barcode encoding library supporting over 50 symbologies including Code 128, Data Matrix, USPS OneCode, EAN-128, UPC/EAN, ITF, QR Code, Code 16k, PDF417, MicroPDF417, LOGMARS, Maxicode, GS1 DataBar, Aztec, Composite Symbols and more. (Source: Github)

SodgeIT is highly concerned about the security and reliability of this project since one of their customers may use it in an upcoming product. In order to test the library efficiently and automatically, sodgeIT thought about implementing feedback-based fuzzing as a dynamic testing method for ZINT (the advantages of feedback-based fuzzing have been explained in this Blogpost). 

Two main challenges of implementing feedback-based fuzzing involve the high amount of manual effort and the required fuzzing expertise. Often developers need days or even weeks to get fuzzing tools like AFL or libFuzzer up and running. Despite the immense workload required, sodgeIT wanted to benefit from fuzzing without diverting resources from other high-profile projects. This is when Code Intelligence came in.

Solution

In the course of one day, we got this unknown project going. In order to use fuzzing, so-called fuzz targets have to be written. Fuzz targets are small programs that test predefined API functions, similar to unit tests. However, the inputs are not provided by the developer but produced with a fuzz generator based on the feedback from instrumentation. 

For this project, we were able to test all the different barcode generation algorithms with a single fuzz target. Derived from existing unit tests, a good entry point (ZBarcode_Encode) was suggested with our software so that we were able to quickly set up fuzzing in the user interface with our "Fuzz this function" feature. Thereby, the manual effort was reduced to a minimum. After defining this fuzz target, the entire application will be fuzzed on every git commit with our testing platform. 

Animation 1: "Fuzz this Function" automatically creates a fuzz target and resolves all compile-time and link-time dependencies.

Outcome

Within the very first minutes of testing, CI Fuzz was able to identify a critical vulnerability. Our testing platform automatically detected a stack buffer overwrite of up to 14 bytes. When entering malicious inputs, provided in the bug report, it would in the best-base scenario cause a crash leading to a denial of service (DoS). If exploited properly, this vulnerability could lead to more severe damage, for example, a remote code execution. The finding was later accepted as a CVE (Common Vulnerabilities and Exposures) with the base score 7,5 (“high severity”). You can find it under the ID CVE-2020-9385

Animation 2: Debugging a stack buffer overflow with CI Fuzz

After this first run, Nico Gunkel from sodgeIT used CI Fuzz to further investigate the library and reported six additional bugs in the following week after. You can find the documentation about all found bugs on Sourceforge.

Open-source software often gets developed by volunteers on a very small budget. It is no shame that this leads to quality and security issues from time to time. Therefore, we believe that testing open-source software really adds value to all participating parties.

By testing open-source projects in with Code Intelligence, companies can...

  • assure that the open-source modules, which they are using regularly in their products, are safe and sound.
  • contribute quality improvements to the open-source community.
  • evaluate the benefits of CI Fuzz without sharing their own intellectual property.

As a result of this project, we were able to convince sodgeIT of the added value of our solution and made a valuable contribution to improving ZINT.

“Thank you for finding the time to test Zint so thoroughly!” - Developer of ZINT

"We have always been looking for a better solution than our scripts to automate fuzzing in our CI. CI Fuzz is a good solution with a very nice integration in VS Code." - Götz Martinek (Managing Director, sodgeIT)

What the Future Holds

In the future, sodgeIT and Code Intelligence want to further expand their partnership. sodgeIT, as a software development company, is convinced that early testing in the development process prevents follow-up costs. Therefore, Code Intelligence can support sodgeIT and its customers with a state-of-the-art testing solution. 

In addition, Code Intelligence is eager to test further open-source projects in order to ensure their security and quality. Feel free to contact us, if you have an open-source project, which should be fuzzed soon!

 

Did you already try to set up fuzzing for your open source project? Drop a comment!