Top 5 New Open Source Vulnerabilities in April 2018

May 3, 2018 Patricia Johnson

If April taught us anything, it’s that open source vulnerabilities are not for the faint of heart.

It seems like only yesterday that Drupal admins waited for security updates to fix April’s notorious Drupalgeddon, and — it’s back. As hackers have already started exploiting that nasty security issue, we’re here to tell you about how the hard working folk at Drupal’s security team have issued yet another security announcement after discovering another vulnerability.

We’ve put together a list of April’s top 5 new known open source security vulnerabilities, aggregated by the WhiteSource database, which is updated continuously from the National Vulnerability Database (NVD), and of course a number of open source publicly available, peer-reviewed security advisories.

Our top 5 list of projects hit by vulnerabilities this month consists of some oldies-but-goodies, as well as some fresh faces. All of the security vulnerabilities we’ve listed this month can be found in popular and widely used projects.

If you’re using open source components in your organization (newsflash: you are) you’re going to want to read this list. Please make sure to take action, and check your projects for vulnerable versions so that you can remediate and beat the hackers to it.

#1 Spring Data Commons

CVE-2018-1273

Vulnerability Score: Critical — 9.8

CVE-2018-1274

Vulnerability Score: High —  7.3

Affected versions: versions prior to 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions

This month, two major vulnerabilities were discovered in the Spring Data Commons project.

The first and more highly rated for risk is CVE-2018-1273. This vulnerability could be exploited by hackers to carry out a remote code execution attack, taking control of systems and performing unauthorized operations.

The second vulnerability found in Spring Data Commons this month is CVE-2018-1274, a property path parser vulnerability caused by unlimited resource allocation. Attackers can exploit this issue to consume excessive CPU and memory resources, resulting in a denial-of-service attack.

This two-for-one special comes to us courtesy of the Spring Data Commons project, part of the well established Spring Framework, the open source Java application development framework that we know and love, due to how modulare and lightweight it is, helping developers to easily create powerful applications.

The Spring Data project is aimed at simplifying database access and supporting cloud services, like Commons, Gemfire, JPA, JDBC, MongoDB, and other modules, providing 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. All of those modules are supported by Spring Data Commons, that does the job of abstracting away from any particular data source. It contains technology-neutral repository interfaces and a metadata model for persisting Java classes, providing basic implementation and interfaces to the other Spring Data projects.

 

#2 Drupal

CVE-2018-7602

Vulnerability Score: High — 7.4

Affected versions: Drupal 7.x, 8.4.x, and 8.5.x

This month, Drupal features in our no rest for the weary section. Or is it no rest for the wicked? Either way, hackers — rejoice, and Drupal web admins still wrestling with last month’s highly critical Drupal security vulnerability — look alive.

The Drupal security team recently published a new critical Remote Code Execution vulnerability, located in Drupal core. The new vulnerability, lovingly referred to as “Drupalgeddon 2”, is a lot like CVE-2018-7600, which we featured last month, and is a result of its fix, which apparently didn’t cover all scenarios.

The new vulnerability could allow an unauthenticated attacker to perform remote code execution on default or common Drupal installations. According to Drupal’s security announcement, the vulnerability “potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being compromised”.

Drupal’s security team went on to warn users that both recent vulnerabilities are already being exploited in the wild, and quite a few research teams have published data about numerous exploits and attempts that have been seen in the wild.

This continuation of Drupalgeddon provides us with yet another example of how extensive security vulnerabilities can be, and reminds us once again that we need to be vigilant in continuously tracking our open source components.

For more information about updating to safer versions, visit Drupal’s security advisory page.

#3 Apache Struts REST Plugin

CVE-2018-1327

Vulnerability Score: Medium — 5.0

Affected versions: 2.1.1 - 2.5.14.1

If it isn’t our old friend Apache Struts. We recently celebrated one year since the publication of that notorious Struts 2 vulnerability that caught Equifax unprepared, leading to the record breaking data breach which resulted in the theft of 145.9 million of personally identifiable information (PII) records.

The Apache Struts Project is an extremely popular open source project, supported by a large and active community. As is the case with open source libraries of this size and reach, it’s updated and tracked continuously, meaning issues are bound to arise. The good news is that they are swiftly discovered and published, this new vulnerability included.

The new security vulnerability lies in the XStream handler in the REST plug-in of Apache Struts. The vulnerability leaves systems open to a denial of service. A remote attacker sending a specially crafted XML request using the XStream handler with the Struts REST plugin, could cause the targeted software to stop functioning.

