oCERT released the following advisory regarding MySQL: A vulnerability has been reported concerning the impossibility for MySQL users (with any major stable version) to enforce an effective SSL/TLS connection that would be immune from man-in-the-middle (MITM) attacks performing a malicious downgrade. While the issue has been addressed in MySQL preview release 5.7.3 in December 2013, it is perceived that the majority of MySQL users are not aware of this limitation and that the issue should be treated as a vulnerability. The vulnerability lies within the behaviour of the '--ssl' client option, which on affected versions it is being treated as "advisory". Therefore while the option would attempt an SSL/TLS connection to be initiated towards a server, it would not actually require it. This allows a MITM attack to transparently "strip" the SSL/TLS protection. The issue affects the ssl client option whether used directly or triggered automatically by the use of other ssl options ('--ssl-xxx') that imply '--ssl'. Such behavior is clearly indicated in MySQL reference manual as follows: 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. In a similar manner to the new '--ssl' option behaviour, users of the MySQL client library (Connector/C, libmysqlclient), as of MySQL 5.7.3, can take advantage of the MYSQL_OPT_SSL_ENFORCE option to enforce SSL/TLS connections. The vulnerability also affects the MySQL forks MariaDB and Percona Server, as the relevant 5.7.3 patch has not been pulled, at the time of this advisory, in their respective stable versions. Upstream patch: https://github.com/mysql/mysql-server/commit/3bd5589e1a5a93f9c224badf983cd65c45215390 MySQL 5.7.3 release notes describing the change: http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-3.html External References: http://www.ocert.org/advisories/ocert-2015-003.html
Created mariadb tracking bugs for this issue: Affects: fedora-all [bug 1217508]
Created community-mysql tracking bugs for this issue: Affects: fedora-all [bug 1217507]
Blog post from the original reporter: https://www.duosecurity.com/blog/backronym-mysql-vulnerability This issue was given a name BACKRONYM. A page created for the issue (with lots of sarcasm): http://backronym.fail/ Reporter's public MITM exploit that strips SSL from MySQL connections: https://github.com/duo-labs/mysslstrip Related blog posts from Todd Farmer of Oracle, who is the security lead for MySQL products: http://mysqlblog.fivefarmers.com/2014/04/02/redefining-ssl-option/ http://mysqlblog.fivefarmers.com/2015/04/29/ssltls-in-5-6-and-5-5-ocert-advisory/
MariaDB upstream bug: https://mariadb.atlassian.net/browse/MDEV-7937
It is not easy to figure out what the best fix should be, since pure backporting the 5.7 patch is changing the behavior that has been documented for years. More information in the blog post and comments: http://mysqlblog.fivefarmers.com/2015/04/29/ssltls-in-5-6-and-5-5-ocert-advisory/ We should wait for what the upstream picks as the solution and use the same approach -- but it is not possible to say when it will be decided. Are we fine with waiting for upstream fix with this particular issue?
(In reply to Honza Horak from comment #5) > It is not easy to figure out what the best fix should be, since pure > backporting the 5.7 patch is changing the behavior that has been documented > for years. More information in the blog post and comments: > http://mysqlblog.fivefarmers.com/2015/04/29/ssltls-in-5-6-and-5-5-ocert- > advisory/ > > We should wait for what the upstream picks as the solution and use the same > approach -- but it is not possible to say when it will be decided. Are we > fine with waiting for upstream fix with this particular issue? Absolutely, I dont think we have much of a choice here!
Statement: This issue affects all versions of mysql and mariadb as shipped with Red Hat Enterprise Linux 5, 6 and 7. Red Hat Product Security has rated this issue as having Moderate security impact and are currently awaiting upstream patch to resolve this flaw.
New upstream version is out with a fix: https://mariadb.com/kb/en/mariadb/mariadb-5544-release-notes/
(In reply to Fabio Olive Leite from comment #8) > New upstream version is out with a fix: > https://mariadb.com/kb/en/mariadb/mariadb-5544-release-notes/ Related MariaDB commits in 5.5.44: https://github.com/MariaDB/server/commit/4ef7497 https://github.com/MariaDB/server/commit/5a44e1a These indicate that availability of SSL is only enforced when using --ssl-verify-server-cert / MYSQL_OPT_SSL_VERIFY_SERVER_CERT option is used. This option is disabled by default, so only --ssl option will not enforce SSL.
In addition to fix in mariadb 5.5.44 (see comment 8 and comment 9 above), this was also fixed in mariadb 10.0.20: https://mariadb.com/kb/en/mariadb/mariadb-10020-release-notes/
mariadb-10.0.20-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
mariadb-10.0.20-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.5 EUS Via RHSA-2015:1646 https://rhn.redhat.com/errata/RHSA-2015-1646.html
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.5 EUS Via RHSA-2015:1647 https://rhn.redhat.com/errata/RHSA-2015-1647.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:1665 https://rhn.redhat.com/errata/RHSA-2015-1665.html
This issue was mitigated in MySQL versions 5.5.49 and 5.6.30. Quoting from the upstream release notes: https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-49.html https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-30.html MySQL client programs now support an --ssl-mode option that enables you to specify the security state of the connection to the server. If the option is not specified, the default value is DISABLED (establish an unencrypted connection). --ssl-mode=REQUIRED can be specified to require a secure connection, or fail if a secure connection cannot be obtained. These clients support --ssl-mode: mysql, mysqladmin, mysqlcheck, mysqldump, mysqlimport, mysqlshow, mysqlpump, mysqlslap, mysqltest, mysql_upgrade. For more information, see Command Options for Secure Connections. Note In MySQL 5.7 and higher, the C client library provides native support for requiring encrypted connections: call the mysql_options() C API function, passing the MYSQL_OPT_SSL_MODE option with a value of SSL_MODE_REQUIRED. In MySQL 5.6, the client library provides no such support because doing so would break binary compatibility with previous library versions within the series. Clients that require encrypted connections must implement the logic themselves. To require encrypted connections in MySQL 5.6, the standard MySQL client programs use this technique: If --ssl-mode=REQUIRED was specified, the client program turns on SSL, connects to the server, and checks whether the resulting connection is encrypted. If not, the client exits with an error. Third-party applications that must be able to require encrypted connections can use the same technique. For details, see mysql_ssl_set(). Upstream commit: https://github.com/mysql/mysql-server/commit/b3e9211e48a3fb586e88b0270a175d2348935424 This fix is limited in two ways: - It only applies to the client tools shipped with MySQL and does not address the problem for other programs using the libmysqlclient library. - To take advantage of the fix, relevant tools need to be invoked with the new --ssl-mode=REQUIRED option specified, either on command line or in my.cnf. Note that a setting in my.cnf would force the use of SSL for all connections, regardless of whether --ssl command line option is used, so may not be usable where both SSL and non-SSL connections need to be made.
(In reply to Tomas Hoger from comment #22) > This issue was mitigated in MySQL versions 5.5.49 and 5.6.30. Additionally, the fix applied in version 5.5.49 and 5.6.30 was found to be incorrect, as it still allowed authentication to happen over non-encrypted connection even when ssl-mode=REQUIRED was used. See CVE-2017-3305 (bug 1431690) that was named The Riddle.
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2015-3152