Last week, an SSL connection security vulnerability was reported for MySQL and MariaDB. The vulnerability states that since MariaDB and MySQL do not enforce SSL when SSL support is enabled, it is possible to launch Man In The Middle (MITM) attacks. MITM attacks can capture the secure connection and turn it into an unsecure connection, revealing data going back and forth to the server.
Issue resolution in MariaDB is visible through the corresponding ticket in MariaDB’s tracking system (JIRA): https://mariadb.atlassian.net/browse/MDEV-7937
The vulnerability affects the client library of the database server in both MariaDB and MySQL. However, the vulnerability does not affect all the libraries, drivers or connectors for establishing SSL connections with the server.
The vulnerability exists when the connection to the server is made through the client library libmysqlclient. This client library is provided with the database server and is a fork of the corresponding client library in MySQL. The client library is used by what is probably the most-used tool, the MySQL Command-Line tool, of which a forked version is shipped with MariaDB.
In addition to libmysqlclient, the MariaDB project provides the following connectors:
- MariaDB Connector/C, https://mariadb.com/kb/en/mariadb/mariadb-connector-c/
- MariaDB Connector/J (Java Client), https://mariadb.com/kb/en/mariadb/about-the-mariadb-java-client/
- MariaDB Connector/ODBC, https://mariadb.com/kb/en/mariadb/mariadb-connector-odbc/
These connectors also support SSL connections to the database server and make use of similar parameters to establish secure connections. Here is an update on whether the connectors are affected or not:
- Affected – MariaDB Connector/C is vulnerable in the same way as libmysqlclient
- Not affected – MariaDB Connector/J works properly, aborting any unsecure connections if SSL is in use
- Not affected – MariaDB Connector/ODBC does not currently support SSL
For MySQL’s Connector/J, it is worth mentioning that it has two properties: “useSSL” and “requireSSL”. If “requireSSL” is selected, then unsecure connections are aborted.
Many of the tools that are used to connect to MariaDB or MySQL make use of libmysqlclient. Thus, when using these tools over an untrusted network, it is highly recommended that you use best practices to restrict network access as much as possible, even if you’re using SSL to connect to MariaDB or MySQL. Some best practices that are easy to put in place for decreasing the risk of MITM attacks include:
- MAC address filtering
- IP filtering
- Setting up a VPN connection between the client and the server
Disabling remote connections to the server and setting up MySQL port forwarding over an SSH tunnel.
Finally, since we are in the middle of fixing the vulnerability in MariaDB, we appreciate your input regarding which versions of MariaDB should get the fix backported. For background, the SSL support in MySQL (up until 5.7) and MariaDB is not enforceable. This is the intended MySQL behavior, implemented back in 2000, and clearly documented in the MySQL reference manual as:
“For the server, this option specifies that the server permits but does not require SSL connections.
For a client program, this option permits but does not require the client to connect to the server using SSL. Therefore, this option is not sufficient in itself to cause an SSL connection to be used. For example, if you specify this option for a client program but the server has not been configured to permit SSL connections, an unencrypted connection is used.”
MariaDB 5.5 and 10.0 are stable versions and behave as documented — they permit SSL, but they do not require it. Enforcing SSL, when the appropriate options are given, will change the behavior of, and might break, existing applications where a mix of SSL and non-SSL connections are used. In MariaDB 10.1 this is not a problem since MariaDB 10.1 is still in beta, although it is very close to release candidate status. There we will introduce the fix. As for MariaDB 5.5 and 10.0, we are collecting input to determine whether we should change the behavior of 5.5 and 10.0. Please visit our website for more details, and share your feedback at here.
The initial reports on the vulnerability can be found through these sources:
- A good report with more information on the vulnerability is provided through oCERT: http://www.ocert.org/advisories/ocert-2015-003.html
- The official CVE report: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3152