Bug 1217506 (BACKRONYM, CVE-2015-3152) - CVE-2015-3152 mysql: use of SSL/TLS can not be enforced in mysql client library (oCERT-2015-003, BACKRONYM)
Summary: CVE-2015-3152 mysql: use of SSL/TLS can not be enforced in mysql client libra...
Keywords:
Status: NEW
Alias: BACKRONYM, CVE-2015-3152
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1217507 1217508
Blocks: 1217509
TreeView+ depends on / blocked
 
Reported: 2015-04-30 14:00 UTC by Martin Prpič
Modified: 2019-09-29 13:31 UTC (History)
32 users (show)

Fixed In Version: mysql 5.7.3, mariadb 5.5.44, mariadb 10.0.20
Doc Type: Bug Fix
Doc Text:
It was found that the MySQL client library permitted but did not require a client to use SSL/TLS when establishing a secure connection to a MySQL server using the "--ssl" option. A man-in-the-middle attacker could use this flaw to strip the SSL/TLS protection from a connection between a client and a server.
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:1646 normal SHIPPED_LIVE Important: rh-mariadb100-mariadb security update 2015-08-20 12:48:37 UTC
Red Hat Product Errata RHSA-2015:1647 normal SHIPPED_LIVE Moderate: mariadb55-mariadb security update 2015-08-20 13:17:49 UTC
Red Hat Product Errata RHSA-2015:1665 normal SHIPPED_LIVE Moderate: mariadb security update 2015-08-24 22:43:12 UTC

Description Martin Prpič 2015-04-30 14:00:51 UTC
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

Comment 1 Martin Prpič 2015-04-30 14:02:11 UTC
Created mariadb tracking bugs for this issue:

Affects: fedora-all [bug 1217508]

Comment 2 Martin Prpič 2015-04-30 14:02:15 UTC
Created community-mysql tracking bugs for this issue:

Affects: fedora-all [bug 1217507]

Comment 3 Tomas Hoger 2015-05-04 11:06:16 UTC
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/

Comment 4 Tomas Hoger 2015-05-04 11:11:10 UTC
MariaDB upstream bug:

https://mariadb.atlassian.net/browse/MDEV-7937

Comment 5 Honza Horak 2015-05-04 16:14:44 UTC
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?

Comment 6 Huzaifa S. Sidhpurwala 2015-05-12 10:03:15 UTC
(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!

Comment 7 Huzaifa S. Sidhpurwala 2015-05-15 09:00:38 UTC
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.

Comment 8 Fabio Olive Leite 2015-06-10 20:44:17 UTC
New upstream version is out with a fix:
https://mariadb.com/kb/en/mariadb/mariadb-5544-release-notes/

Comment 9 Tomas Hoger 2015-06-11 06:27:32 UTC
(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.

Comment 10 Tomas Hoger 2015-06-23 07:03:55 UTC
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/

Comment 11 Fedora Update System 2015-07-03 18:48:58 UTC
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.

Comment 12 Fedora Update System 2015-07-10 19:10:46 UTC
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.

Comment 13 errata-xmlrpc 2015-08-20 08:48:51 UTC
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

Comment 14 errata-xmlrpc 2015-08-20 09:18:33 UTC
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

Comment 15 errata-xmlrpc 2015-08-24 18:43:58 UTC
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

Comment 22 Tomas Hoger 2017-03-15 10:28:08 UTC
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.

Comment 23 Tomas Hoger 2017-03-17 12:53:06 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.