In case you have been offline for the past eight months and haven’t heard what happened when Equifax failed to track and remediate Struts vulnerabilities, please take it from us: check to see if one of your projects is using a vulnerable Struts version, and fix it now. Don’t say we didn’t tell you.

You can find more information about the vulnerability and its remediation here.

#4 Ruby on Rails

CVE-2018-3741

Vulnerability Score: Medium — 4.3

Affected versions:  all rails-html-sanitizer gem versions below 1.0.4 for Ruby

And

CVE-2018-8048

Vulnerability Score: Medium — 4.3

Affected versions: Loofah gem through 2.2.0 for Ruby, but only: when running on MRI or RBX, and/ or in combination with libxml2 >= 2.9.2.)

Basecamp, GitHub, Shopify, Airbnb, SoundCloud, Hulu, and Zendesk, are just a few of the applications built with Ruby on Rails. Released in 2014 it is used to create hundreds of thousands of applications to date. Developers love using Rails because it includes everything they need to create database-backed web applications according to the Model-View-Controller (MVC) pattern.

This month, vulnerabilities struck this open source project twice.

In CVE-2018-3741, a possible XSS vulnerability hit all rails-html-sanitizer gem versions below 1.0.4 for Ruby.

An HTML sanitizer removes unwanted code and protects against security concerns like cross-site scripting attacks, by sanitizing HTML input, stripping all tags and attributes that aren't whitelisted.

Unfortunately, with this vulnerability, the gem allows non-whitelisted attributes to be present in sanitized output when input with specially-crafted HTML fragments. These attributes can then lead to an XSS attack on target applications.

This issue is similar to CVE-2018-8048 in Loofah — the second Ruby vulnerability published this month.

Loofah is a library used by the aforementioned rails-html-sanitizer. An attacker could exploit this vulnerability by convincing a user to follow a malicious link that contains crafted HTML fragments, which could allow non-whitelisted attributes to be present in the output. The attacker could then execute arbitrary script code in the context of the targeted user's browser or allow the attacker to access sensitive browser-based information.

Shout-out to the Shopify Application Security team that put in some hard work and discovered the Loofah vulnerability, showing us once again that when all invested parties work together, the entire community wins, promising us secure components to help us build the products our customers need. Thanks Shopify AppSec team for helping us keep our Loofah squeaky clean.

More information about the rails-html-sanitizer vulnerability, CVE-2018-3741, can be found on GitHub.

If you want to learn more about CVE-2018-8048 — the Loofah vulnerability and remediation you can read about it here and here.

#5 FFmpeg

CVE-2018-10001

Vulnerability Score: Medium — 4.3

Affected versions: through 3.4.2

Last, and certainly not least is this vulnerability in the open source FFmpeg project.

FFmpeg is a collection of libraries and tools that help to process a variety of multimedia content, including audio, video, subtitles, and related metadata. This open source project is a leading multimedia framework that developers go to because it decodes, encodes, transcodes, and plays nearly everything. On addition, it supports a wide variety of formats, and is highly portable.

A security vulnerability discovered in a function in one of FFmpeg’s libraries, could allow remote hackers to use an AVI file to carry out a denial of service (out of array read) attack.

You can find more information about this vulnerability and its fix here.

Don’t Sweep Open Source Security Vulnerabilities Under the Rug

For us here at WhiteSource, today is the day for giving you the lowdown on the scariest open source security vulnerabilities published over the past month. Apparently, today, the third of May, is also the day we celebrate lumpy rugs. Yup — it’s lumpy rug day.

In celebration of this questionable holiday, we urge you to avoid sweeping known open source vulnerabilities under the rug, because those are the lumps that the hackers will celebrate, and will surely get you in trouble.

Attackers have already showed us that organizations that haven’t addressed the security issues in vulnerable Drupal versions, are at real risk of being attacked.

As open source users work with the community to ensure security vulnerabilities are discovered and addressed swiftly, it’s our responsibility to follow up, tracking the open source components in our code, and remediating any vulnerable version that puts us at risk.

Open source security management has to be a top priority. We’ve learned time and time again that open source vulnerabilities can’t be ignored or swept under the rug (who said Equifax?). Track your open source components continuously, and have a happy and risk-free lumpy rug day.

 
Previous Flipbook
Lessons Learned From the Equifax Breach
Lessons Learned From the Equifax Breach

Learn all about the Equifax breach: what went wrong with Equifax, the order of occurrences that led to the ...

Next Article
The Equifax Hack: 6 Months Later, What Did We Learn?
The Equifax Hack: 6 Months Later, What Did We Learn?