The vulnerability (CVE-2016-6662) can be exploited by hackers to inject malicious settings into MySQL configuration files or create their own malicious ones.
The critical flaw affects all default versions of MySQL and has been disclosed after Oracle failed to patch the flaw promptly.
A researcher has disclosed a zero-day flaw in the widely-used MySQL database application after Oracle reportedly failed to patch the critical security hole.
On Monday, independent security researcher Dawid Golunski released his findings through a public security disclosure, stating that over 40 days have passed since the zero-day vulnerability was reported to the vendor.
The bug, CVE-2016-6662, is a privilege escalation flaw which impacts all version branches of MySQL, including 5.7.15, 5.6.33 and 5.5.52, as well as software linked to MySQL, including MariaDB and PerconaDB.
CVE-2016-6662 can be exploited if an attacker has an authenticated connection to MySQL, such as through shared networking or web interfaces. Attackers are able to inject malicious settings into MySQL configuration files, my.cnf, to gain root access and execute additional malicious code.
The previously unknown vulnerability can be exploited by both local and remote attackers and can lead to remote code execution with root privileges, which in turn can grant an attacker the ability to fully compromise a server.
To summarize, the methods used to gain root privileges require multiple conditions:
- A remote (or even local) MySQL user that has FILE permissions (or SUPER, which encompasses all of them).
- Improper OS files/directories permissions around MySQL configuration files that allow the MySQL system user access to modify or create new configuration files.
- Several techniques alter the MySQL configuration to include loading a malicious shared library.
The techniques currently described require FILE or SUPER privileges, but also include the currently undisclosed CVE-2016-6663 (which demonstrates how to alter the configuration without FILE privileges).
- Have that malicious shared library loaded when MySQL restarts, which includes the code that allows privilege escalation.
The researcher has also provided proof-of-concept (PoC) code to demonstrate his claims. However, the PoC has been limited — for now — as a way to warn users and give Oracle time to issue a fix before a full PoC is released to the public.
The critical flaw was first reported to Oracle on 29 July and was triaged by the company’s security team. The flaw was also reported to other vendors affected by the vulnerability, including PerconaDB and MariaDB. PerconaDB and MariaDB have both patched the problem and so users of the two firms’ software are now safe from this flaw, but Oracle is yet to push a patch to fix the bug.
“During the course of the patching by these vendors the patches went into public repositories and the fixed security issues were also mentioned in the new releases which could be noticed by malicious attackers,” Golunski says.
No MySQL Patch Available Yet
Golunski reported the zero-day flaws to Oracle on July 29 and other affected vendors on July 29.
While Oracle acknowledged and triaged the report, scheduling the next Oracle CPUs for October 18, 2016, MariaDB and PerconaDB patched their versions of the database software before the end of August.
Since more than 40 days have passed and the two vendors released the patches to fix the issues, Golunski said he decided to go public with the details of the zero-days.
“As over 40 days have passed since reporting the issues and patches were already mentioned publicly, 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 researcher added.
“As temporary mitigations, users should ensure that no MySQL config files are owned by MySQL users, and create root-owned dummy my.cnf files that are not in use,” the expert wrote in his advisory. “These are by no means a complete solution and users should apply official vendor patches as soon as they become available.”
Oracle’s next Critical Patch Update (CPU) is scheduled for October 18. SecurityWeek has reached out to the company for clarifications and will update this article if representatives respond.
The exploit is not available yet but Hackers are really eager to exploit the affected servers.