Open source software is a software with source code that anyone can inspect, modify, and enhance. They have multiple advantages like high quality software, no vendor lock-in, lower software cost and most important ABUNDANT support.
But with more flexibility comes more responsibility and that’s why we need something that can assure us that our software is free from programmatic errors, and have no serious security threats.
So to make our open source softwares more secure and stable, Google has introduced OSS fuzz in 2016 with three primary goals:
1. Finding security vulnerabilities, stability issues, and functional bugs at scale.
2. Making the platform easy to use for open-source developers and encouraging them to take security testing into their own hands.
3. Getting the bugs fixed quickly (OSS-Fuzz has a 90% fix-rate!)
OSS-Fuzz does Fuzz testing which is a well-known technique for uncovering programming errors in software. Many of these detectable errors, like buffer overflow, can have serious security implications, but with OSS-Fuzz we aims to make common open source softwares more secure and stable by combining modern fuzzing techniques with scalable, distributed execution.
Currently, OSS-Fuzz supports C/C++, Rust, Go, Python and Java/JVM code. Other languages supported by LLVM may work too. OSS-Fuzz supports fuzzing x86_64 and i386 builds.
Overview
To know more, read this detailed documentation to learn how to use OSS-Fuzz
Cluster API
Cluster API is a Kubernetes sub-project focused on providing declarative APIs and tooling to simplify provisioning, upgrading, and operating multiple Kubernetes clusters.
Started by the Kubernetes Special Interest Group (SIG) Cluster Lifecycle, the Cluster API project uses Kubernetes-style APIs and patterns to automate cluster lifecycle management for platform operators. The supporting infrastructure, like virtual machines, networks, load balancers, and VPCs, as well as the Kubernetes cluster configuration are all defined in the same way that application developers operate deploying and managing their workloads. This enables consistent and repeatable cluster deployments across a wide variety of infrastructure environments.
To know more, visit this github page.
Setup Cluster API on OSS-Fuzz
As Cluster API is a widely used open source project, so community decided to setup Cluster API on OSS-Fuzz.
This is the following PR to track this setup process in CAPI project.
Once we initiate the setup of any open source project on Oss-Fuzz
, we also raised one corresponding PR in google/oss-fuzz
repository.
This is the corresponding google/oss-fuzz PR for CAPI setup `
Once all these steps are executed, then we are done with initial integrations. In above steps we have mentioned some email IDs in the PR, and these people will get the automatic email notification if any bug is found in the mentioned project.
Once we received a mail, next action item is to reproduce this issue locally and resolve it in the project.
In next section I will list down few steps to reproduce the issue in your local system.
Steps to reproduce it locally
Files and variables required to run it in local
/path/to/downloaded/minimized/testcase:
this is the path for a file which every issue has. It's called a reproducer file (also know as a "testcase" file). This you can get from mail with a name as Reproducer TestcaseTake checkout of OSS-Fuzz in local:
git clone https://github.com/google/oss-fuzz
cd oss-fuzzPull the latest Docker images
Docker images get regularly updated with a newer version of build tools, build configurations, scripts, and other changes. In some cases, a particular issue can be reproduced only with a fresh image being used. Pull the latest images by running the following command:
python infra/helper.py pull_images
Build the image and the fuzzers. Run following command
python infra/helper.py build_image kubernetes-cluster-api
python infra/helper.py build_fuzzers kubernetes-cluster-api
python infra/helper.py reproduce kubernetes-cluster-api fuzz_conversion_of_all_types /path/to/downloaded/minimized/testcase
After running all the above commands you will see something like this in your local:
In this way, you can reproduce the bug locally.
To know more on reproducing the bug locally follow this official doc.