Privilege escalation is the method of exploiting a bug, design flaw, or configuration issue in an operating system or software application to gain access to resources that are having restrictions to use by other users. An independent researcher Dawid Golunski exposed a privilege escalation vulnerability (CVE-2016-5616/CVE-2016-6663) present in MySQL, MariaDB, and PerconaDB databases. Vulnerability management software is the solution for this problem.
This issue is in legalhackers advisory along with PoC by Dawid Golunski on November 01, 2016. The author of the advisory states, “This vulnerability allows a local system user, who has CREATE/INSERT/SELECT grants with access to the affected database that can escalate their privileges and execute arbitrary code as the database system user (typically ‘mysql’)”.
In addition to mitigating security vulnerabilities, using secure data integration methods, such as those provided by ETL tools for MySQL, can help streamline data processing and protect database environments.
VULNERABILITY (affected versions):
MariaDB
< 5.5.52
< 10.1.18
< 10.0.28
MySQL
<= 5.5.51
<= 5.6.32
<= 5.7.14
Percona Server
< 5.5.51-38.2
< 5.6.32-78-1
< 5.7.14-8
Percona XtraDB Cluster
< 5.6.32-25.17
< 5.7.14-26.17
< 5.5.41-37.0
EXPLOIT:
(1) For instance, create a directory /tmp/mysql_exploit to store database.
(2) Create a database user, for instance, taken as “testuser” with password “test” and grant permissions to the testuser for performing operations on the database “EXPLOIT”.
(3) Create a TABLE and give the path of the data directory so that the TABLE will be stored in that particular path. From this, we can clearly understand that the owner and group owner are “MySQL” for the created TABLE. CVE-2016-5616
(4) Executing the REPAIR table command performs some unusual operations. It will invoke some of the system calls like open files, read files, change permissions, etc. It mainly checks file permissions of the table1 file, which is then copied with chmod() to the newly created table1.TMD temporary file containing the repaired table.
The code is vulnerable to Race Conditions between the call:
lstat(“/tmp/mysql_exploit/table1.MYD”, {st_mode=S_IFREG|0660, st_size=0, …}) = 0
and
chmod(“/tmp/mysql_exploit/table1.TMD”, 0660) = 0
This is happening by first pre-setting permissions on table 1.MYD to 04777 (suid), and winning the race so that the permissions apply on a copy of a bash shell file through the vulnerable chmod() call. This effectively creates a shell that elevates their permissions after execution. But here there is a problem. Even though the user gains access, their suid shell remains to be owned by the user’s respective id and not the ‘MySQL’ user. Further, to access as a ‘mysql’ user, database users need to copy the bash shell to the table created. But MYSQL doesn’t allow database users to copy to its directory. This can be bypassed if the user creates a specially crafted directory with a group sticky bit “g+s” and then create a table.
(5) Creating specially crafted directory and repeating above steps again from scratch (creating table2). So here we can see a change in the permissions i.e., table2 has “mysql” as an owner but “root” as a group. Now database user will be easily able to copy /bin/bash to table2.MYD file and preserve the file ownership.
Finally, the user can exploit the Race Condition again and have SUID + execute permissions applied on table2.MYD which would then allow them to execute the suid shell with elevated privileges of the ‘mysql’ user. CVE-2016-5616.
To prevent these attacks from occurring, a good vulnerability management tool can be helpful.
Using PoC source code written by Dawid Golunski:
(Source code is saving as mysql.c for instance)
(a) Compiling file as per usage mentioned in source code
Usage : gcc mysql.c -o mysql -I/usr/include/mysql -lmysqlclient
(b) Executing mysql-privesc-race gives mysql-suid-shell
Usage : time ./mysql USER PASSWORD HOST DATABASE
(Executed on Ubuntu 16.04-x64)
Installed package: MariaDB-server and its dependent packages v10.0.24-7
Before performing the exploit, the user will not have access to MySQL directory:
Once exploitation is performing
This vulnerability can also be chained with other privilege escalation vulnerabilities discovered earlier (CVE-2016-6662 and CVE-2016-5617) to further escalate privileges from mysql user to root user and thus allow attackers to fully compromise the target server. CVE-2016-6663 is the original CVE that was agreed to be used by all the affected vendors. This issue was however mentioned in Oracle CVE mistakenly under a new CVE of CVE-2016-5616, resulting in duplication. Oracle has informed to state that CVE-2016-5616 is equivalent to CVE-2016-6663 which is mentioned in Oracle advisory.
WORKAROUND:
As temporary mitigation, the user can disable symbolic link support in the database server configuration with the following my.conf config setting:
i.e., Open /etc/my.cnf (for instance, considered LINUX operating system) and comment in the line mentioned below to prevent security risks
symbolic-links = 0
However, applying the updates is to as patches are releasing from respective official vendor websites.
IMPACT:
Malicious users can exploit this vulnerability in a common hosting environment where each user has access to only one database assigned to them. It could also be exploited by attackers who have managed to find a vulnerability on a website and gained access to the target system as a low-privileged user (such as Apache/www-data).
Since these are the wide databases in the world. We recommend users install the latest patches and prevent their systems from this vulnerability from exploitation.
SanerNow detects these vulnerabilities and automatically fixes them by applying Important and critical security updates. Download Saner now and keep your systems updated and secure.