Oracle Corp.'s MySQL database server software is used by some of the world's biggest companies -- think Facebook, Google and Adobe -- as well as many smaller businesses. Its performance,
While MySQL is easy to set up and use, take the time to ensure it is configured securely, a step that is often overlooked in the rush to launch a new Web application.
In this tip, we'll discuss the state of MySQL security and determine the threat posed by these MySQL zero-day vulnerabilities. We'll also provide some possible mitigations for concerned MySQL users, including a potential MySQL alternative.
MySQL zero-day overview
To determine the severity of the recent MySQL zero-days, we must first delve into what exactly each vulnerability entails. These vulnerabilities have been assigned the following Common Vulnerabilities and Exposures (CVE) IDs:
- CVE-2012-5611 MySQL stack-based buffer overrun: This is triggered by sending an overly long argument to the GRANT FILE command, which in turn leads to a stack-buffer overflow. It permits remote attackers to execute arbitrary code or may even cause a database crash.
- CVE-2012-5612 MySQL heap-based overrun: A remote, authenticated attacker with low privileges could cause a heap-buffer overflow by sending a series of crafted commands.
- CVE-2012-5613 MySQL Database privilege elevation: This is not considered to be a security bug as it's a result of a MySQL misconfiguration that could lead to remote authenticated users gaining administrator privileges.
- CVE-2012-5614 MySQL denial of service (DoS): By sending a SELECT command with an UpdateXML command containing XML with a large number of unique, nested elements, an authenticated user could cause a DoS.
- CVE-2012-5615 MySQL remote preauth user enumeration: A remote attacker could discover valid MySQL usernames based on error messages generated by MySQL.
At first glance, this list may appear to highlight a worrying number of problems, including DoS attacks, privilege escalation, authentication bypass and code execution. However, CVE-2012-5615 has been known for a long time and is documented in the MySQL developer's manual. Also, for an attacker to successfully exploit vulnerabilities CVE-2012-5611 (actually a duplicate of an older bug CVE-2012-5579) and CVE-2012-5614, he or she would need a valid MySQL username and password. CVE-2012-5613 also requires the attacker to have the valid credentials of someone that has been granted FILE privilege (read/write access on the server). This is not a vulnerability, as such, because this documented server behavior can only be exploited in the case of a misconfigured server. The manual says that, at most, database administrators should have FILE privilege.
So in practical terms, only CVE-2012-5612 and 5614 are of any genuine concern. The Common Vulnerability Scoring System (CVSS) is a standardized method for assessing security vulnerabilities, with scores ranging from 0, the least severe, to 10, the most severe. CVE-2012-5612 has a score of 6.5 and CVE-2012-5614 has a score of 4.0, so they are not critical. No attacks leveraging these exploits have been reported in the wild, but Trend Micro Inc. has released "deep packet inspection" (DPI) rules covering these vulnerabilities for its firewall.
Still uneasy about MySQL security? Try an alternative
For MySQL users still concerned about potential exploits, there are steps that can be taken to further secure a MySQL implementation. As always, ensure commands passed to a database via remote users are verified as being valid and expected. For example, a SHOW FIELDS FROM command should be blocked; such a command would only come from a malicious user. Also, confirm that MySQL does not listen on a port that is accessible from the Internet; ideally, limit access to MySQL on a host or subnet basis. Verify that all test accounts and unnecessary privileges have been removed, and upgrade MySQL as soon as each new version is released, as this will include fixes for these vulnerabilities.
From the editors: More on database security
Does Windows Server 2012 provide enough security benefits to warrant an upgrade?
Reassess the security of your SAP implementations in light of server-side request forgery attacks.
For those MySQL users who, following a thorough risk assessment, determine the risk of using the product is too great, consider MariaDB, a binary drop-in replacement for MySQL. Not only does it function similarly to MySQL (the creators run monthly mergers with the MySQL code base to ensure compatibility), but it is also often patched before MySQL is. Plus, it offers a lot of options, storage engines and bug fixes that are not in MySQL, though admin support can't be bought.
While these MySQL zero-days may not be as serious as first thought, they do serve as a reminder that correctly configuring database software, and the operating system that it is running on, is a crucial part of keeping the data it holds secure. While MySQL is easy to set up and use, take the time to ensure it is configured securely, a step that is often overlooked in the rush to launch a new Web application. Misconfigured servers are vulnerable to attack. For anyone using MySQL, I recommend reading chapter 6 of the MySQL Reference Manual, which covers security and, in particular, section 6.1.3 Making MySQL Secure Against Attackers. You can find Information about MySQL bugs at the MySQL site.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is founder and managing director of Cobweb Applications Ltd., a consultancy that helps companies secure their networks and websites, and also helps them achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. Michael is also a Microsoft Certified Database Administrator and a Microsoft Certified Professional.
This was first published in March 2013