CVE-2016-6662 – Remote Root Code Execution / Privilege Escalation (0day exploit)
A new 0-day exploit has been announced for MySQL that can result in remote code execution or privilege escalation.
Apparently, this exploit was announced to Oracle, the owners of MySQL more than 40 days ago and a fix has not yet been released.
You can read about it in greater detail from these sources:
- http://www.techworm.net/2016/09/mysql-zero-day-allows-attacker-take-full-control-database.html
- https://threatpost.com/critical-mysql-vulnerability-disclosed/120486/
- http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html
This affects the following MySQL and MySQL “clones”: (excerpted from “LegalHackers.com”)
MySQL 5.7.15, 5.6.33 & 5.5.52 Remote Root Code Execution / Privilege Escalation (0day) MySQL "clones" are also affected, including: MariaDB PerconaDB
This exploit / bug works because if the malloc-lib configuration variable is set, the wrapper script mysqld_safe (which runs as root) will preload a user designated shared library before starting the server. Boom. Big problem.
Ways to mitigate CVE-2016-6662 risk in WHM / Cpanel: (Currently supported versions)
If you run WHM / cPanel – then you should take note of the following:
The defaults for cPanel should be configured to not allow this preload as far as this vulnerability is concerned. The default configurations do not allow the attackers access to the files needed unless they already have root access, which means they would already breached your server. You have larger problems at that point.
So, that means cPanel is not vulnerable by default unless you change permissions for mysql config files or unless you have some super mysql user with FILE perms.
Also, by default, your my.cnf files should be owned by root (user) and root (group) only.
cPanel is not vulnerable by default (unless you change permissions for mysql config files) unless you have some super mysql user with FILE perms.
For MySQL versions under 5.7 (5.5 and 5.6 respectively), mysqld_safe also checks /var/lib/mysql/my.cnf at startup. This means even if /etc/my.cnf (or another MySQL config file) is not writable by the mysql user, an attacker with access to a compromised MySQL user with SUPER or FILE permissions can create a new MySQL config file containing the malloc-lib=’/path/to/bad/lib’ configuration variable and successfully exploit the system.
You can view grants like so: (from command prompt)
SHOW GRANTS [FOR user]
Full explanation: MySQL :: MySQL 5.7 Reference Manual :: 14.7.5.21 SHOW GRANTS Syntax
So, again, check that your /etc/my.cnf has the correct ownership/permissions. No MySQL users created by cPanel should have SUPER or FILE permissions unless specifically set by a System Administrator since neither of these permissions can be granted through cPanel or any other method other than root access.
Additional protections and considerations:
- Shut down port 3306 (mysql) to the outside world. You should be running this localhost anyway. Shame on you.