MySQL 5.5, MariaDB 5.5 and 10.3 have a vulnerability in the client library that does not enforce the use of SSL/TLS. Client applications that specify the use of SSL/TLS can result in established connections without SSL/TLS enabled and no reported error.
This is the result of an incomplete fix for CVE-2015-3152 (a.k.a BACKRONYM).
Created community-mysql tracking bugs for this issue:
Affects: fedora-all [bug 1564967]
Created mariadb tracking bugs for this issue:
Affects: fedora-all [bug 1564966]
In reply to comment 0:
> MySQL 5.5, MariaDB 5.5 and 10.3 have a vulnerability in the client library
> that does not enforce the use of SSL/TLS.
Term "client library" is misleading here, as it would normally be used to refer to the libmysqlclient library. However, this problem affects libmysqld - a library that can be used to embed MySQL server into other applications. Such application, if only linked against libmysqld, can still open client connections to other MySQL servers using the MySQL client library code in libmysqld. The problem is that such connections are silently established without TLS/SSL, even though application requested the library to establish TLS/SSL connection.
Note that it's apparently possible to link an application to both libmysqlclient and libmysqld. In that case, code from one of the libraries will be used, and the application may or may not be affected depending on the linking order.
This issue did not affect MySQL and MariaDB packages in Red Hat Software Collections or Red Hat OpenStack Platform, as they do not provide libmysqld (and libmysqlclient).
MariaDB addressed this problem in versions 5.5.60, 10.0.35, 10.1.33, 10.2.15, and 10.3.7 via the following commit:
The check is documented via the following entry in the release notes:
The embedded server library now supports SSL when connecting to
Note that even after the above fix TLS/SSL client support in MariaDB's libmysql remains buggy, as there are other code parts that remain inside "#if defined(HAVE_OPENSSL) && !defined(EMBEDDED_LIBRARY)" and hence is not compiled in when building libmysqld. One example is mysql_ssl_set() function:
which is also used to specify CA certificate for server certificate verification. Hence server certificate can only be verified if it was issued by a CA that is trusted by the system CA certificate store.
This problem is not reproducible with MySQL 5.1 as shipped with Red Hat Enterprise Linux 6. Client connections using both libmysqlclient and libmysqld behave the same. It may have been introduced in MySQL version 5.5.5 when many "#ifdef HAVE_OPENSSL" to "#if defined(HAVE_OPENSSL) && !defined(EMBEDDED_LIBRARY)".
Note that the original BACKRONYM / CVE-2015-3152 issue has no been addressed in MySQL 5.1 in Red Hat Enterprise Linux 6, only in MySQL 5.5 (mysql-55-mysql) packages.
This issue is now listed as addressed via Oracle CPU July 2018:
It should be addressed in MySQL versions 5.5.61, 5.6.41, and 5.7.23. However, even though the above advisory was published few days ago, fixed MySQL versions have not been released yet.
MySQL upstream fix:
This modifies the MySQL client code in libmysqld to fail connection attempt with an error if SSL is requested.
Matching release notes entry:
An unencrypted connection could result from a client connection attempt
specifying that an encrypted connection was required, if the server was
not configured to support SSL. (Bug #27759871)
It does not explain how the problem was addressed.
This issue has been addressed in the following products:
Red Hat Enterprise Linux 7
Via RHSA-2018:2439 https://access.redhat.com/errata/RHSA-2018:2439