Protect against MySQL vulnerability CVE-2016-6662

by Pythian Marketing on Sep 13, 2016 12:00:00 AM

Overview

On September 12, 2016, a security vulnerability affecting all current versions of MySQL and its various vendors: Oracle, Percona Server, and MariaDB. The vulnerability, numbered CVE-2016-6662, allows an attacker to override the MySQL config file with various settings for the next time MySQL is restarted. If an attacker can load custom code on the server, it is possible for MySQL to load that code as a shared dynamic library by utilizing the --malloc-lib option in the mysqld_safe script. The attack vector requires several pieces to be in place:

Config files must be writeable by the MySQL User.
The attacker must be able to inject code in the config files MySQL reads at startup by overwriting the the location of the general_log.
To run custom code, the script that manages the mysqld process must allow loading dynamic libraries. Specifically, this is the --malloc-lib option allowed by mysqld_safe.

The CVE gives this example for overriding the general_log: [code type="sql"] mysql> set global general_log_file = '/etc/my.cnf'; mysql> set global general_log = on; mysql> select ' '> '> ; injected config entry '> '> [mysqld] '> malloc_lib=/tmp/mysql_exploit_lib.so '> '> [separator] '> '> '; 1 row in set (0.00 sec) mysql> set global general_log = off; [/code]

Secure your application against SQL Injection

This vulnerability really only has merit to attackers that have remote or local access directly to your MySQL server, or through SQL Injection in the application. You can follow the recommended steps at the end of our post on SQL Injection to harden against such attacks.

Does this vulnerability affect AWS RDS?

Some are wondering if this vulnerability affects any flavor of Amazon's RDS. In general, the attack relies on the ability to enable the general_log file to inject configuration text into a file MySQL recognizes as a config file. But RDS removes the ability to set global variables by users, requiring changes to be made via parameter groups. The general_log_file parameter is not modifiable.

A word of caution

While CVE-2016-6662 specifically targets MySQL-writeable configuration files and the ability to create files on the server with FILE permissions, the author provides a word of caution that implies there will be additional requirements to protect against this type of attack:

# Full PoC will be released at a later date, and will show how attackers could # exploit the vulnerability on default installations of MySQL on systems with no # writable my.cnf config files available. # # The upcoming advisory CVE-2016-6663 will also make the exploitation trivial # for certain low-privileged attackers that do not have FILE privilege.

Conclusion

All of the MySQL Vendors have patched against the ability to modify the general_log to a config file, as well as updating the mysqld_safe to prevent loading shared libraries except from certain directories that MySQL typically does not have write access to. Examples are /usr/lib and /usr/lib64. If upgrading to these versions is not an option, the attack can be mitigated by ensuring your my.cnf files are not writeable by MySQL user. Also, if you have no config file in the normal places MySQL looks for a config file, you should create empty files that are owned by 'root', and not by the MySQL user. The various configuration locations differ from MySQL version and OS distribution. For example, check the MySQL 5.7 documentation on option files. You should also ensure that your application is secure from SQL Injection by following some recommended best-practices. If you happen to run RDS, this particular vulnerability is mitigated by the security features RDS imposes on the database users such as the inability to set global variables and the use of Parameter Groups.

No Comments Yet

Let us know what you think

See all

Share this