Privilege escalation is the method of exploiting a bug, design flaw or configuration issues in an operating system or software application to gain access to resources that are restricted to be used 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.

This issue was disclosed 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’)”.

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”.

2

(3) Create a TABLE and give the path of data directory so that the TABLE will be stored in that particular path. From this, we can clearly understand that owner and group-owner is “mysql” for the created TABLE.

3

4

(4) Executing REPAIR table command performs some unusual operations. It will invoke some of the system calls like open file, read file, change permissions etc. It mainly checks file permissions of table1 file which is then copied with chmod() to the newly created table1.TMD temporary file containing the repaired table.

5

The code is vulnerable to Race Condition 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 could be done by first pre-setting permissions on table1.MYD to 04777 (suid), and winning the race so that the permissions get applied 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 would gain access, their suid shell would remain to be owned by the user’s respective id and not ‘mysql’ user. Further, to access as ‘mysql’ user, database users need to copy 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 created 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.

6

7

8

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.

Using PoC source code written by Dawid Golunski:

(Source code is saved 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

910

Before performing the exploit, the user will not be having access to mysql directory:

11

Once exploitation is performed i.e., when database user gets the access of mysql-suid-shell, they can gain complete access to files under mysql directory which can be seen below:

12

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 a temporary mitigation, the user can disable symbolic link support in the database server configuration with the following my.cnf 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 recommended as patches are released from respective official vendor websites.

IMPACT:

Malicious users can exploit this vulnerability in a shared hosting environment where each user is supposed to have 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 most widely used databases in the world, we recommend users to install latest patches and prevent their systems from this vulnerability being exploited.

 

SecPod Saner detects these vulnerabilities and automatically fixes it by applying Important and critical security updates. Download Saner now and keep your systems updated and secure.

Loading Facebook Comments ...

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>