MySQL Vulnerability Allows Client to Send Data via Unencrypted Connection

[Karamjit]

Flaw is exploitable via man-in-the-middle attacks

A security flaw in Oracle MySQL 5.7.2 and lower allows an attacker acting as a proxy between the client and the server to access the database and retrieve information in plaintext, even if a secure connection is negotiated by the server.

The glitch lies in the fact that, while MySQL servers can be configured to require an encrypted connection, there is no option to enforce the same on the client, which then delivers the query results in the clear.

An attacker interposed between the two machines can thus communicate securely with the server but insecurely with the client and obtain the data.
Legacy behavior of the “-ssl” option

At the root of the problem is the legacy behavior of the client “-ssl” option, which can be enabled on the client, but cannot be made mandatory. As such, if the server is not configured to use the TLS (transport layer security) cryptographic communication protocol, the client obliges and sends the info.

In a man-in-the-middle attack, the threat actor can intercept the connection to the MySQL client and ask it during the initial handshake to deliver data over an unecrypted protocol, all the while respecting the request for TLS from the server.

Responsible for this behavior is the “libmysqlclient” library in MySQL. The vulnerability was uncovered by Duo Security researcher Adam Goodman of Duo Security, who dubbed it BACKRONYM (Bad Authentication Causes Kritical Risk Over Networks, Yikes MySQL).

Goodman says that Oracle is aware of this issue and released a fix, but it is available only in MySQL 5.7.3 and higher. On the same note, the developer rolled out version 6.1.3 of the standalone distribution of libmysqlclient, although it is not enabled by default, making the products that integrate it vulnerable.
Mitigating the risk

The recommendation from the security researcher is to adopt MySQL 5.7.3 or above, since the fix has not been backported to earlier versions.

A workaround is to configure the “REQUIRE X509 option,” which validates the identity of the recipient based on its SSL/TLS certificate, meaning that the client has to use TLS.

Goodman says that the vulnerability may not be “panic-worthy” for most MySQL users because an attacker needs to sit between the client and the server, and in most cases, the two reside on the same machine or next to each other.

However, disclosing the vulnerability (now identified as CVE-2015-3152) is part of an effort to draw attention to this problem and allow admins to take the necessary steps to eliminate this attack vector.

From: http://news.softpedia.com/news/MySQL-Vulnerability-Allows-Access-to-Plaintext-Information-in-the-Database-479943.shtml

[DLord]

"meaning that the client has to use TLS" which is not widely used!