MySQL (Database) Race Condition my_copystat Privilege Escalation

A race condition vulnerability exists in the MySQL, MariaDB, and Percona databases. This vulnerability will allow a local attacker (remote access via a web shell or SSH connection) who has a low privileged account (CREATE/INSERT/SELECT grants) on the affected database to escalate their privileges and execute arbitrary code as the database system user.

Exploitation

Stages

1. The local (remote with web shell access) attacker uses low level SQL privileges to enter race loop using REPAIR TABLE statement.
2. During REPAIR TABLE of a MyISAM table, a temporary data file (.TMD) is created.
3. When repair finishes, this file is renamed to the original .MYD file. The stats from the old file are copied to the new file with chmod/chown.
4. If the attacker manages to replace the temporary file before chmod/chown was executed, it is possible to get an arbitrary file with the privileges of the MySQL user.

Prerequisites

• You need local user access or remote access to server via web shell or SSH. The attacker needs to carry out filesystem commands.
• You need a MySQL user with a low privileged account (CREATE/INSERT/SELECT grants).

Vulnerability Description

A race condition vulnerability has been discovered in the MySQL, MariaDB, and Percona databases. This vulnerability will allow a local attacker (remote access via a web shell or SSH connection) who has a low privileged account (CREATE/INSERT/SELECT grants) on the affected database to escalate their privileges and execute arbitrary code as the database system user. The main mechanism the attacker utilizes is the REPAIR TABLE statement. During REPAIR TABLE of a MyISAM table, a temporary data file (.TMD) is created. When repair finishes, this file is renamed to the original .MYD file. The stats from the old file are copied to the new file with chmod/chown.

If an attacker manages to replace the temporary file before chmod/chown was executed, it is possible to get an arbitrary file with the privileges of the MySQL user. Successful exploitation would allow the attacker to gain access to all databases stored on the server. It must also be noted that from thisstandpoint, the attacker could leverage the following vulnerabilities CVE-2016-6662 and CVE-2016-6664 to escalate their privileges to root user, which could lead to a total compromise of the victim’s server. 

Alert Logic Coverage

Alert Logic® has evaluated its customer base for exposure to the exploit and has developed signatures for mitigating the threat depending on the security service in place.

Detection of this threat is provided via the Alert Logic ActiveWatch™ for Log Manager™ service. Log messages are produced by the vulnerable system when an exploit of this type is leveraged. An incident will be generated in the Alert Logic console if these log messages are observed.

Recommendations for Mitigation

Upon discovery of a successful exploit, customers are expected to take reasonable action in accordance with their own standard operating procedures, such as:

• Isolate the compromised device from the network.
• Restrict access to the system to only trusted local users. If the attack was executed remotely, check the system for the attacker’s access point, such as vulnerability in web application allowing a web shell upload. This vulnerability will also need to be patched by a trusted source.
• Wipe and reinstall the device from secure media.
• Patch the vulnerability from a trusted source (or otherwise mitigate with FW, config, etc.).
• Replace data from backups.
• Test the device.
• Return the compromised device to the network and full operation.