MySQL, MariaDB, and PerconaDB administrators need to check their database versions, as attackers can chain two critical vulnerabilities and completely take over the server hosting the database.
The two critical vulnerabilities, which can lead to arbitrary code execution, root privilege escalation, and server compromise, affect MySQL and forks like Percona Server, Percona XtraDB Cluster, and MariaDB, according to security researcher Dawid Golunski, who provided details of the vulnerability on LegalHackers. Administrators should install the latest updates as soon as possible, or in cases where the patches cannot be applied, they should disable symbolic link support within the database server configuration by setting symbolic-links=0 in my.cnf.
Race condition gives access to the server
The first vulnerability, a privilege escalation/race condition flaw (CVE-2016-6663), gives elevated privileges to a local system user with access to a database and allows the him or her to execute arbitrary code as the database system user. This gives an attacker access to all of the databases on the affected server.
“The vulnerability can allow a local system user with access to the affected database in the context of a low-privileged account (CREATE/INSERT/SELECT grants) to escalate their privileges and execute arbitrary code as the database system user (typically ‘mysql’),” Golunski said. “Successful exploitation would allow an attacker to gain access to all of the databases stored on the affected database server.
The local system user simply needs to have local select, insert, and create privileges to exploit the vulnerability, which is related to unsafe operations on temporary files created by the REPAIR TABLE SQL statement. In MySQL-based databases, users with create privileges can specify a disk path of the directory where the new table will be stored. During the table repair process, if an attacker manages to unlink a temporary table and replace it with a symlink to a system directory (/var/lib/mysql) before it gets locked, the attacker would be able to apply arbitrary permissions on the data directory. For example, setting the permissions to the temporary table can result in the data directory becoming readable and writable because of the symlink.
At this point, the attacker can access mysql shell and run arbitrary code. To run mysql shell as a privileged system user (mysql), the attacker could create another directory with specific permissions and created the table in that path.
Affected database software include MySQL 5.5.51 and earlier, 5.6.32 and earlier, and 5.7.14 and earlier; Percona Server 5.5.51-38.2 and earlier, 5.6.32-78-1 and earlier, and 5.7.14-8 and earlier; Percona XtraDB Cluster 5.6.32-25.17 and earlier, 5.7.14-26.17 and earlier, and 5.5.41-37.0 and earlier; and MariaDB 5.5.52 and earlier, 10.1.18 and earlier, and 10.0.28 and earlier.
Gaining god mode
The privilege escalation/race condition flaw can be chained with another critical vulnerability, a root privilege escalation vulnerability (CVE-2016-6664), to further elevate the system level user to gain root on the server. The issue is related to the unsafe file operations performed by error logs and other system files. The error.log file on most default installations of MySQL, PerconaDB, and MariaDB is stored in either /var/log/mysql or /var/lib/mysql.
“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.
In a shared environment, where multiples databases belonging to different organizations and applications are hosted on the same server, this combination could give an attacker with access to the system as a lower-tier user full control over the machine. The race condition flaw can be combined with a different privilege escalation vulnerability, such as the one in MySQL reported in September, to gain rootshell on the server. Attackers can potentially gain a foothold on the server by exploiting a common web application vulnerability and work their way up to fully compromising the server.
Affected database software include MySQL 5.5.51 and earlier, 5.6.32 and earlier, and 5.7.14 and earlier; Percona Server 5.5.51-38.2 and earlier, 5.6.32-78-1 and earlier, and 5.7.14-8 and earlier; and Percona XtraDB Cluster 5.6.32-25.17 and earlier, 5.7.14-26.17 and earlier, and 5.5.41-37.0 and earlier. All current versions of MariaDB are affected by this flaw.
Understanding and applying updates
Oracle fixed the vulnerabilities in MySQL, and Percona has fixed the issues in Server and XtaDB Cluster. The MySQL fix can be a little confusing because the vulnerabilities were assigned different CVE identifiers in Oracle’s Critical Patch Tuesday. The race condition flaw is identified as CVE-2016-5616 and the root privilege escalation vulnerability as CVE-2016-5617 in last month’s Oracle CPU. Administrators who have already applied the MySQL updates from the Oracle CPU have the latest patches.
MariaDB fixed the race condition vulnerability and will close the root privilege escalation flaw in a later release. Since the root privilege escalation vulnerability cannot be exploited directly, the severity is less than the race condition flaw. While it does need to be fixed, the fact that another vulnerability is required to make the database exploitable gives the team some time to work on the patch.
Applying updates to servers, especially for production databases, is not as simple as downloading and installing updates on desktops and laptops. The patches have to be tested thoroughly, and administrators have to figure out the update window that would cause the least amount of disruption. This is why many vulnerabilities continue to be used in successful attacks long after a patch has been released. A vulnerability like this, which could implicate other databases and applications in a shared environment, requires an aggressive patching schedule to stay ahead of the inevitable attacks on the way.
