Top 5 Open Source Vulnerabilities for April 2019
Table of Contents
April showers may bring May flowers, but they also bring with them some real doozies when it comes to open source vulnerabilities.
Spring is in the air, but our hard-working knowledge team at Mend is still at it, seeking out the open source vulnerabilities that the public needs to know are out there.
The Mend database continuously collects known open source security vulnerabilities from a number of well-respected community resources like the National Vulnerability Database (NVD), and other public, peer-reviewed security advisories, and issue trackers.
This month’s list brings us some serious vulnerabilities in projects that we know you’re probably using. So let’s not waste any time and get down to it. Happy reading and don’t forget to update your software when you’re done.
CGI Servlet in Apache Tomcat
CVSS V2 9.3
Affected Versions: 9.0.0.M1 to 9.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93
Coming at the top-rated CVSS rating of the month (you can breathe east team, no 10s this time around) is a particularly nasty vulnerability in one of our favorite projects.
We have learned that when running on Windows with enableCmdLineArguments enabled, the Common Gateway Interface (CGI) Servlet in Apache Tomcat (versions 9.0.0.M1 to 9.0.17, 8.5.0 to 8.5.39 and 7.0.0 to 7.0.93) is vulnerable to a Remote Code Execution due to a bug in the way the JRE passes command line arguments to Windows.
In order to make this attack work, the target needs to be running on Windows in a non-default configuration while in conjunction with batch files. When these conditions match up, it can lead to an input validation vulnerability (CWE-20).
In response to this risk, it is advisable to make sure that you are running Tomcat according to the default settings, which will have the CGI option enableCmdLineArguments disabled moving forward. The recommended fix here is to upgrade to one of the safer versions in either 7.9.94, 8.5.40, 9.0.19.
Seclists.org has a pretty comprehensive write up of this vulnerability, including how to replicate it. For those of you who are interested in reading a detailed explanation of the JRE behavior, check out Markus Wulftange’s blog. This archived MSDN blog post is also listed as recommended reading.
Handlebars
WS-2019-0064
CVSS: 8
Affected Versions: prior to 4.0.14
Open source developers always have a great sense of humor, especially when it comes to naming their projects. Handlebars, an extension to the Mustache templating language, is no exception.
Handlebars.js is described as a logicless templating language that keeps the view and the code separated from one another for an easier experience. With close to 6.5 million downloads a week according to NPM, it would seem like a lot of folks have become fans of this project.
Unfortunately, versions of handlebars prior to 4.0.14 have found themselves in a bit of twist and are vulnerable to Prototype Pollution. According to the reports, templates may alter an Objects’ prototype, thus allowing an attacker to execute arbitrary code on the server.
You may have noticed that this vulnerability has a WS prefix before its ID number. This is because it hasn’t been added to the NVD yet. While the NVD is a popular database for security vulnerabilities and includes many open source issues, some open source vulnerabilities that are discovered and remediated by the open source community are published on other various public platforms. This is what happened with the handlebars vulnerability, and they were added to the Mend database before they were indexed in the CVE or added to the NVD.
You can find out more about the fix on handlebars’ GitHub page.
Js-YAML
WS-2019-0063
CVSS: 8
Affected Versions: prior to 3.13.1
It’s been a rough couple of months for this popular JavaScript component. Last month it was found to have two vulnerabilities (WS-2019-0032 and WS-2019-0034) that could lead to a Denial of Service attack. Now this month, Js-YAML prior to 3.13.1 was reported to be vulnerable to a Code Injection attack.
According to reports, the load() function may execute arbitrary code injected through a malicious YAML file. Definitely not good news for users of this popular project.
JS-YAML is a YAML 1.2 parser and writer for JavaScript. It’s an implementation of YAML, a human-friendly data serialization standard for all programming languages. According to JS-YAML’s GitHub and npm pages, the project started as PyYAML port, and was completely rewritten to become very fast, and support 1.2 spec.
The 14,589,603 weekly downloads and 7,322 dependents featured on JS-YAML’s NPM page say that users are generally pretty happy with it. Hopefully, this run of vulnerabilities won’t have a negative impact on this useful project.
Some programming languages are more likely than others to have many of their vulnerability postings in spots other than the NVD. JavaScript, in particular, has been found to have over 31% of their vulnerabilities not listed on the NVD but posted on other security advisories like NPM’s advisory. It is worth remembering that the open source community is diffuse, so solely tracking the NVD is not sufficient for staying secure.
The fix here is to upgrade to version 3.13.1.
Linux Kernel
CVSS: 7.2
Affected Versions: before versions 4.20.8 and 4.19.21
As one of the most used projects in the open source space, there are always interesting vulnerabilities in the Linux Kernel.
This month we have discovered that in the Linux Kernel before versions 4.20.8 and 4.19.21, a use-after-free error in the “sctp_sendmsg()” function (net/sctp/socket.c) when handling SCTP_SENDALL flag can be exploited to corrupt memory.
Info on how to patch can be found here.
Kubernetes
CVSS: 4
Affected Versions: v1.11.8, v1.12.6, and v1.13.4
Just in case you’ve been under a rock for the past year or so, Google’s container deployment orchestration tool Kubernetes has been the talk of the town, helping organizations manage their container deployments at scale.
However, this much-beloved project has had its fair share of issues in recent months, including a Critical vulnerability in December of 2018 that allowed attackers to take over whole compute nodes on unpatched systems. By contrast, this latest vulnerability in Kubernetes is fairly minor, but the near ubiquity of Kubernetes throughout the industry makes it an important one for us to cover.
In all Kubernetes versions prior to v1.11.8, v1.12.6, and v1.13.4, users that are authorized to make patch requests to the Kubernetes API Server can send a specially crafted patch of type “json-patch” (e.g. `kubectl patch –type json` or `”Content-Type: application/json-patch+json”`) that consumes excessive resources while processing, causing a Denial of Service on the API Server.
Google, who maintains Kubernetes, suggests in their write up that it is a good idea to remove patch permissions from all untrusted users even before you start upgrading to the safe version.
While the results of an attacker exploiting this vulnerability could have a negative impact on the target, the fact that they already need to be an authorized user with the ability to make patch requests does serve as a limiting factor, justifying this lower CVSS rating. That said, given the growing concerns about insider threats, credential compromise, and of course a good old fashioned mistake, we strongly recommend updating to the safe version.
You can access more info about the secured version here on GitHub this general Kubernetes security best practices post.
Spring Into Action With Proactive Vulnerability Management
With winter having hopefully wound down to a close, it is tempting to turn our attention outwards. BBQs, beaches, and other joys of being outside are calling us, but unfortunately, open source vulnerabilities don’t know seasons. Rain or shine, they are with us all year.
Remember that while you can always turn to us for the month’s hottest open source vulnerabilities, the first step to staying secure is knowing which open source components you and your team are using in your products so that you can know which alerts to keep your eyes peeled for. As we saw in our two WS-linked vulnerabilities, not all issues will initially show up in the NVD, and may slip by you if you’re not fully on top of your game.
Want to catch up on open source vulnerabilities which could have slipped by in 2018? Check out our blog to see if there are any that you might have missed last year.
