How to fix CVE-2016-6662 on cPanel / WHM

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:

This affects the following MySQL and MySQL “clones”: (excerpted from “LegalHackers.com”)

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.

To exploit the vulnerability you first have to have a compromised MySQL user with SUPER or FILE privileges. Then you need to have a vulnerable my.cnf config file that the hacker can write to. THEN the SUPER privilege would allow the attacker to enable logging and THEN point the log file to a MySQL configuration file (my.cnf) that MySQL can write to, and THEN the attacker could inject the malloc-lib variable setting via MySQL. THEN, the FILE privilege allows a user (remember our compromised MySQL user above) that lacks the SUPER privilege to manipulate the new global log settings by writing a trigger file for an active table and therefore bypassing the need for the SUPER privilege.

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.

Want to discuss a project?

  • This field is for validation purposes and should be left unchanged.