[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160331230016.AB0636FC041@smtpvmsrv1.mitre.org>
Date: Thu, 31 Mar 2016 19:00:16 -0400 (EDT)
From: cve-assign@...re.org
To: seth.arnold@...onical.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Clarification: Mysqlnd / CVE-2015-3152
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
> Tomas Hoger asked if CVE-2015-3152 is appropriate for re-use with the php
> mysqlnd interface:
No, the PHP ext/mysqlnd/mysqlnd.c code seems to be completely
unrelated to the code shown in the
https://github.com/mysql/mysql-server/commit/3bd5589e1a5a93f9c224badf983cd65c45215390
commit (and the code available from the
http://downloads.mysql.com/archives/c-c/?version=6.1.2&os=src web
page), and thus the CVE ID should be different. Use CVE-2015-8838 for
this https://bugs.php.net/bug.php?id=69669 issue.
Incidentally, there typically aren't CVE IDs for reports such as
"MySQL clients have long had a --ssl option. Casual users may think
specifying this option will cause clients to secure connections using
SSL. That is not the case ... This behavior is clearly explained in
the manual ... this option is not sufficient in itself to cause an SSL
connection to be used" in the
http://mysqlblog.fivefarmers.com/2014/04/02/redefining-ssl-option/
post. In other words, if the only problem were that the product
documented behavior that hardly anyone wants, and omitted behavior
that would be much more useful, then a CVE ID generally shouldn't
exist. This case was different because, as mentioned in the
https://duo.com/blog/backronym-mysql-vulnerability post, other
documentation stated "MYSQL_OPT_SSL_VERIFY_SERVER_CERT ... This
feature can be used to prevent man-in-the-middle attacks." This was
misleading because enabling the certificate-verification code didn't
prevent the man-in-the-middle attacker from using a
cleartext-downgrade attack. Also,
http://mysqlblog.fivefarmers.com/2015/04/29/ssltls-in-5-6-and-5-5-ocert-advisory/
is arguably a vendor confirmation that the behavior was a MySQL
vulnerability, even though it was not on an official vendor web site.
https://access.redhat.com/security/cve/cve-2015-3152 was posted by
the CNA for this CVE.
http://php.net/ChangeLog-5.php has the three vendor confirmations of
CVE-2015-8838 (the entries that mention bug #69669). We don't know
whether the unpatched mysqlnd.c code ever included misleading
documentation about the relationship between certificate verification
and man-in-the-middle protection, but that's not needed for a CVE
because of the obvious confirmation on the vendor's official site.
- --
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJW/atfAAoJEL54rhJi8gl5ByUQAM/xz719Q1AkdIdd/XOn4AVL
E3iePMjQLfVVU2HHZBBWAb5EWM7vxS52f4K7FOFmbfZ9+813qLh7S8dRpM61eqZZ
S9qXHmeUZazoWtN8D4j9nhGqKRHAc9k9Cl1g4+d1urV6aVtdSG+R4NsrEFGTKomu
Qoq2akYMFqBGVlb1kyPVYZS0Yy/WMntYTmQ0MXJQxwzFfXNtDCDMn8swOg5CkKzP
p/lj3f1EkUtJjdSytZhyCnzs9B5awCx3JkH/yBSdqo2ApfCaranjsia965pSv2Yd
xKyIwr3jeO3BfatV1cGgaHHrrSobMNVJ5os4TPw4ziif6UBx+36HsaHEgKLP++sW
Jx9j/565GbF1WH4iy0IV20qgPrSIGRx9h6AgmAWirw6iRrT9JM+5KEvFSDetNk/5
ctCSeWVLb9gT4ASW6EOGEzCLU2Zy3AXZWHhPcOqNmq+iKcEWoUOowIAL8XtHyMlZ
r6WwM+7Q5qsjP2hI+lI10qmCUPBw4KVsXurvKCasWC+BRSS8bkjJh2nnRfkELJwj
lN5bTnQ0gdmr7nxr2IcQfB2F4nXfBa2kW0mSXSCT26wVSlt/ycTd8M64p0WLeIpE
6xhpVxV7N9Pn6rhCqKjnqWGKWrOYPuD949DNqY6kQv6gd6eFWrHcikaKGtBfOjhY
wb6fxrb9zEfAcWpd+07+
=xHPT
-----END PGP SIGNATURE-----
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.
