Top 10 New Open Source Security Vulnerabilities in 2018
Table of Contents
Now that the dust of the New Year’s celebrations has settled, hangovers have receded, and vacation tans have faded, it’s time for one last new year’s list.
At the end of 2017 we started a tradition of rounding up the top 10 open source security vulnerabilities of the year to give you a quick rundown of the most unsettling and common security flaws found in open source components. Since then, we’ve worked hard every month to publish our monthly top 5 open source vulnerabilities blog posts, and now it’s time to give you 2018 ’s top 10 open source security vulnerabilities.
Our research team looked over all of the new open source security vulnerabilities added to Mend’s database in 2018, aggregated from multiple sources including the National Vulnerability Database (NVD), and additional publicly available, peer-reviewed security advisories and issue trackers.
You’ll probably notice that quite a few of the vulnerabilities on the list have a WS prefix on their ID, rather than the more familiar CVE identification. WS vulnerabilities are ones that have not yet been added to the NVD, but have been catalogued in our database. While the NVD is a comprehensive vulnerabilities database, only 86% of open source vulnerabilities are in the CVE database, while the rest are published on other platforms. That’s why Mend’s open source vulnerability database extends beyond NVD vulnerabilities, and continuously aggregates data from additional security sources.
So, without further ado, here is our list of the top 10 open source security vulnerabilities published in 2018.
#1 Linux Kernel netfilter: xt_TCPMSS
Affected versions: Linux kernel before 4.11, and 4.9.x before 4.9.36
Vulnerability score: High — 9.8
The Linux community is a hardworking bunch, constantly combing through their OG project. That’s one of the reasons this year saw so many Linux vulnerabilities popping up — which made choosing just one for this list was quite the task. In the end, we decided to include this netfilter: xt_TCPMSS vulnerability in the list because of its extra high vulnerability score, as well as how popular the vulnerable versions are.
netfilter: xt_TCPMSS sits on the kernel level, and helps to filter network communication by defining the maximum segment size allowed for accepting TCP headers. Think of a dam in a river: this component provides the required controls to ensure that the valley is never flooded.
Malicious users could exploit this flaw to execute a denial of service attack, sending through a flood of communications to knock the system offline. Considering that this component sits on the foundation of the system, the effects could be quite destructive and wide-ranging. That’s why this scary vulnerability scored a CVSS v2 score of 10, and a CVSS v3 score of 9.8.
Happily, the dedicated Linux kernel community swiftly provided a fix. You can read more about it here.
#2 macaddress
WS-2018-0113
Affected versions: All versions prior to 0.2.9
Vulnerability Score: Critical — 10
In May, a security vulnerability was found in Node-macaddress, the open source module that retrieves MAC addresses in Linux, OS X, and Windows, and is now vulnerable to command injection attacks.
The node-macaddress library enables users to find the MAC address per network interface and chooses an appropriate interface when users are interested in a specific MAC address identifying the host system.
This is an extremely popular library, currently averaging 563,699 weekly downloads. That leaves a whole lot of systems vulnerable to command injection attacks.
According to the npm security advisory, users must update to versions 0.2.9 or later.
This node-macaddress vulnerability (WS-2018-0113) is the first example in this list of an open source vulnerability that was added to our database from a source other than the most common and widely known NVD, reminding us that it’s important to cover all bases when it comes to open source security.
You can find more information about this vulnerability here.
#3 Drupal
Affected versions: 7.58, 8.x before 8.3.9, 8.4.x before 8.4.6, and 8.5.x before 8.5.1
Affected versions: multiple subsystems of Drupal 7.x and 8.x
Vulnerability Score: Critical — 9.8
March was not a happy month for Drupal admins, to put it lightly. Most of the security and Drupal community simply called it Drupalgeddon 2.0. Multiple versions of the popular open source content management platform that has always galvanized web developers was found to be vulnerable to malicious attacks, due to an input validation issue in Drupal core.
The Drupal team issued a security announcement informing site admins of a security release scheduled for the following week. Administrators were urged to “reserve time for core updates” because “exploits might be developed within hours or days.”
As many Drupal admins were still attempting to contain the chaos, another security vulnerability was reported in April. This time, the Drupal security advisory warned of a new Remote Code Execution vulnerability in Drupal core. The new flaw was similar to CVE-2018-7600, and was a result of its fix, which didn’t cover all scenarios.
Although the vulnerability was highly publicized and many admins took action to ensure security, it appears many others weren’t as quick on their feet. According to security research published over two months after the first of the two Drupal vulnerabilities were published, multiple cryptojacking campaigns were discovered actively exploiting the vulnerability on hundreds of Drupal sites. This shouldn’t come as a huge surprise considering that researchers recently found over 115,000 Drupal websites are running outdated and vulnerable versions.
This is another important lesson in how important it is to continuously track and remediate open source security vulnerabilities in your code as soon as possible. Updating a Drupal version might be a hassle, but it’s nowhere near the nightmare of being hacked.
#4 Spring Data Commons
Vulnerability Score: Critical — 9.8
Vulnerability Score: High — 7.3
Affected versions: versions 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported version
April brought us not one, but two major security vulnerabilities in the Spring Data Commons project.
The more critical flaw, CVE-2018-1273, could be exploited by hackers to take control of systems and perform unauthorized operations via a remote code execution attack.
The second vulnerability, CVE-2018-1274 while garnering a slightly lower vulnerability score, is no slouch. It’s a property path parser vulnerability caused by unlimited resource allocation. Unauthenticated remote attackers could issue requests against Spring Data REST endpoints or endpoints using property path parsing, causing a denial of service (CPU and memory consumption).
The Spring Data Commons project is part of the much respected open source OG, the Spring Framework, a Java application development framework. The Spring Data project simplifies database access and supports cloud services like Commons, Gemfire, JPA, JDBC, MongoDB, and other modules, to enable a consistent, Spring-based programming model for data access without affecting the special traits of the underlying data store.
Every developer that has had to code to databases can tell you that it can be tedious. This is where Spring Data comes in to save the day, eliminating boilerplate code and abstracting data store interactions into a common repository API.
Spring Data includes various sub-projects that are specific to a given database. Spring Data Commons supports those modules, by abstracting away from any particular data source. It provides basic implementation and interfaces to the other Spring Data projects, with its technology-neutral repository interfaces and a metadata model for persisting Java classes.
To learn more about the vulnerabilities, visit the Pivotal vulnerability reports for CVE-2018-1273 and CVE-2018-1274.
#5 Requests
Affected versions: through 2.19.1 before 2018-09-14
Vulnerability Score: Medium — 4.3
Another November newbie is a remote attack vulnerability discovered in Requests, the beloved open source HTTP library for Python.
Security researchers found that vulnerable versions of the Requests package could expose sensitive information when receiving a specially crafted HTTP header. This is because the vulnerable package sends an HTTP Authorization header to an http URI when receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to uncover credentials.
The Requests project page on GitHub assures us that all the “cool kids” are using it, and if that doesn’t convince you, the Requests website boasts 400k daily downloads, and provides a long list of heavy-hitting users like “Nike, Twitter, Spotify, Microsoft, Amazon, Lyft, BuzzFeed, Reddit, The NSA, Her Majesty’s Government, Google, Twilio, Runscope, Mozilla, Heroku, PayPal, NPR, Obama for America, Transifex, Native Instruments, The Washington Post, SoundCloud, Kippt, Sony, and Federal U.S. Institutions that prefer to be unnamed”.
Since it’s a well-known fact among many in the Python community that Python users are Fonz level cool, if you’re coding in Python it’s best you check and see if you’re using a vulnerable version of Requests, and make sure that you update ASAP.
Find out more about the fix on GitHub, and more general advice on how to secure GitHub repositories.
#6 Apache Struts REST Plugin
Affected versions: 2.1.1 – 2.5.14.1
Vulnerability Score: Medium — 5.0
Another headline grabber that was discovered in 2018 was this Apache Struts vulnerability, published in April. A year and a month after the disclosure of the infamous Struts 2 vulnerability that Equifax ignored, a security vulnerability was discovered in the XStream handler in the Apache Struts REST plug-in.
The vulnerability allows remote attackers to create denial of service conditions by sending a specially crafted XML request using the XStream handler with the Struts REST plugin, causing the targeted software to stop functioning.
You can find more information about the vulnerability and its remediation here.
#7 Jenkins
CVE-2017-1000354: Vulnerability score: High — 8.8
CVE-2017-1000355: Vulnerability score: Medium — 6.5
CVE-2017-1000356: Vulnerability score: High — 8.8
Affected versions: 2.56 and earlier as well as 2.46.1 LTS and earlier
Jenkins was hit with a triple whammy in February.
This Java-based open source CI server is much beloved by many development outfits and supported by a large community.
The multiple issues that were discovered allow for Cross-Site Request Forgery (CSRF), meaning that hackers could execute various admin actions by tricking an unsuspecting victim into opening a web page.
In CVE-2017-1000354, which got a very high 8.8 CVSS v3 vulnerability score, a login command allowed impersonation of a Jenkins user.
CVE-2017-1000355, with a slightly lower 6.5 CVSS v3 score, is caused by an XStream vulnerability that could cause Java to crash through a DoS attack.
CVE-2017-1000356, another doozie with an 8.8 CVSS v3 rating is a vulnerability in Jenkins user database authentication that allows attackers to create an account on the application, enabling unauthorized disclosure of information and unauthorized modification.
You can read more about the vulnerabilities and their fixes on Jenkin’s security advisory.
#8 AngularJS
WS-2018-0001
WS-2018-0002
Vulnerability score: Medium — 5.5
AngularJS, another beloved open source framework, created and maintained by Google, got hit with double trouble last January.
In WS-2018-0001 JSONP could allow untrusted resource URLs, a very dangerous issue, since it provides hackers with an attack vector.
The second flaw, WS-2018-0002, occurs when rendering Angular templates with a server-side templating engine like ERB or Haml, allowing cross-site scripting (XSS). Attackers could exploit this to inject malicious client-side scripts into public web pages. These vulnerabilities are enabled by AngularJS evaluating user-provided strings containing interpolation symbols (default symbols are {{ and }}).
Notice that this is yet another case where vulnerabilities in a widely used open source project have not yet been added to the NVD. Luckily, we’ve got you covered, and you can learn more about WS-2018-0001 here, and about WS-2018-0002 here.
#9 Moment.js
Affected versions: before 2.19.3 for Node.js
Vulnerability Score: High — 7.5
This vulnerability was published in the NVD in March, but was previously known as WS-2017-0422 and included in our December open source vulnerability update, last year.
Moment.js is a popular open source JavaScript library that helps developers with the usually tedious task of coding date and time objects.
A vulnerability in Moment.js is a fairly rare occurrence, and this one isn’t pretty. It could leave users open to a ReDoS attack, which is why it got a high vulnerability rating of 7.5.
According to the npm advisory, users with vulnerable versions should update Moment.js to version 2.19.3. You can read more about the Moment.js vulnerability and its remediation on GitHub.
#10 Lodash
WS-2018-0210
Affected versions: before version 4.17.11
Vulnerability Score: Low — 3.5
This vulnerability is one of the newer issues on the list, published in November. A prototype pollution vulnerability was discovered in some functions in the Lodash node module. The vulnerable functions are merge, mergeWith, and defaultsDeep, and they can be tricked into adding or modifying properties of the Object prototype.
Developers love to use Lodash’s modular methods for iterating arrays, objects, and strings; manipulating and testing values and creating composite functions. Lodash documentation states that the component helps make JavaScript easier to handle by simplifying work with arrays, numbers, objects, strings, and more. Lodash’s current version on npm (v4.17.11) has nearly 17 million weekly downloads, which tells us that users agree.
You can read more about the vulnerability, and its fix on GitHub.
Leave no known open source security vulnerabilities behind
We can all agree that It’s been quite a year for the open source community.
The number of open source security vulnerabilities rose by 51% in 2017, and 2018 gave us approximately the same hefty serving of open source flaws in some of the most popular and well-maintained projects out there. While exploits of known open source vulnerabilities catch headlines that send shivers down our spine, we can see that there are still organizations that are too slow to patch or update vulnerable versions, and pay the cost, often in the public eye.
The open source community continues to focus on finding and fixing security vulnerabilities in their projects, promising that the volume of published vulnerabilities won’t be decreasing any time soon. The good news is that 97.4% of all reported vulnerabilities have at least one suggested fix in the open source community.
Organizations that want to make sure the hackers don’t beat them to the known vulnerabilities in their code have to make sure they’re on top of their vulnerable versions, managing their open source security with the right practices and tools.
Let’s do our best in 2019 to make sure we find ourselves in the headlines of tech news for all the right reasons.
Want to catch up on earlier 2018 open source vulnerabilities? Check out our top open source vulnerabilities page.
