Four Open Source Components You Need to Update Right Now

Four Open Source Components You Need to Update Right Now

May 07, 2014
By Brian Fox

Heartbleed has put the security community on notice: it is time to take a harder look at the security status of open source components and frameworks. After doing a little industry research on downloads from the (Maven) Central Repository, I'm sitting here with my jaw hanging open. Over 46 million Java-based open source components containing known vulnerabilities were downloaded from the Central Repository in 2013.

Heartbleed may be the most notorious manifestation of a component vulnerability, but there are four components with critical or severe vulnerabilities associated with specific versions that are still actively downloaded. I want to be clear that the projects typically do a great job of responding to and fixing vulnerabilities. The issue is that users don't respond as quickly to consume the fixes. Given that attackers are notified via the same mechanism that a vulnerability has been found and fixed, they effectively have first mover advantage, because it's generally easier to exploit than to update your application framework. We want to call attention to this problem.

Here are the top four downloads that should concern you the most. If you are running these component versions, you are opening yourself, and your company, to avoidable risk. If you aren't sure if you are using any of these vulnerable components, we can help with a complimentary assessment.

Struts

Struts is a popular application framework. Its popularity has waned in recent years, but it is still common among older, legacy Java applications. This vulnerability exists within the framework, so applications are vulnerable before a single line of custom code is executed.

Struts versions prior to 2.3.15.1 are vulnerable to CVE-2013-2251, which allows code to be uploaded anonymously and then executed as the application server user. This can lead to complete system compromise if the application server user has escalated permissions or if other vulnerabilities are chained together to escalate permissions.

Since the disclosure in July 2013, affected versions of Struts2 components were downloaded 179,050 times from more than 4000 organizations.

Bouncy Castle

Bouncy Castle is the most popular white-room implementation of cryptographic algorithms in Java. It's used because the Java runtime doesn't provide consistent algorithms across every platform. The Bouncy Castle implementation can run on any platform, hence its popularity.

Certain older versions of the implementations are susceptible to a "Bleichenbacher" attack. This attack allows an attacker to compromise the encrypted data and the decryption key by observing traffic over time. This essentially makes the thing you intended to encrypt completely open.

Since March 2009, 11,236 organizations have downloaded Bouncy Castle 214,484 times.

HttpClient

HttpClient is the most popular implementation of an http client in Java. HTTP is a protocol ubiquitous on the web. It's what web browsers use, but also REST APIs and many other common exchanges of data on the internet. HttpClient could be used in almost any scenario where data is exchanged across networks. It is also used in Android devices to process payments. This isn't just about big server applications, it's about the internet of things.

Since November 2012, 29,468 organizations have downloaded HttpClient 3,749,193 times.

Jetty

Mort Bay Jetty 6.x and 7.0.0 writes back-trace data without sanitizing non-printable characters, which might allow remote attackers to modify a window's title, or possibly execute arbitrary commands or overwrite files, via an HTTP request containing an escape sequence for a terminal emulator.

Since its release date in January 2010, 36,181 organizations have downloaded it 5,174,913 times.

What Can You Do to Prepare for the Next HeartBleed?

What can you do to remove these vulnerable components and frameworks from your applications? Use the following checklist to quickly determine your first steps to rid your apps, both in development and production, of vulnerable components.

  1. Perform an open source application analysis to determine if you are using any components with known vulnerabilities of severity level 8 or above.
  2. Perform a repository health check if you are using Nexus, to highlight vulnerable components still being accessed from within your repository.
  3. Update existing components to the most trustworthy versions for your systems.
  4. Implement a component management system, such as Sonatype Component Lifecycle Management (CLM), within your development environment, that automatically monitors the use of vulnerable components in development and production.

If you don't know what's in your apps, start by finding out. We'll help you run a quick health check to generate a "Bill of Materials" for your application or Sonatype Nexus Repository which provides details of all the OSS components used within your app, which versions of those components are being used and how to quickly remediate the most severe risks.