It’s time for June’s open source vulnerabilities snapshot, your monthly overview of everything new in the fast-paced world of open source security vulnerabilities.
In hopes of giving you this month-at-a-glance summary of current trends in the open source ecosystem, our trusted research team reviewed the new open source security vulnerabilities published in May and collected by the WhiteSource database. WhiteSource’s comprehensive open source vulnerabilities database continuously aggregates information from a variety of sources, ranging from the National Vulnerability Database (NVD) to peer-reviewed security advisories and issue trackers in the open-source and security communities.
Open Source Vulnerabilities in June: What’s New?
Five hundred new open source vulnerabilities were published in May. Come rain or shine or pandemic, the open source community continues to invest significant efforts in finding and fixing issues in open source projects. Happily, almost 50% of the open source security vulnerabilities published in May already have a fix already available, and these numbers are sure to rise in the upcoming weeks, making it that much easier for all of us to manage the security of the open source components that we’re using.
Open Source Vulnerabilities Severity Breakdown in May
We looked at how May’s vulnerabilities’ severity scores were distributed since this is usually a deciding factor for development and security teams when determining which new alerts to address first.
Looking at the data, it’s clear that severity scores aren’t enough when attempting to prioritize vulnerabilities when over 50% of them are rated high or critical.
There are several reasons why the distribution of scores is so uneven. Understandably, the security research community invests resources in discovering and disclosing high-severity issues, resulting in fewer low and medium vulnerabilities published. While severity score should be one consideration when prioritizing security alerts for new vulnerabilities, it’s important to remember that it can’t be the only consideration. The CVSS score is meant to measure severity, not risk. The risk and the impact of a vulnerability on a software product depend on a number of additional aspects that should be considered.
Most Common Open Source CWEs in May
CWE-79 (XSS) has been the most common vulnerability type over the past two years and has been one of the three most common CWEs for several years prior. The increasing use of automated tools for the detection of XSS issues is one reason behind the high number of new XSS issues discovered in open source components month after month. Another explanation is the attention the security community has been directing towards web application security, where CWE-79 can be found.
As XSS vulnerabilities continuously increase, it’s important to remember that this issue can be avoided at the coding stage, by simply following basic coding standards and best practices. While early detection of issues is extremely important, secure coding is also a critical step in shifting security left.
May Open Source Vulnerabilities per Programming Language
We also found that the distribution of new open source vulnerabilities per programming language in May is fairly consistent with April’s results.
In May, 25% of the open source vulnerabilities published were in libraries written in C. Considering the amount of code written in C and the size of the communities behind applications like the Linux kernel, this should come as no surprise. Linus’s Law states that "given enough eyeballs, all bugs are shallow." When we look at a language as prominent and popular as C, a high number of published vulnerabilities is to be expected.
Spotlight on WS-2020-0091 in http-proxy
Severity: High, 7.5
Vulnerable versions: http-proxy prior to 1.18.1
According to the NPM security advisory, vulnerable versions of http-proxy are open to a Denial of Service attack. The advisory warns that in cases where the proxy server sets headers in the proxy request using a specific function, an HTTP request with a long body triggers an unhandled exception that crashes the proxy server.
One example that the advisory provides is “for a proxy server running on http://localhost:3000, the following curl request triggers the unhandled exception:
curl -XPOST http://localhost:3000 -d "$(python -c 'print("x"*1025)')" ”
Considering the library has over 8.5 million weekly downloads from npm and over 1,900 dependents, including some extremely popular projects, it’s extremely important to make sure that you are using an updated version.
The good folks at http-proxy have fixed the issue, and remediation requires upgrading to version 1.18.1. You can learn more about the fix in the pull request on GitHub.
You might be wondering why this vulnerability’s ID begins with a WS rather than the more common CVE prefix. This is because the issue hasn’t been listed in the CVE yet. While many rely on the CVE and NVD as the primary resources for information about security vulnerabilities, sometimes it takes a while for open source issues to be added there. Due to the decentralized nature of the open source community, open source vulnerabilities are often published in an advisory, forum, or issue tracker before being indexed in the CVE. These issues are added to the WhiteSource database with a WS prefix.
This is another reminder that relying exclusively on the CVE or NVD is not enough to fully cover all of the open source vulnerabilities in your code.
Don’t Let the Open Source Security Vulnerabilities Keep You Down
The open source and security research communities continue to work hard to uncover and publish open source security vulnerabilities in the software projects that we are all using. The next step is up to us, the users of open source components.
Managing open source security is not for the faint of heart, but it’s a challenge we can’t ignore. We need to address the open source vulnerabilities in our code as soon as possible, without slowing down development or delaying release.
If we want to check all of our open source security boxes, DevOps, development, and security teams must work together, implementing the right processes and tools as early as possible in the development lifecycle. Making the right decisions from the earliest stages of coding and continuously tracking our open source components and vulnerabilities throughout the DevOps pipeline will help us get to our release dates quickly and securely.
Want to learn more about May’s top open source security vulnerabilities? Check out WhiteSource’s Vulnerability Database!