A researcher has published details and a limited proof-of-concept exploit for a critical vulnerability in MySQL that has been patched by some vendors, but not yet by Oracle.
The vulnerability allows an attacker to remotely or locally exploit a vulnerable MySQL database and execute arbitrary code, researcher Dawid Golunski of Legal Hackers wrote today in an advisory.
The flaw affects MySQL 5.7.15, 5.6.33 and 5.5.52. It has been patched in vendor deployments of MySQL in MariaDB and PerconaDB. Golunski said in his advisory that he reported the vulnerability to Oracle and other affected vendors on July 29. MariaDB and PerconaDB patched their versions of the database software before the end of August. Golunski said that since more than 40 days have passed and the two vendor fixes are public, he decided to disclose.
“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,” Golunski said. “No official patches or mitigations are available at this time from the vendor. As temporary mitigations, users should ensure that no mysql config files are owned by mysql user, and create root-owned dummy my.cnf files that are not in use. These are by no means a complete solution and users should apply official vendor patches as soon as they become available.”
A request to Oracle for comment was not returned in time for publication. Oracle declined to comment on this article. Oracle’s next quarterly Critical Patch Update is scheduled for Oct. 18; the last one in July addressed a record 276 vulnerabilities across Oracle’s product lines.
Golunski said the vulnerability, CVE-2016-6662, can be exploited via SQL injection attack, or by an attacker with valid credentials either locally or over the Web via phpMyAdmin, for example.
“A successful exploitation could allow attackers to execute arbitrary code with root privileges which would then allow them to fully compromise the server on which an affected version of MySQL is running,” Golunski said.
Golunski cautioned that the vulnerability can be attacked even if running on a server with SELinux or the AppArmor Linux kernel security module enabled.
Golunski said that the issue lies with a script called mysqld_safe which is used as a wrapper by MySQL default packages to start the MySQL service process. The wrapper executes as root, and the main mysqld process lowers its privilege level to mysql user, the researcher said. Golunski examined a particular function in the wrapper that can be used to pre-load a shared library before starting the server.
“If an attacker managed to inject a path to their malicious library within the config, they would be able to pre-load an arbitrary library and thus execute arbitrary code with root privileges when MySQL service is restarted (manually, via a system update, package update, system reboot etc.),” Golunski said.
A similar bug was patched in 2003, but Golunski said that exploits for his vulnerability would be able to bypass restrictions put in place 13 years ago by abusing logging functions in MySQL, which are available by default. An attacker would be able to inject a malicious configuration file, create new configuration files with in a MySQL data directory, or gain access to logging functions normally available only to admins.
Golunski also warned that a related vulnerability, CVE-2016-6663, will make exploitation trivial, he said.
“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,” he said. This will allow an attacker to escalate privileges to root, he added.
