As we enter the truly sweltering months of summer, our hardworking research team has taken comfort in blasting their AC up to full force to put together a list of June’s top 5 new open source security vulnerabilities.
Whether it’s snowing or sunny, the WhiteSource database continues to automatically aggregate known open source security vulnerabilities from multiple resources like the National Vulnerability Database (NVD), as well as other well-respected public, peer-reviewed security advisories, and issue trackers.
June was a rough month for the open source security community, who worked hard to discover and remediate vulnerabilities found in some of the most popular open source libraries and components out there. This list of newly published open source security vulnerabilities a wide variety of open source projects, simple and complex, covering diverse aspects of the software industry.
So, here they are folks, hold on to your seats and read all about the top 5 new open source vulnerabilities in June.
Vulnerability Score: Critical — 9.8 (CVSS v3.0)
Affected versions: Android-7.0 Android-7.1.1 Android-7.1.2 Android-8.0 Android-8.1 Android-9.
Coming in with a high CVSS v2.0 score 10, is this Android vulnerability. The issue was found in HAliasAnalyzer.Query of hydrogen-alias-analysis.h, and might cause memory corruption due to type confusion.
According to the NVD entry, this could allow a remote code execution attack from a malicious proxy configuration. It’s especially dangerous because the exploit can be performed with no additional execution privileges or user interaction needed.
Rest assured, Android’s security team fixed this issue swiftly. You can read more about the issue and its fix on Android’s security bulletin for June.
Vulnerability Score: High — 7.6
Affected versions: before 2.0.0
A vulnerability discovered in Querystringify allows malicious users to override built-in properties of the resulting query string object if a malicious string is inserted in the query string.
Quirystringify is a “somewhat JSON compatible interface for query string parsing”, that pretty much everyone seems to be using, based on the nearly 5 million weekly downloads from their npm page. Maybe it’s so popular because, as the project’s documentation states, it’s small, simple, but powerful.”
This vulnerability hasn’t been listed in the NVD yet. You may have noticed that rather than a CVE prefix, the ID number starts with a WS. The NVD is a highly popular and respected database for security vulnerabilities, and while it includes many open source issues, it doesn’t cover all of them and can at times take longer to post new listings that are available elsewhere. Since open source security vulnerabilities that are discovered and remediated by the decentralized open source community, they are published on a variety of community platforms, and are often added late to the NVD. This is what happened with the Quirystringify issue which was added to the WhiteSource database before being indexed in the CVE or added to the NVD. This is another reminder that tracking vulnerabilities in open source components is a complex issue and best covered by a dedicated tracking tool.
Happily, a fix has already been published. You can read more about it here.
Vulnerability Score: High — 7.4 (CVSS v3.0)
Affected versions: 2.7.6 and later through 3.0.2
Ruby users look alive: a directory traversal issue was discovered in vulnerable versions of RubyGems, a popular hosting service for the large and enthusiastic Ruby community.
According to RubyGem’s security advisory, “Before making new directories or touching files (which now include path-checking code for symlinks), it would delete the target destination. If that destination was hidden behind a symlink, a malicious gem could delete arbitrary files on the user’s machine.” The advisory goes on to warn developers that, “Given how frequently gem is run as sudo, and how predictable paths are on modern systems (/tmp, /usr, etc.), this could likely lead to data loss or an unusable system.”
This is just one example of how bug bounty contributors have become increasingly important to the open source community’s vast and sometimes confusing security ecosystem. This is only one of several issues RubyGems issues published on HackerOne. You can check out the full list of issues and their fixes on RubyGem’s official blog.
Vulnerability Score: High — 8.8 (CVSS v3.0)
Affected versions: 10.x before 10.9 and versions 11.x before 11.4
Affected PostgreSQL versions are vulnerable to a stack-based buffer overflow attack. According to PostgreSQL’s trusty release notes, “An authenticated user could create a stack-based buffer overflow by changing their own password to a purpose-crafted value.” The PostgreSQL team warns that on top of enabling a hacker to crash the PostgreSQL server, they could further exploit it to execute arbitrary code as the PostgreSQL operating system account.
If that’s not enough incentive to get users to check which version of PostgreSQL they are using and upgrade ASAP if they find they are using a vulnerable version. The release post adds that, “Additionally, a rogue server could send a specifically crafted message during the SCRAM authentication process and cause a libpq-enabled client to either crash or execute arbitrary code as the client's operating system account.”
This isn’t the first time that we’ve featured PostgreSQL in our Top 5 new monthly open source vulnerabilities list. PostgreSQL is an extremely popular object-relational database system. Fondly referred to as Postgres by its many admirers, the project’s documentation boasts a strong reputation for reliability, feature robustness, and performance thanks to being backed by over 30 years of active development.
Postgres continues to gain popularity, breathing down the necks of some of the database giants, with some rankings placing it as the number four top database in use today and the second most used open source database (behind MySQL). This impressive growth also means that it is very likely that you are either directly or indirectly using this open source DBMS, and should update to a secure version as fast as humanly possible.
You can learn more about this and other PostgreSQL issues on their security page.
#5 Cesanta Mongoose Embedded Web Server Library
Vulnerability Score: Critical — 9.8 (CVSS v3.0)
Affected versions: 6.13 and earlier
This is one of several security issues discovered in the versions 6.13 and earlier of the Cesanta Mongoose Embedded Web Server Library, and one of four critical issues found specifically in the mg_http_get_proto_data function in mongoose.c.
In this case, an invalid read of 8 bytes due to a use-after-free vulnerability during a "NULL test" in the allows a denial of service (application crash) or remote code execution.
We should note that Mongoose has had a rough go of late with a collection of other vulnerabilities popping up. CVE-2018-20354, CVE-2018-20355, CVE-2018-20356, and CVE-2018-20352 are the three additional high severity and critical use-after-free vulnerabilities discovered in Cesanta Mongoose’s mg_http_get_proto_data function in mongoose.c.
That’s not all. CVE-2019-12951 was another critical vulnerability (9.8 CVSS v3.0) was discovered in versions prior to 6.15. Here, the parse_mqtt() function in mg_mqtt.c has a critical heap-based buffer overflow. You can read more about the issue and its fix here.
Mongoose is a networking library written in C, described in the documentation as “a swiss army knife for embedded network programming” that “implements event-driven non-blocking APIs for TCP, UDP, HTTP, WebSocket, CoAP, MQTT for client and server mode.”
Apparently it’s a pretty amazing army knife since according to Cesanta’s website, Mongoose is GitHub's most popular embedded web server. So popular that since it first came to market in 2004, it’s been used by a sky-high number of products. We mean this quite literally — it even runs on the International Space Station. So whether you are running projects here or in outer space, it’s best you make sure that you check to see if you’re using an outdated version of Cesanta Mongoose.
Don’t Get Burned by Known Open Source Vulnerabilities
There you have it folks. The list of top 5 open source vulnerabilities in June includes a variety of projects that are the building blocks of the software that we create and maintain. Aside from the fact that these open source projects are most probably used in our software, they are also very likely to be connected to the products that we use.
While the open source community is hard at work ensuring that the open source libraries that power our innovation are vulnerability free, it’s up to us to release software products using the most updated versions of open source components in order to ensure that they don’t include any known vulnerabilities. And it doesn’t stop there — vulnerabilities can be discovered in versions of open source components that have been out there for a while. Just because they were considered to be vulnerability-free when you deployed your product, it doesn’t mean that they still are.
If you want to make sure that the open source projects in your software products are vulnerability-free, you need to use a tool that continuously tracks your open source usage, and alerts you in real-time when an issue is discovered, providing all the necessary information and automating remediation.
The best way to stay on top of open source security, and one step ahead of the hackers, is to integrate tools that will help you manage your open source usage into your development processes. That way you can continue using open source projects to deliver great products, without letting security concerns slow you down.
Want to catch up on open source vulnerabilities which could have slipped by in 2019? Check out our top open source vulnerabilities page to see if there are any that you might have missed last year.
See you next month when we pull together the top list for July.