Critical vulnerabilities in MySQL and vendor deployments by database servers MariaDB and PerconaDB have been identified that can lead to arbitrary code execution, root privilege escalation and server compromise.
Dawid Golunski of Legal Hackers published details around two proof-of-concept exploits for the vulnerabilities on Tuesday.
Both vulnerabilities affect MySQL 5.5.51 and earlier, 5.6.32 and earlier, and 5.7.14 and earlier, along with MySQL database forks such as Percona Server and MariaDB.
The first vulnerability, a privilege escalation/race condition bug (CVE-2016-6663) is the more severe of the two. It can allow a local system user that has access to a database to escalate their privileges and execute arbitrary code as the database system user, Golunski said in an advisory. From there, an attacker could successfully access all of the databases on the affected database server.
More troubling, an attacker could chain the vulnerability together with a privilege escalation vulnerability, like the one Golunski uncovered in MySQL back in September, or the second, separate vulnerability he disclosed this week to further escalate privileges to the root system user. After doing so, an attacker could fully compromise the target server.
Golunski warns the vulnerability could be exploited in a shared hosting environment where users are technically assigned to just one database, or by an attacker who could have gained access to a system as a lower tier user.
The second vulnerability uncovered by Golunski is a root privilege escalation bug that can be used in tandem with the race condition bug. Affected is MySQL and all current builds of MariaDB and select builds of Percona Server and Percona XtraDB Cluster.
The vulnerability is tied to the unsafe file handling of error logs and other files. Assuming an attacker has already gained MySQL system user access through the CVE-2016-6663 exploit they could further escalate their privileges on the system as root user. The error.log file is the crux of the problem here; because of the way it behaves, it performs unsafe file operations that can allow it to be removed and quickly replaced with an arbitrary system file, something that opens the door to root privileges.
According to the researcher, combining this bug with the other privilege escalation bug would make things even messier.
“The combination of the two would effectively allow low privileged local database users to escalate their system privileges to root system account and allow them to fully compromise the server which increases the severity of this issue,” Golunski writes.
Golunski told Threatpost on Wednesday that the vulnerabilities have been fixed by the database management systems for the most part. MySQL and Percona released patches for both issues after he privately disclosed the bugs to them.
MariaDB is the lone holdout, at least for now. The database server project fixed first bug but has not patched the root privilege escalation vulnerability yet. According to Golunski, based on his interaction with the company, developers there were focused on fixing the Privilege Escalation/Race Condition vulnerability (CVE-2016-6663) first.
When reached on Wednesday, a spokesperson from MariaDB said the database would fix the CVE-2016-6664 in a future release:
To clarify, CVE-2016-6664 requires another vulnerability in order to be exploitable. With CVE-2016-6663 fixed, there are no known exploitable vulnerabilities in MariaDB. We are planning to fix CVE-2016-6664 in an upcoming release, MariaDB said.
Golunski first warned about CVE-2016-6663, undisclosed at the time, back in September when he divulged details around another issue, a remote root code execution and privilege escalation vulnerability (CVE-2016-6662) in MySQL. MySQL ultimately fixed that bug quietly without informing Golunski. All of the fixes ultimately found their way into Oracle’s quarterly Critical Patch Update – the most recent two coming under different CVE names (CVE-2016-5616, and CVE-2016-5617) – last month.
Golunski, who plans to publish a video demonstrating how an attacker could use the proof-of-concept exploit on all three database systems on Wednesday night, is encouraging users to update to the latest version regardless of what they use.
