How open source C++ code can introduce security risks

Open source libraries and frameworks are a great way to jump-start development projects. Open source empowers developers to do some great things without reinventing the wheel and developing solutions for problems that have already been solved.

However, adding any code to a project carries an inherent risk of introducing potential vulnerabilities that may have made their way into it through error or malice.

This article explores how open source code introduces vulnerabilities into the software supply chain. It also highlights how you can identify vulnerabilities in C++ open source security using automated vulnerability scanners.

How open source code introduces security risks

The open source software ecosystem is deeply interconnected. When you install one open source component in your code, it comes with dependencies. It’s difficult to continuously be aware of the security issues that each dependency might contain, and you can’t always rely on package maintainers to patch these vulnerabilities in time. This means there may be unpatched vulnerabilities in the open source packages that exist in your codebase.

Data from recent research by Snyk and the Linux Foundation shows that the time it takes to fix vulnerabilities in open source projects has steadily increased from 49 days in 2018 to 110 days in 2021. Fixing vulnerabilities in open source projects takes almost 20% longer (18.75%) than in proprietary projects. Because of these complexities, open source applications with known vulnerabilities are a desirable target for hackers.

Buffer overflow vulnerabilities are pervasive in low-level programming languages, such as C or C++, because it is up to developers to allocate memory. C and C++ do not safeguard the application against clients accessing or writing data beyond the given bounds of a buffer, making C++ open source projects vulnerable. For applications without properly managed memory, attackers can take advantage of this vulnerability and insert executable code into the program.

For instance, consider the Glibc bug found in the libresolv library in the GNU C Library. The bug exposed Glibc to buffer overflow attacks when the getaddrinfo library function was used.

An attacker can exploit this vulnerability by tricking a client into looking up a malicious domain. They can then return a payload that triggers the bug. If the client has root privileges, this can compromise the system and lead to a man-in-the-middle attack. Glibc is used in millions of systems that use the Linux Kernel, so any system running the Glibc version containing the vulnerability may be affected.

What is a software supply chain?

The term “supply chain” is traditionally used in the manufacturing industry. For instance, a car manufacturer might use some parts produced in-house and purchase other parts from other companies. This means that before a car reaches its owner, many people using different tools will have worked on it.

In software, the supply chain works quite the same. The software supply chain refers to anything that goes into or touches your code, from development to deployment. This includes code and binaries, the developers who worked on the project, and the repositories where it is deployed. It also encompasses building tools, packaging scripts, and application infrastructure. Supply chain security is paramount.

Because the software supply chain consists of many elements, it can become quite complex. Hackers like to take advantage of this complexity.

Software supply chain vulnerabilities

In a software supply chain attack, malicious actors use the upstream components connected to the target of their attack to gain access. They can also target the services that distribute or run the software. Here, these upstream components are not necessarily the target of the attack — they are only a means for access.

The three main targets in a supply chain are dependencies, pipelines, and pipeline dependencies.

Dependencies

Attackers target open source dependencies that developers pull in when creating applications. If an attacker inserts malware into a typical open source package by exploiting a known vulnerability, software applications that install it as a dependency become exposed. Because software applications may have more than one dependency that contains other dependencies, tracking possible vulnerabilities is difficult. This makes the dependencies an easy target.

Pipelines

In a pipeline attack, malicious users target the continuous integration and continuous deployment (CI/CD) pipeline, as it provides a large attack surface. It can access default configurations, security credentials, databases, and proprietary code. Therefore, when attackers insert malicious code in a CI/CD pipeline and compromise it, they can create a backdoor into the applications that use it.

Pipeline dependencies

Attackers can also target pipeline dependencies to gain access to a build environment. For instance, the malicious actors in the Codecov breach used the credentials from a docker image to update a bash script uploader. They updated the script to send themselves the environment variables of Codecov’s users.

Identifying vulnerabilities in open source dependencies

Even though open source code has the potential to come with problems of its own, it still enables developers to do incredible things and build off of the work of others. But developers must be able to identify vulnerabilities and vet the quality of the open source code used in their projects. However, it’s not feasible for most organizations to expend the resources required to perform manual code reviews and audit open source code before using it.

It would be challenging to catch vulnerabilities such as buffer overflows, null pointers, integer overflows, and underflows, among others, in every C/C++ dependency in the supply chain. For instance, a null pointer vulnerability in a piece of open source C/C++ code used in our software supply chain, can be attacked by hackers and lead to a crash. It won’t matter if the application code has no vulnerabilities, as the vulnerabilities in the open source code make it insecure.

The two primary methods of identifying vulnerabilities in open source dependencies are: creating a secure software supply chain where every step is a trusted contributor, and using automated vulnerability scanners — such as Snyk for C/C++.

Creating a secure software supply chain

Keeping track of each contributor in the supply chain and ensuring that they are trustworthy is a good solution in theory, but extremely difficult to implement. The software supply chain includes many developers responsible for multiple libraries and components used in an application.

Automated vulnerability scanners such as Snyk for C/C++

A more practical solution is to analyze open source code for security vulnerabilities. However, manually performing scans can be time-consuming and error-prone. The best practice is to scan open source C++ code with an automated vulnerability scanner, like Snyk.

With Snyk Open Source, developers gain visibility into the open source C++ code they are using. The Snyk CLI converts the files into digital signatures — or hashes — which are then correlated with Snyk’s databases to form a list of matching open source components. Developers can find vulnerabilities by referencing this list against the Snyk vulnerability database.

Unlike other vulnerability scanners that scan individual files, Snyk considers the context of the files. Using auxiliary files, such as readme files and install scripts, Snyk minimizes the number of false-positive vulnerability reports. This reduces white noise and helps developers focus on where fixes are needed.

Once a vulnerability is identified, Snyk notifies the developers within the IDE or CLI, and automatically identifies the minimal upgrade required to fix a vulnerability without breaking other code.

Conclusion

The popularity of open source software is growing. Because of this, more applications contain more third-party libraries and components written and maintained by unknown people. Because these libraries can be found in public repositories, attackers can exploit the less secure ones for access.

To avoid vulnerabilities when working with open source code in C++ projects, use an automated vulnerability scanner such as Snyk Open Source. It allows you to scan open source C++ projects in your application for vulnerabilities, identify malicious libraries, and protect your software from being compromised.

Check out the Snyk for C/C++ documentation to learn how to scan your C/C++ projects.