|
Message-ID: <20180408122107.dftnkqrrgfuz3w2h@pali> Date: Sun, 8 Apr 2018 14:21:07 +0200 From: Pali Rohár <pali.rohar@...il.com> To: oss-security@...ts.openwall.com, security@...iadb.org, Percona Security Team <security@...cona.com>, Oracle Security Alerts <secalert_us@...cle.com>, labs@...security.com Subject: CVE-2018-2767: MySQL & MariaDB: Return of the BACKRONYM vulnerability (public disclosure) Hello, at the first let me remind you The BACKRONYM and The Riddle vulnerabilities in MySQL and MariaDB database client software. http://backronym.fail/ The BACKRONYM vulnerability was discovered in 2015 by Duo Labs and cause that any mandatory encryption and requirement of usage SSL encryption by client software which uses MySQL/MariaDB client is only opportunistic. When server does not support SSL/TLS then client fallback to plain text non-encrypted connection without any notice. Therefore fully vulnerable to the downgrade attack. http://riddle.link/ Later in 2017 I discovered that fix for BACKRONYM in MySQL 5.5 by Oracle introduced another vulnerability: The Riddle. Oracle fixed BACKRONYM by adding a new check that SSL/TLS encryption is active -- but this check was done *after* authentication phase. Therefore vulnerable to reply attack (thanks to insecure scheme "Secure Password Authentication"). http://again.riddle.link/ After Oracle released a version of MySQL which claimed to fix The Riddle vulnerability I immediately discovered that it is not truth and problem was still there... After that Oracle again released a new version with next attempt of fix. So... do you think that problems with The BACKRONYM and the Riddle vulnerabilities were fixed after third attempt? No, I discovered that BACKRONYM is still present. The Riddle vulnerability uses the weaknesses of the MySQL auth protocol. https://dev.mysql.com/doc/internals/en/secure-password-authentication.html "MySQL Secure Password Authentication" is not secure at all. I already described it in The Riddle page, usage of SCRAM cryptographic scheme instead could prevent this problem. We would see in future if "MySQL Secure Password Authentication" is going to be changed or this "secure" scheme allows us to break authentication again. I discovered that BACKRONYM vulnerability is still present in the last version of the MySQL 5.7 series, MariaDB 5.5 and 10.3 series when client application which enforces SSL/TLS is linked with libmysqld (library which supports embedded server, but also connecting to the regular database server via TCP). Probably other series are affected too, I have not tested them. MySQL 5.7 client connects to server even when SSL is unsupported. MariaDB 10.3 client does not connect to server when SSL is unsupported, but it connects without establishing SSL tunel when SSL is supported by server. This behavior is really strange! In attachment is simple program written in C which can demonstrate this problem. It sets mysql client options to enforce SSL, then connect to database server and outputs value of "Ssl_cipher" variable. "Ssl_cipher" indicates which cipher was used for encryption, empty string when SSL was not established. Compile it with libmysqld and see results. $ cc -o a.out ssl-test.c `mysql_config --cflags --libmysqld-libs` -lstdc++ $ ./a.out 127.0.0.1 3306 "" "user" "pass" "/path/to/ca" It should either print error message that connection cannot be established due to server does not support SSL encryption. Or it should print Ssl_cipher with valid non-empty cipher when connection is really encrypted. On tested versions it shows that encryption is not used. If you are unsure, just open wireshark and watch network communication. These details were reported to MariaDB, Oracle and Percona security teams in 2018-03-25. After discussion Oracle sent to other teams CVE-2018-2767 identifier for this issue and 2018-04-08 was chosen for public disclosure. Should not be 3 years enough for fixing BACKRONYM? So... would be BACKRONYM finally fixed? :-) Or can we expect in next months another new vulnerability which is going to be introduced with the fix for this one by Oracle team? PS: In past I had very bad experience with Oracle, they fully ignored previous reports, did not want to communicate with me and they tried to remove and hide all details about The Riddle Vulnerability (also from MITRE). Therefore I'm longer not doing any discussion with Oracle and I suggest you to do same (I was very polite that for now I sent them at least details before disclosure). -- Pali Rohár pali.rohar@...il.com View attachment "ssl-test.c" of type "text/x-csrc" (2507 bytes) Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.