Google has introduced the ClusterFuzzLite project, which enables fuzz testing code to detect potential vulnerabilities early in the continuous integration process. Currently, ClusterFuzz can be used to automate fuzz testing for pull requests in GitHub Actions, Google Cloud Build, and Prow, with support for other CI systems anticipated in the future. The project is based on the ClusterFuzz platform, designed to coordinate the work of fuzz testing clusters, and is distributed under the Apache 2.0 license.
It is noted that after the introduction of the OSS-Fuzz service by Google in 2016, more than 500 important open-source projects were adopted into the continuous fuzz testing program. Based on the checks conducted, over 6,500 confirmed vulnerabilities were eliminated, and more than 21,000 bugs were fixed. ClusterFuzzLite continues to develop fuzz testing mechanisms with the capability of earlier detection of issues during the review stage of proposed changes. It has already been implemented in the change review processes of the systemd and curl projects, allowing for the detection of errors missed by static analyzers and linters used during the initial code review.
ClusterFuzzLite supports the testing of projects in C, C++, Java (and other JVM-based languages), Go, Python, Rust, and Swift. Fuzz testing is conducted using the LibFuzzer engine. To detect memory handling errors and anomalies, tools like AddressSanitizer, MemorySanitizer, and UBSan (UndefinedBehaviorSanitizer) can also be invoked.
The main features of ClusterFuzzLite include rapid checks of proposed changes to find errors before code acceptance; uploading reports on the conditions of crashes; the ability to transition to more extensive fuzz testing to identify deeper bugs that did not surface during code change checks; generating coverage reports to assess code coverage during testing; and a modular architecture that allows for the selection of necessary functionality.
As a reminder, fuzz testing involves generating a stream of various random combinations of input data, closely resembling real data (for example, HTML pages with random tag parameters, archives, or images with abnormal headers, etc.), and monitoring for possible failures during their processing. If a sequence causes a crash or does not match the expected response, such behavior likely indicates an error or vulnerability.
Source: opennet.ru
