Our research team analyzed our database, which includes over 3M open source components and 70M source files, covering over 20 programming languages, to learn: which are the most popular open source projects currently in use and how safe are they?

This is what we found:

Let’s take a closer look at the popular open source projects found to be most vulnerable:

#1 Apache Tomcat

This open source web server takes the dubious title of the most vulnerable open source project, Apache Tomcat came in with 1096 known vulnerabilities. Specifically, this number includes Tomcat-Catalina – Tomcat’s servlet container, with 836 vulnerabilities, and Tomcat-Coyote – a connector component, with 260 vulnerabilities.

#2 struts2

Second in our most vulnerable list with 687 vulnerabilities, struts2 is one of the most popular frameworks for developing web applications in Java, due to its flexibility and extendibility.

Some of you may remember that just last month a vulnerable upload functionality in this open source project was exploited.

#3 Bash – 276 vulnerabilities

Bash is the shell, or command language interpreter, for the GNU operating system that offers functional improvements over sh for both interactive and programming use. Bash is portable and currently runs on nearly every version of Unix and a few other operating systems.

Though 276 is quite an impressive number, Bash has had one vulnerability that that still haunts the development community: I’m referring, of course, to the notorious Shellshock bug.

#4 Spring – 247 vulnerabilities

Spring is one of the most popular Java application development frameworks because of its modularity and lightweight. It incorporates layering, a lightweight container, and the ability to program on an interface.

#5 CXF – 169 vulnerabilities

Apache CXF is a framework for developing Web Services and front end interface communication, from small JSON utilities for web applications to a full-scale enterprise service bus (ESB). CXF includes a broad feature set, but it is primarily focused on Web Services Standards Support, Frontends, Ease of use and Binary and Legacy Protocol Support.

And, last but not least:

#6 Camel – 160 vulnerabilities

Apache Camel is an open source integration framework based on known Enterprise Integration Patterns (EIPs), that provides a standardized, internal domain-specific language (DSL) to integrate applications.

Java here, Java there

One of the first things that jumped out at me when reviewing this list was that five out of the six most vulnerable projects run on Java, and four out of those are development frameworks. Why are these projects so popular?

Experts recommend Open-source Java frameworks as a great way to jump-start application development and boost developer productivity, ultimately supporting better coding standards and helping to eliminate bugs.

Data from GitHub also reflects the rising predominance of Java projects, citing the popularity of Android, which uses Java as a primary language for building apps for phones and tablets, as well as the increasing demand for version control platforms at businesses and enterprises, as a possible stimulus to this growth. 

Why is everyone using Java-based projects if they are so exploit-friendly?

While the continuous rise of Java in open source projects is impressive, I can’t help but wonder: what about all these vulnerabilities? Clearly, these open source projects are less secure and easier for hackers to exploit, so why are so many organizations using them? Why is the open source community promoting them? Shouldn’t we work to avoid the open source Java components and replace them with safer proprietary or third party code?

The high number of vulnerabilities did, in fact, make my head spin. But – it’s not as simple as that. Open source projects do not contain more defects or vulnerabilities than proprietary ones. Both are patched and updated frequently.

The difference with these Java open source projects – and many other popular open source components, is that they are managed and supported by a dedicated open source community of experts. The fact that the open source vulnerabilities, as well as their fixes and updated versions, are well documented is a testament to that. While the security updates about the paid solutions that you are using come to you from vendors, the information about these popular open source projects is shared and published by the community for all users, frequently updated as new information and solutions are discovered.

One of the reasons developers made these top 6 open source projects so popular is because the support base is so reliable. So, the short answer is: keep making use of these open source resources. They are more likely to help you avoid and remediate critical vulnerabilities than leave you compromised.

Open source vulnerability management

 If you want to sleep peacefully at night, not to mention keep your security officers happy, it is important that you make sure you manage the security of your open source projects. Many development teams don’t even know the extent of the open source projects that they are using. Don’t be one of those teams. There are quick and reliable ways to monitor your open source components. Stay alert and updated regarding code updates and fixes. These open source security vulnerabilities shouldn’t be scary at all – as long as your survival kit is properly assembled.

What makes things worse, is that this Apache Struts vulnerability has been actively exploited in the wild since before it was formally released.

Unfortunately, even after the CVE was released with a fix, there have been many victims. So far two Canadian government agencies have reported they were attacked and evidence gathered show us they are not alone. As usual in these cases, we will know the total impact only a few months from now, but what should you do today?

About Apache Struts 2

