5

I read the CVE-2015-3152 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3152) named BACKRONYM (http://backronym.fail/), and what I understood (ELI5 style) was the following:

  1. Attacker sniffs the network looking for packages from a MySQL client to a MySQL server.
  2. Attacker replies to MySQL client tricking it into think the MySQL server is replying "hey, I don't support SLL, send me thing in plain text please!".
  3. MySQL client resends the package, but now in plain text.
  4. Attacker is able to read your username password in plain text.

This basically means that I would only need to update the server which is the MySQL client and configure it to enforce SSL, is this conclusion right?

PS: Please assume I have 2 different servers on different networks and Server#1 has the MySQL master/server and the Server#2 has the MySQL slave/client which connects to Server#1 to query stuff. Also I would only care about fixing this vulnerability (so if updating the client fixes the issue, I'm fine).

Improve this question
4
  • Wow, what a confusing question. You are asking us about a MySQL client on a server connecting to a server running MySQL server and only the server should be updated right?
    – billc.cn
    Nov 10, 2015 at 16:09
  • @billc.cn only the server acting as MySQL client, yes.
    – Jhuliano Moreno
    Nov 10, 2015 at 18:36
  • Why suddenly a bounty?
    – Jesse K
    Nov 10, 2015 at 20:10
  • @JesseKeilson I want a more detailed answer for the question. So, why not :)?
    – Jhuliano Moreno
    Nov 11, 2015 at 3:43

2 Answers 2

Reset to default
2
+50

That's right, the issue lies in the database client, but you don't need to configure it. The problem is that when you tell it to connect using SSL, via "--ssl" or some other option that implies its usage, the client tries to use it, but will still try to connect via plaintext if the server tells it that it is not configured to use SSL. The fix just enforces the client to ONLY connect IF the server accepts the usage of SSL (when that "--ssl" or some other option that implies it is used).

Original advisory: oCERT

Improve this answer
2
  • That basically means that it would be a MITM attack. The attacker would have to be able to "spoof" the response an then the "MySQL client" would respond with plaintext message. Right?
    – Jhuliano Moreno
    Nov 10, 2015 at 18:40
  • Well, I think the advisory you provided makes it clear enough
    – Jhuliano Moreno
    Nov 10, 2015 at 18:45
0

A couple of points. First, you use "server" to mean both computer and provider of a backend service to which a client connects. This does not promote clear understanding of the question.

"This basically means that I would only need to update the server which is the MySQL client and configure it to enforce SSL, is this conclusion right?"

You may update the client software to version 5.7.3 or higher if you do not trust the backend server to consistently provide SSL OR if you want to be certain that SSL is being provided. If the backend server is properly configured, the older versions still prefer SSL when using the -ssl argument, so you should see no functional difference.

Improve this answer
9
  • You are right, it's kind of confusing. We may call them "mysql server" and "mysql client" or just master and slave for my purpose. Anyways! I don't think your answer is right, see the answer from DarkLighting and the source he provides. The vulnerability lies within the slave (or MySQL client), since an attacker can trick older MySQL versions into thinking that the master (or MySQL server) doesn't support SSL and that it should send the response again but in plain text.
    – Jhuliano Moreno
    Nov 11, 2015 at 3:12
  • Quoting from ocert.org/advisories/ocert-2015-003.html "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.", I think it's pretty clear that the -ssl argument won't fix the problem.
    – Jhuliano Moreno
    Nov 11, 2015 at 3:17
  • The severity of the vulnerability in your environment depends heavily on whether you control the client, the server, or both. If you control the server, but not the clients, you can enforce SSL. If you control the clients, but not the server, you CANNOT enforce SSL on versions prior to 5.7.3. This is the essence of the vulnerability. With 5.7.3 (or later), use of the ssl flag means that a connection to the server fails unless ssl is present.
    – Jesse K
    Nov 11, 2015 at 16:55
  • I control both server (in my case), but honestly looking into all the available sources I don't think you can enforce it since the vulnerabilitie lies within the client that doesn't follow the "--ssl" option (even if you force the client to use SSL it will respond with plain text if someone can do a MITM atack and spoof if). Could you provide some information backing up what you are saying?
    – Jhuliano Moreno
    Nov 11, 2015 at 19:38
  • Let me rephrase. The problem exists only on the mysql client. The mysql command line client has an option "-ssl". The expected behavior when using the "-ssl" option is that the mysql client will ONLY use SSL/TLS to connect to the mysql server. The vulnerability advisory states that this is not accurate, the "-ssl" option only requires that the mysql client TRY to use SSL/TLS. If it fails to connect this way to the mysql server, it will try again without encryption. If you control the mysql server, this vulnerability is not applicable, as you can require all clients to connect using SSL/TLS.
    – Jesse K
    Nov 11, 2015 at 21:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .