[<prev] [next>] [day] [month] [year] [list]
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.
