It was found that MySQL client when specified to use SSL/TLS mode is authenticating to MySQL server not supporting SSL/TLS, client will fallback to plain text protocol used for authentication. After successful authentication client checks if SSL/TLS layer is required and if server doesn't support it, client will close the connection with error. Active MITM attacker can downgrade SSL/TLS to plain text and forward nonce from server back to client. MITM attacker receive login data (for server nonce) from client and send it to server to authenticate as client. This issue is present in libmysqlclient.so in 5.5 and 5.6 versions.
Acknowledgments: Name: Pali Rohár
I think this is better described as incorrect implementation or enforcement of ssl-mode=REQUIRED in MySQL 5.5 and 5.6. Support for that option was added in versions 5.5.49 and 5.6.30 in response to the CVE-2015-3152 issues, which is also known as BACKRONYM. See bug 1217506 comment 22 for details. As noted in the upstream release notes referenced from the comment linked above, upstream used different implementation from what was previously available in 5.7 versions. Because of binary compatibility concerns with previous 5.5 and 5.6 versions, they did not add support for setting the MYSQL_OPT_SSL_MODE option using the mysql_options() C API function and enforcing the requirement in early phases of the connection handshake. Instead, the implementation in 5.5 and 5.6 establishes connection and only checks afterwards if the use of SSL was negotiated or not. That check happens after authentication. As MySQL uses a challenge-response authentication scheme: https://dev.mysql.com/doc/internals/en/secure-password-authentication.html and hence does not send passwords over the wire, the late check was apparently not considered a problem. However, as noted by the reporter of this issue, this still allows MITM attacker to make client compute correct response and hence hijack client's authentication to the server. Note that this issue is not really relevant to the libmysqlclient, as the ssl-mode=REQUIRED support was only implemented in the tools included with MySQL and is not available to other applications using the library.
The original decision to not provide support for the MYSQL_OPT_SSL_MODE option in MySQL 5.5 and 5.6 was apparently revised recently, likely in response to the report of this issue. It is now documented as valid option that can be passed to the mysql_options() function: https://dev.mysql.com/doc/refman/5.6/en/mysql-options.html https://dev.mysql.com/doc/refman/5.5/en/mysql-options.html MYSQL_OPT_SSL_MODE (argument type: unsigned int *) The security state to use for the connection to the server. The only permitted arument value is SSL_MODE_REQUIRED (require a secure connection). If set, this option causes mysql_real_connect() to fail if an encrypted connection cannot be obtained, without falling back to an unencrypted connection. Thus, mysql_real_connect() returns an error if the server does not support SSL or the client is not configured to use SSL. For more information about the security states, see the description of --ssl-mode in Section 6.4.5, “Command Options for Secure Connections”. To require an encrypted connection in MySQL 5.6, the standard MySQL client programs call mysql_options() to set MYSQL_OPT_SSL_MODE if the --ssl-mode=REQUIRED command-line option was specified. Third-party applications that must be able to require encrypted connections can use the same technique. For details, see Section 23.8.7.68, “mysql_ssl_set()”. This option was added in MySQL 5.6.36. or This option was added in MySQL 5.5.55. Note that versions 5.5.55 and 5.6.36 have not been released yet.
This issue is not relevant to MariaDB, which used different approach to address the BACKRONYM issue, see bug 1217506 comment 9.
Public now via original reporter's advisory. External References: http://riddle.link/
(In reply to Tomas Hoger from comment #3) > Note that versions 5.5.55 and 5.6.36 have not been released yet. Those versions are now available fixing this issue. Related info in the release notes: The mysql_options() C API function now supports a MYSQL_OPT_SSL_MODE option. The only permitted option value is SSL_MODE_REQUIRED, to require a secure connection to the server. It causes mysql_real_connect() to fail if an encrypted connection cannot be obtained, without falling back to an unencrypted connection. Thus, mysql_real_connect() returns an error if the server does not support SSL or the client is not configured to use SSL. The client/server exchange terminates immediately after the initial server packet has been received if the server indicates that it does not support SSL. To require an encrypted connection in MySQL 5.6, the standard MySQL client programs call mysql_options() to set MYSQL_OPT_SSL_MODE if the --ssl-mode=REQUIRED command-line option was specified. Third-party applications that must be able to require encrypted connections can use the same technique. For details, see mysql_ssl_set(). The minor C API version number was not incremented for this change. Application programs compiled for MySQL 5.6 that require MYSQL_OPT_SSL_MODE may fail to operate properly if the dynamic loader provides an older client library without MYSQL_OPT_SSL_MODE. Such applications must be written to handle this possibility by checking whether the mysql_options() call succeeds or fails. (Bug #25575605) https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-36.html#mysqld-5-6-36-security https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-55.html#mysqld-5-5-55-security Upstream commits: 5.6: https://github.com/mysql/mysql-server/commit/0002e1380d5f8c113b6bce91f2cf3f75136fd7c7 5.5: https://github.com/mysql/mysql-server/commit/060b1eadf4913f7066484ea34ec62feead1bca44 https://github.com/mysql/mysql-server/commit/87e37ee06b32dda19f8c17a888586dd03191eeec
This is now also listed in the Oracle April 2017 CPU: http://www.oracle.com/technetwork/security-advisory/cpuapr2017-3236618.html#AppendixMSQL
Oracle April 2017 CPU was updated to list 5.5.55 version as affected, even though it was previously listed as fixed. Looking at the release notes trying to find out why the change was made, the following is the only change documented for 5.5.56: https://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-56.html Binary packages for MySQL 5.5.56 are identical to those for MySQL 5.5.55, except for the version number. The change in 5.5.56 for Bug #25942414 is applicable only to those who build from source. Security Notes For the WITH_SSL CMake option, no is no longer a permitted value or the default value. The default is now bundled. Consequently, MySQL now is always built with SSL support. (Bug #25942414) The relevant commit is: https://github.com/mysql/mysql-server/commit/ad88f2a7b5c5827cb1ba78eee3497fb851b37a9f Apparently, when mysql client libraries were built without SSL support, various --ssl-* options were ignored silently and hence SSL was not used even when requested. While symptoms are similar to those of this issue, that change should have been treated as a separate flaw with a separate CVE. Re-use of this CVE for the additional change is incorrect.
The additional issue noted in comment 13 was reported by the same reporter as the CVE-2017-3305 / Riddle issue, and got named "Again Riddle": http://again.riddle.link/
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.3 EUS Via RHSA-2017:2787 https://access.redhat.com/errata/RHSA-2017:2787