Skip to main content

A nasty pair of MySQL exploits grant attackers system root from any database user

Four days ago I received an email from Dawid Golunski through the list illustrating one of the more brutal pair of security vulnerabilities I have seen recently. Here's how it works.
    The exploit uses a vulnerability within MariaDB, PerconaDB (and/or XtraDB Cluster) and MySQL to, first, gain access to the 'mysql' system user using any mysql user that has CREATE / INSERT / UPDATE permissions. The first part revolves around a race condition when sql generates temporary files as part of the `REPAIR table` command. Then using the mysql system user the second vulnerability grants the attacker root access to the server using a clever hack that takes advantage of mysql_safe's approach to writing to file based error logs. Below I've provided a list of vulnerable server versions. Just about any server using the more recent (unpatched) stable releases of MySQL or MariaDB through CentOS is vulnerable (Percona isn't part of the standard CentOS repositories), with a few of caveats.
    The first caveat is that an unpatched vulnerable server can prevent at least the 2nd exploit by disabling symlinks through /etc/my.cnf using skip-symbolic-links or symbolic-links=0
    The next caveat is that the 2nd exploit also depends on using file-based mysql logging. Using syslog will avoid trouble.
    The third caveat is that for the 1st exploit to work an attacker needs a mysql user and password.
    There is some good news here. The latest stable versions of MariaDB at least disable symbolic links in my.cnf by default (its been a while since I installed MySQL through the repo but I'm fairly sure its disabled here as well). And how would an attacker get a MySQL user anyway?
    Consider that because *any* MySQL user to be used, an un-patched shared server used by a hosting company would depend on the security competency of every one of that c customers to securely handle database authentication. Not only are there a variety of exploits available for obtaining a standard database user, but its depressingly common for web designers to place their connection strings with un-encrypted database username and password into world-readable files. There are a variety of feeds and sites that scan the internet for and compile such files.
    And even without the use of the 2nd exploit, an attacker can still do an enormous amount of damage without server root with only the mysql system user. The attacker will have full access to the MySQL system files. An attacker could easily delete an entire database instance, for example.
    Of course the best part is that this is a vulnerability in MySQL itself. Upgrading MySQL is the scariest, riskiest upgrade there is among standard repo software. A lot of admins compile it from source or install it from a direct RPM (in which cases symlinks are enabled by default). And applications are closely linked with the database version. Even successful upgrades can easily break applications that run on that database as calls used by the application become deprecated. Upgrading applications has substantial costs, whether you develop the application itself or license it. A patch was already in circulation before these exploits were posted, but for all of the reasons listed above, vulnerable databases will be active for years.

Here are the impacted DB 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

Here the first two links below contain a comprehensive breakdown of both exploits with example scripts that you can run to test.

http://legalhackers.com/advisories/MySQL-Maria-Percona-PrivEscRace-CVE-2016-6663-5616-Exploit.html

https://legalhackers.com/advisories/MySQL-Maria-Percona-RootPrivEsc-CVE-2016-6664-5617-Exploit.html

This link includes a video illustrating how a compromise takes place using the example scripts:
http://legalhackers.com/videos/MySQL-MariaDB-PerconaDB-PrivEsc-Race-CVE-2016-6663-5616-6664-5617-Exploits.html

Comments

Popular posts from this blog

Fixing Event ID 10154 - The WinRM service failed to create the following SPN

The Problem The configuration of the system when this error was encountered is as follows: A. Windows Server 2008 R2 Redundant Domain Controllers - we will call these DC1.joshwieder.com and DC2.joshwieder.com B. Windows Server 2003 Web Server with Windows Remote Management enabled / part of the Active directory deployment - we will call this WEB.joshwieder.com C. For the sake of our example, let's say I have configured an OU named "Web Servers" on those domain controllers Whenever the Windows 2003 Web server reboots, or WinRM.exe service on the Windows 2003 Web server restarts, the following error was logged into the Event Viewer: Event ID: 10154 Source: Microsoft-Windows-WinRM Version: 6.1 Symbolic Name: LOG_WSMAN_SPN_CREATION Message: The WinRM service failed to create the following SPN: %1. Additional Data The error received was 8344: Insufficient access rights to perform the operation. User Action The SPN can be created by an administrator using sets

Email server using amavisd-new fails with (!)DENIED ACCESS from IP 1.2.3.4, policy bank ''

I have used ClamAV and Spamassassin for many years. I've had a less experience with Amavis (now amavisd-new), but I've decided to give it a try with a new mail server deployment I've been working on. As a reference for my install, I relied on the documentation provided by Amavis for integration with Postfix  as well as a somewhat-outdated but still-relevant walkthrough published by CentOS . Prior to integration with amavisd, Postfix worked fine. Similarly, I had no issues with Spamassassin on its own. But once I finished my install of amavisd-new, things quickly went wrong. Attempting to send messages to accounts hosted on my email server resulted in the following chaing of errors in my maillog: Jan 13 18:17:34 hostname amavis[31578]: Net::Server: 2016/01/13-18:17:34 CONNECT TCP Peer: "[192.168.1.1]:40209" Local: "[127.0.0.1]:10024" Jan 13 18:17:34 hostname amavis[31578]: loaded base policy bank Jan 13 18:17:34 hostname amavis[31578]: lookup_ip_

Wikileaks Global Intelligence File Dump is Loaded With Malicious Software

Click here for the second post on this topic, which includes more detailed technical information. Hector Monsegur, formerly sabu of Lulzsec, has offered his point of view on this post. Get his opinion by reading my third post on the topic. In my fourth post on this topic, I explain how malware is not limited to the Stratfor leak torrent - curated links throughout the Wikileaks.Org website allow users to download individual infected files . This series of posts is beginning to receive coverage from several newspapers around the world. German speakers should check out the story in Neue Zürcher Zeitung / New Zurich Times . For English speakers, I recommend The Register from the UK for an excellent summary of these findings . Beginning in  February 27, 2012 , the controversial news organization Wikileaks has been publishing a large and growing trove of emails from the private intelligence firm  Strategic Forecasting, Inc (more widely known as  Stratfor). The leak publication bega