A security researcher this week disclosed a zero-day MySQL vulnerability that could allow attackers to gain complete control of servers, though questions remain about whether or not the flaw had already been addressed by Oracle.
Dawid Golunski, the researcher who posted the advisory, reported the MySQL vulnerabilities on July 29 to Oracle, as well as to open source database vendors Percona and MariaDB, both of which were vulnerable to the same flaws as they are both MySQL forks. Golunski said both Percona and MariaDB had responded promptly and issued patches by the end of August, but, having heard nothing from Oracle, Golunski decided to go public with the first of the MySQL vulnerabilities he uncovered.
"As over 40 days have passed since reporting the issues and patches were already mentioned publicly," Golunski wrote, "a decision was made to start disclosing vulnerabilities (with limited PoC) to inform users about the risks before the vendor's next CPU update that only happens at the end of October."
The flaws would allow an attacker to abuse MySQL logging functions on improperly configured systems. Golunski's proof of concept attack starts by injecting malicious configuration data into MySQL configuration files with improper permissions. The next step is to create new configuration files, after which attackers would be able to escalate their MySQL privileges.
Oracle declined to comment on Golunski's MySQL vulnerability report. It's possible that Oracle addressed some of the issues in the report prior to Golunski's disclosure. The MySQL patches were released on Sept. 6, for MySQL 5.7, 5.6 and 5.5, all of which appear to address some of the flaws Golunski submitted under CVE-2016-6662.
"MySQL seems to have already released versions that include the security fixes [with MySQL 5.6.33]," Percona stated on its blog. None of the experts SearchSecurity spoke with could verify whether the Oracle patches released on Sept. 6 addressed the vulnerability, and Oracle has not released an official patch or security advisory that clarifies the situation.
How serious is it?
The advisory, wrote Golunski, describes a critical vulnerability assigned to CVE-2016-6662, "which can allow attackers to (remotely) inject malicious settings into MySQL configuration files (my.cnf) leading to critical consequences."
Jacob Williamsfounder, Rendition InfoSec LLC
MySQL servers using the default configuration in all version branches, including the latest versions, were found to be vulnerable, "and could be exploited by both local and remote attackers. Both the authenticated access to MySQL database (via network connection or web interfaces such as phpMyAdmin) and SQL injection could be used as exploitation vectors."
Experts were split on just how serious the MySQL vulnerability was. "It's serious, but it's not an unauthenticated vulnerability," said Jacob Williams, founder of consulting firm Rendition InfoSec LLC in Augusta, Ga. "Attackers need to have some way to issue queries to the server to make this exploitable. This might happen through shared access to a server or through another vulnerability such as SQL injection. The problem is that very low-privileged users can access unintended -- and known dangerous -- functionality that was not intended. This causes significant problems in shared hosting environments where multiple users are given access to a single MySQL database instance and their permissions are controlled by the database administrator."
However, Dmitry Chastukhin, lead SAP security analyst at ERPscan, suggested that the advisory's title may have overstated the "Remote Root Code Execution" aspect of the flaw. "In reality it is a privilege escalation vulnerability, which allows an attacker to escalate his or her rights -- in some cases -- on a server and gain root user privileges, if she or he can change the my.cnf configuration file. How to do it -- remotely and anonymously -- is a different matter. It requires other security issues in applications and weak configuration permissions on the server."
The attacker only needs to acquire some level of write permission in the filesystem to exploit this type of vulnerability, according to Mordechai Guri, chief science officer at Morphisec. Guri told SearchSecurity, "This is considered to be an easy task on the attacker's part. It's important to note that these semi-logic vulnerabilities won't go away and are proof that new approaches like moving target defense should be developed and deployed in many strata of the computer security stack, including operating systems, SQL language, et cetera."
What to do about it?
Williams had some specific suggestions for enterprises concerned about the MySQL vulnerability, starting with controlling access to the database itself. Since any user with SELECT permissions can access the administrative logging functions exploited in the vulnerability, "the configuration files which are normally owned by the MySQL user should be changed so they are owned by another user, such as root, and not writeable by the MySQL user."
"Finally, MySQL reads additional configuration data from my.cnf files," Williams noted. "One location it may read these from, /var/lib/mysql, must continue to have write permissions enabled for the MySQL server. To prevent attackers from writing a my.cnf file in this location as MySQL users, we are advising administrators to write my.cnf files owned by root in any directory where the MySQL user has write permissions."
"In all but extraordinary cases, MySQL should never be exposed to the open internet," said John Bambenek, manager of threat systems at Fidelis Cybersecurity in Waltham, Mass. "Ideally, a database server would behind a firewall in a standard three-tier design."
Oracle takes heat for its response
"Sometimes vulnerabilities can be complicated to patch and that could be delaying release," Bambenek said. "However, open communication with the researchers should be routine so that such issues are known. That said, considering other database platforms (PerconaDB and MariaDB) were able to patch, it calls into question whether complexity is really the issue for Oracle here. More importantly, Oracle should have developed some mitigation or something to protect enterprises in the meantime."
"Oracle's response to vulnerabilities involving open source projects must be more vigilant than those involving only closed source," Williams said. "Anyone can fork an open source project and they are likely to be notified as well when vulnerabilities are reported. If the open source project patches first, then Oracle's customers are exposed. I think it's clear that quarterly patching cycles are no longer sufficient in today's vulnerability research climate."
As for the takeaway for enterprises, Williams added, "If you aren't comfortable with quarterly patching, vote with your wallet. There are other database solutions out there and seeing Oracle hold to a quarterly patching schedule when open source forks have already patched is very troubling. Changing database engines is very expensive for an enterprise. If this behavior from Oracle continues, I'd definitely recommend examining your options."
"The fact that two other open source projects patched the same vulnerability before Oracle says a lot about their responsiveness," Williams said. "These are obviously serious vulnerabilities and because they are present in other projects, Oracle doesn't get to control the patch release timeline."
"In my opinion, this case is a good illustration of poor interaction between Oracle PR and tech departments," Chastukhin said. "They could have responded to Golunski's report in due time and publicly announced that the vulnerability was not as dangerous as the researcher stated and the patch was already released. In this turn of events, Oracle could have become the winner of the situation."
"What do we have now? A pile of articles with harsh criticism and frustration of system administrators."
This is not the end of the story, though. Golunski noted that "attackers could use one of the other vulnerabilities discovered by the author of this advisory, which has been assigned a CVEID of CVE-2016-6663 and is pending disclosure. The undisclosed vulnerability makes it easy for certain attackers to create /var/lib/mysql/my.cnf file with arbitrary contents without the FILE privilege requirement."
Find out more about mitigating MySQL vulnerabilities.
Read more about how to spot security flaws in open source web applications.