Last week, a 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’s possible to launch Man In The Middle attacks (MITM). MITM attacks can capture the secure connection and turn it into an insecure one, 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. But, 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 done 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 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:
These connectors also support SSL connections to the database server and make use of the similar parameters etc. 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 does the right thing and aborts 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’s highly recommended that you restrict network access as much as possible with normal means, 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
Finally, since we’re in the middle of fixing the vulnerability in MariaDB, we appreciate your input regarding which versions of MariaDB that 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 do not require it. To enforce SSL, when the appropriate options are given, will change the behavior 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: http://info.mariadb.com/ssl-vulnerability-mysql-mariadb
The initial reports on the vulnerability can be found through these sources: