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):

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:

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:

The initial reports on the vulnerability can be found through these sources:

I’m getting more and more concerned about the current Oracle approach to MySQL security. And the fact that I was solely responsible for the for about ten years, doesn’t make it easier, on the contrary, it only emphasizes changes in the attitude.

Starting from the obvious — somewhat slower response to critical bug fixes, which can be expected, Oracle is a big company, right? Very little information about security vulnerabilities is disclosed, CPUs are carefully stripped from anything that might help to understand the problem, it takes hours to map them to code changes. Heck, even test cases are kept private now. This seriously smells Security through Obscurity to me.

But all that isn’t news. Here I want to talk about the recent wave of security vulnerabilities. If you search for, say, “mysql security full-disclosure”, you will find the original postings to the mailing list, as well as further discussion and my replies. Not Oracle replies, though. In short, the vulnerabilities  announced in the early December were:

  1. CVE-2012-5611 MySQL (Linux) Stack based buffer overrun PoC Zeroday
  2. CVE-2012-5612 MySQL (Linux) Heap Based Overrun PoC Zeroday
  3. CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday
  4. CVE-2012-5614 MySQL Denial of Service Zeroday PoC
  5. CVE-2012-5615 MySQL Remote Preauth User Enumeration Zeroday
  6. CVE-2012-5627 MySQL Local/Remote FAST Account Password Cracking

All posted to the full disclosure mailing list, accompanied by exploits in Perl. Out of these issues, the 3rd was a configuration issue (FILE privilege granted to untrusted user, no --secure-file-priv used), 4th was already fixed in the latest MariaDB and MySQL releases (the reporter used an outdated MySQL version), 1st — the most dangerous one — was already fixed in the latest MariaDB release (we were lucky to discover this issue independently few weeks ealier and immediately released a fix). Everything else was valid, exploitable, and very much public, after the original postings were quoted in various blogs and news articles.

In a due time MySQL 5.5.29 is released. The 1st issue — CVE-2012-5611 — looks fixed. The second one — CVE-2012-5612 — is fixed too. Hurra! But 5th and 6th vulnerabilities — CVE-2012-5615 and CVE-2012-5627  — are not fixed. Which, apparently, leaves MySQL installations at the mercy of any script-kiddie, who can use google. And the 1st one (the worst of all) is fixed incompletely — the fact, that is simply impossible to miss, given the amount of testing that MySQL continuous integration framework (Pushbuild2) is performing.

Really, I wouldn’t expect a database vendor to blatantly ignore publicly announced vulnerabilities, that have CVE identifiers, known and easily available exploits, and were posted and reposted all over. So, Oracle, what was that, eh?

2013/Feb/05 UPDATE: MySQL 5.5.30 doesn’t seem to fix these issues either. Two months after the vulnerabilities went public. After MariaDB 5.5.29 release (with the fixes) and this blog post! I don’t think the Hanlon’s razor can explain that.

In this primer I will show how to improve the security of your MariaDB installation by using two-step verification and how to use it from your Windows GUI client.

Let’s suppose you have your data in MariaDB, installed, say, on Ubuntu. And your users connect to it to run ad hoc queries, using some sort of a Windows GUI client. You don’t want them to write the access password on post-it notes or have it auto-entered by the client. And you don’t want anyone see the password when one of the salespersons connects to the mother ship from his laptop in the Internet café. So you decide to use the two-step verification, just like Google does, to secure the access to the data.

Continue reading