Now that the sparkle and pop of the Fourth of July’s fireworks has subsided, it’s time for July’s open source vulnerabilities snapshot, your monthly overview of everything new in the always-evolving world of open source security.
Once again, we’re here to give you an overview of what’s new and what’s stayed the same in the world of open source security vulnerabilities. Mend’s hard-working research team dug into the data from our database, to give you the low-down on the open source security vulnerabilities published in June, and see what’s changed since our previous overview. The extensive Mend database for open source vulnerabilities continuously collects information from several resources, including the well-known National Vulnerability Database (NVD) and multiple peer-reviewed security advisories, forums, and issue trackers in the open-source and security communities.
Over 800 new open source vulnerabilities were published in June. As open source usage becomes a common practice in software development organizations big and small and the open source community grows, the community is continuously increasing efforts to detect and remediate security issues in open source components.
The result is this high number of new open source security vulnerabilities published in June, nearly 50% of them with a fix already available. Considering the resources invested in open source security, the number of fixes will most probably rise in the upcoming weeks.
The distribution of severity scores, based on CVSS v3.x, continues to fall heavily on the high and critical side of the scale, with 47% of all open source vulnerabilities published in June rated high or critical.
This presents security and development teams tasked with addressing a steady flow of security alerts with quite a challenge, since the CVSS score is often a major consideration in prioritizing what gets remediated first. If nearly 50% of the open source vulnerabilities published in a month are critical or high, how can they decide what requires their most immediate attentio
It’s important to remember that while referring to a vulnerability’s severity score is important, there are other parameters that can help evaluate how much of a threat a vulnerability presents and prioritize accordingly. CVSS 3.x attempts to address the characteristics and impact of a security vulnerability, but doesn’t indicate risk. Risk is the impact times the likelihood, and the severity scoring system only indicates the impact.
The most common CWEs are consistent over the past few months, and even the past few years, are CWE-79 (Cross-site scripting (XSS)), CWE-200 (Information Exposure), CWE-125 (Out-of-bounds Read), and CWE-20 (Improper Input Validation).
Some of the reasons for the high number of XSS issues are the increased use of automated tools for their detection and the security community’s focus on web application security, where XSS issues are found. The prevalence of CWE-200 and CWE-20 is partly because they are both very general. Unlike XSS, CWE-200 covers the many consequences of a very wide scenario. The same is true for CWE-20, where input validation may refer to any number of actions that must be implemented for security. Developers often forget to address all of them, resulting in an Improper Input Validation issue. In addition, CWE-20 can mean anything from XSS to SQL injection to several other issues.
One concerning point to consider is that most of the common CWEs are the result of simple coding errors that could be avoided by complying with basic coding standards and secure coding best practices.
The distribution of new open source vulnerabilities per programming language in June shifted a bit as compared to the previous month.
One thing that remained stable was the relative amount of vulnerabilities discovered in C libraries. Coming once again in first place, with nearly 25% of the open source vulnerabilities published in June, is C. C can usually be found at the top of this list, since there are more lines of code written in C than any other language, not to mention the prevalence of some C projects, like the Linux kernel, to name just one.
Severity: Critical, 9.8
Vulnerable versions: before 2.1.2
Speaking of vulnerabilities in C, an out-of-bounds read was discovered in TrioParse in FreeRDP, an open source implementation of the Remote Desktop Protocol (RDP). According to GitHub’s Security Advisory, logging might bypass string length checks due to an integer overflow. The issue was discovered by Antonio Morales from GitHub Security Lab (GHSL) and was fixed in version 2.1.2.
The FreeRDP website boasts that the project provides users with the ability to use their software wherever and however they want. Little did they know how important it would become to enable developers to work from home freely, and how dependent we would become on tools that help us work remotely.
Severity: Medium, 6.1
Vulnerable versions: before 1.2.1
Java vulnerabilities came second after C in June, and this is one of them.
It’s good to see that OWASP (The Open Web Application Security Project), the nonprofit foundation that works hard to improve the security of software, is not only providing us with open source tools and resources, but also making sure that they remain secure.
Read more about this issue and its fix on GitHub.
Clearly, there is never a dull moment in the open source security ecosystem. Whether you’re working remotely or planning to spend your summers by the pool, one thing you can count on is that the open source community will continue to find and fix new security vulnerabilities in our favorite open source projects.
In order to keep up, it’s important to embed security into your DevOps pipeline, starting from the earliest stages of development. Keeping track of the open source components in your projects, from design to production, is how to ensure you stay on top of open source security, without breaking a sweat or delaying release schedules.
Want to read more of our monthly open source security vulnerabilities snapshots? Check out our Top Vulnerabilities.