It’s happened again. 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.
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.
The vulnerability affects all MySQL, MariaDB and PerconaDB servers operating on default configuration.
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.
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.
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.
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.