Apache Struts 2 is an open-source web application framework for developing Java EE web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model view controller (MVC) architecture. The WebWork framework spun off from Apache Struts aiming to offer enhancements and refinements while retaining the same general architecture of the original Struts framework.

In the past 6 years, 71 security vulnerabilities were discovered in Apache Struts projects. Even though all vulnerabilities have been mitigated through patches or new versions, hackers still constantly exploit these vulnerabilities to launch attacks as companies’ response time to open source vulnerabilities is extremely slow. Just take into consideration that even 3 years after Heartbleed, the most notorious open source vulnerability out there, was released, nearly 200,000 online services are still vulnerable to it. Just imagine how many companies are using those vulnerable Apache Struts versions without eve knowing about the risk they are putting their software to.

The most commonly exploited Apache Struts vulnerabilities are known as Remote Code Execution (RCE), which allow the attacker to take over the server by running arbitrary malicious code.

What happened this time?

On March 6th, a new remote code execution (RCE) vulnerability was announced in Apache Struts 2 by publishing a new vulnerability (CVE-2017-5638). However, only the CVE number was announced and it was under ‘reserved’ status with no other information until March 10th, when full exploitation and remediation information were made public.

Although data was not made public until March 10^th, an official first exploitation was made a day after the vulnerability was announced and by March 14^th multiple attacks were reported from over 1,500 IP addresses from over 40 countries (almost 70% originated from China).

The recommended fix is to upgrade your Apache Struts versions. The vulnerable versions of Struts 2.3 to 2.3.31 should be upgraded to Struts 2.3.32 and Struts 2.5 to Struts 2.5.10 should be upgraded to Struts 2.5.10.1. VMWare, Huawei, Cisco and Atlassian have already issued an alert regarding their vulnerable product versions as a result from this CVE. Considering the fact that 2.3.1 was released in December 2011, there are millions of users worldwide that are probably unaware they are using this component or unaware that it’s vulnerable.

Furthermore, although a fix was released on March 10th, all evidence shows that the vulnerability is still exploited in the wild. The Government of Canada confirmed on March 13^th that some of its servers were breached by attackers making use of the Apache Struts flaw.

How does CVE-2017-5638 work?

According to Apache, the vulnerability exists in the Jakarta Multipart parser. When an invalid value is placed in the Content-Type header, an exception is thrown. The exception is used to display the error to the user. An attacker can exploit this vulnerability to escape the data scope into the execution scope through the Content-Type header.

The Content-Type header field is used to specify the format of information being sent so that the receiving application will know how to handle it. In HTTP requests, the “Unauthorized Request Content-Type” rule is triggered when either the Content-Type cannot be correctly established according to the RFC or when the Content-Type is identified as an unauthorized type.

What’s the lesson?

The lesson here is definitely not that open source components are not safe. Our regular readers know very well that we believe open source is as safe, if not more, compared to proprietary code.

What companies should understand is that nowadays, when their in-house code accounts for only 10% to 20% of their products, identifying whether they have known security vulnerabilities in their open source components should be done through automated tools.

This case is no different than many other open source vulnerabilities that are discovered on a regular basis. However, unlike many other open source vulnerabilities, this bug has gotten a lot of publicity and therefore alerted many security and software development teams to check if they are using the vulnerable versions. But what about the many other exploitable vulnerabilities in open source components that you are not aware of?

Mend.io customers were alerted a few hours after the details and remediation of the CVE were made public and could proactively protect their software from possible attacks.

So, here’s everything you need to know about the new nasty bug on the scene.

What’s the Story with This Dirty Cow?

Dirty Cow started its life in a 2007 release of the Linux kernel. Linus Torvalds was actually aware of the bug, and although he thought it trivial, he chose to fix it anyway as a precaution. However, the bug reared its ugly little head again when another developer unwittingly unraveled Torvald’s fix in order to patch a separate problem.

Fast forward to Oct 20^th, and Phil Oester (the researcher who found the vulnerability) reports that the Dirty Cow vulnerability has been alive and kicking for the past 9 years.

Who’s Affected?

Dirty Cow affects nearly every single Android and Linux distribution out there.

Basically, any Linux system with a web facing server is affected, making Dirty Cow one of the most serious bugs ever found in Linux.

What is it?

Dirty Cow is a “privilege escalation” vulnerability which allows attackers to circumvent the mechanisms for permission management in the kernel and edit files that are normally restricted, including operating system components. Therefore, it can be used to grant root access to a malicious application or user, all without leaving any trace of the breach.What’s also worrying, Oester reported that the bug is trivial to exploit and never fails.

