MySQL Security Analysis: mitigates the zero-day MySQL Vulnerability

Some of the world's largest companies (such as Facebook, Google and Adobe) and many smaller companies are using Oracle's MySQL database server software. Its performance, reliability, and ease of use make it an indispensable part of thousands of Web applications built on the LAMP (Linux, Apache, MySQL, Perl/PHP/Python) platform. In view of its large user base, recent zero-day vulnerabilities in MySQL have aroused high attention of the IT security team and aroused attackers's interest in MySQL security.
This article will discuss the security status of MySQL and the zero-day vulnerability threats of MySQL. We will also provide some feasible mitigation and possible MySQL alternatives for MySQL users.
　　MySQLZero-day vulnerability Overview
To determine the severity of recent zero-day vulnerabilities in MySQL, we must first thoroughly analyze each vulnerability. These Vulnerabilities have been assigned the following Common Vulnerabilities and Exposures CVE IDs:
• Stack-based buffer overflow in CVE-2012-5611 MySQL: This is triggered by sending a super-long parameter to the grant file command, which causes stack buffer overflow. It allows remote attackers to execute arbitrary code and may even cause database crashes.
• CVE-2012-5612 MySQL heap-based overflow: Low-privilege authenticated remote attackers can cause heap buffer overflow by sending a series of specially crafted commands.
• CVE-2012-5613 MySQL database privilege escalation: This is not considered a security vulnerability, but the result of a MySQL misconfiguration, which may cause remote authenticated users to gain administrator privileges.
• CVE-2012-5614 MySQL Denial of Service (DoS): One authenticated user can cause denial of service by sending SELECT commands and UpdateXML commands containing XML (with a large number of unique nested elements.
• CVE-2012-5615 MySQL remote preauth User Enumeration: remote attackers can discover valid MySQL usernames Based on MySQL-generated error messages.
At first glance, this list seems to point out many worrying issues, including DoS attacks, permission upgrades, authentication bypass, and code execution. But in fact the CVE-2012-5615 has been around for a long time and is recorded in the MySQL developer manual. In addition, if an attacker wants to successfully exploit the vulnerability CVE-2012-5611 (which is actually copying an older vulnerability CVE-2012-5579) and CVE-2012-5614, he/she will need a valid MySQL username and password. For CVE-2012-5613, attackers need a valid logon account for the person who has the FILE Permission (read/write access to the server. This is not a vulnerability because such known server behavior can only occur on servers with incorrect configurations. In the manual, you can only grant FILE permissions to the database administrator.
Therefore, in actual situations, only CVE-2012-5612 and 5614 need to cause real attention. The general vulnerability Scoring System (CVSS) is the standard method for evaluating security vulnerabilities. The score ranges from 0 to 10. 0 indicates the least serious, and 10 indicates the most serious. CVE-2012-5612 scored 6.5 and CVE-2012-5614 scored 4.0, so they are not the most serious vulnerabilities. No attacks exploiting these vulnerabilities have been reported yet, But Trend Micro has released the "Deep Packet detection" (DPI) rule that covers these vulnerabilities in its firewall rules.
　　Still worried about MySQL security? Try an alternative
For MySQL users who are still worried about potential vulnerabilities, you can take some measures to further protect MySQL. First, make sure that the commands sent from remote users to the database are valid and reasonable after verification. For example, the show fields from command should be blocked, which may only come FROM malicious users. At the same time, it is confirmed that MySQL does not have a listening port that can be accessed from the Internet; ideally, access to MySQL on the host or subnet is restricted. Confirm that all test accounts and unnecessary permissions have been deleted. When the new version is released, upgrade MySQL as soon as possible because these vulnerabilities are fixed.
After comprehensive risk assessment, MySQL users may consider MariaDB as a binary embedded substitute for MySQL if they still feel that the risk of using this product is too high. It not only features similar to MySQL (its developers mix with the MySQL code library every month to ensure compatibility), but also often patches MySQL before. In addition, MySQL does not have many options, storage engines, and vulnerability fixes, although there is no management support.
　　Summary
These zero-day vulnerabilities in MySQL may not be as serious as we think, but they remind us that correct configuration of database software and operating systems running these software are important factors to maintain data security. Although MySQL is easy to set up and use, enterprises should spend more time ensuring the security configuration of MySQL. Many enterprises are eager to launch new web applications and often ignore this step. Servers with misconfigured configurations are vulnerable to attacks. For all MySQL users, I suggest reading chapter 6 of the MySQL reference manual for security issues, especially Section 6.1.3 Making MySQL Secure Against Attackers. You can find information about MySQL vulnerabilities on the MySQL website.