Critical MySQL Database Vulnerability Puts Your Data at Risk

It’s happened again. Yesterday a new critical open source vulnerability was detected.

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.

So, how are you tracking your open source usage?