A further piece of bad news is that it’s all but impossible for antivirus and security software to detect Dirty Cow. Yet antivirus signatures that detect the bug are possible. The key would be detecting the attack by comparing the size of the malicious binary against the size of the original binary.

On a positive note, Dirty Cow isn’t as severe as other high profile vulnerabilities (Heartbleed, Glibc), as hackers need to exploit a separate security issue to penetrate their target before they can execute Dirty Cow and gain root access. And even then, they’re limited to the specific container or VM where they executed the malicious code.

Vulnerability Info

Dirty Cow has been allocated CVE-2016-5195.

However, as the CVE is still reserved, as per normal reporting procedures, information is pretty few and far between.

What to Do Now

Patches are already available for RHEL, Debian and Ubuntu and other popular Linux OS.

Furthermore, now a patch has been pushed for the Linux kernel, an Android patch should be in the works. However, the soonest it will be released is in November’s patch batch, which is considered by many to be too long as the bug is being actively exploited.

Yet, later is better than never. While newer Android devices will be patched, older devices may miss out due to limitations placed by carriers and manufacturers.

Keeping Ahead of the Curve

Whether you are or aren’t affected, this a good opportunity for all Linux users to upgrade their security strength by updating their software.

Here at Mend, we continuously monitor and track the NVD, security advisories and open source projects’ bug trackers to ensure our market leading Vulnerability Database is always up to date.

Furthermore, the minute a vulnerable component is added to our customers’ repository/build, or a vulnerability is detected for a used component, we provide real-time remediation steps such as links to patches, fixes and recommendations to change system configuration. After all, it’s essential to be first in line when it comes to open source security.

This time, white hat hacker Dawid Golunski discovered a critical vulnerability affecting every available version (5.7.15, 5.6.33 and 5.5.52) of Oracle’s MySQL database and its clones, namely MariaDB and PerconaDB.

As is best practice when disclosing vulnerabilities, Golunski privately informed Oracle and manufacturers of Maria DB and Percona DB of the issue on July 29th 2016.

Information Leak

As Oracle haven’t yet released a patch, and 40 days passed since the other affected vendors released patches containing information allowing hackers to reverse engineer the vulnerability, Golunski decided to release a partial proof of concept, in order inform users of the risks before Oracle’s update next month.

So, here’s the rundown on everything you need to know. From the vulnerability’s specifications, the risk it presents and possible steps for remediation and mitigation.

MySQL Database Vulnerability Specifications

The vulnerability affects all MySQL, MariaDB and PerconaDB servers operating on default configuration.

How MySQL Databasae Vulnerability Operates

The MySQL Database vulnerability allows malicious settings to be injected into MySQL configuration files.

These settings allow attackers to execute arbitrary code with root privileges, allowing them full access to the server on which the affected MySQL installation is running. This means the attacker would not only have access to any information contained within the database, but they can also amend or even delete entries as well.

The vulnerability can be exploited both locally and remotely, by either the attacker possessing valid access credentials, or via SQL Injection.

Seeing as SQL Injections are one the most common issues in web applications, the SQL Injection attack vector is particularly worrying. This is because in the event of a successful SQL Injection attack, affected web applications would be at critical risk of exploitation.

MySQL Database Vulnerability Information

The MySQL Database vulnerability has been assigned CVE-2016-6662, but further information (e.g. severity and exploitability rating) are unavailable as the CVE is still undergoing its process of review.

How to Fix the MySQL Database Vulnerability

I’m pleased to say that both MariaDB and PerconaDB patched their versions on August 30th. However, no official patches or remediation have been released by Oracle to date.

Golunski advises that in the meantime users should ensure that “no mysql config files are owned by mysql user(s), and (they should) create root-owned dummy my.cnf files that are not in use”. Of course, once official vendor patches are released, they should be applied.

Keeping Your Eye on the Ball

Once again, a vulnerability such as the MySQL Database vulnerability reminds us all of the importance of tracking our open source component usage, and upgrading them or mitigating our system against vulnerability exploitation, as soon as possible.

But, surely it’s unrealistic for an organization such as yours to dedicate serious time and resources manually tracking its open source usage, and researching patches or remediation methods.

Here at Mend, we provide our customers with real-time alerts whenever a vulnerable component is added to a repository or build, or when a vulnerability is announced for a used component.

Furthermore, we automatically provide our customers with all possible remediation options, ranging from links to patches, new versions, recommendations to change system configuration and more, every time a new vulnerability is discovered.