|
Message-Id: <20150907154401.164E26C000F@smtpvmsrv1.mitre.org> Date: Mon, 7 Sep 2015 11:44:01 -0400 (EDT) From: cve-assign@...re.org To: fweimer@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: nss: SSL_ImplementedCiphers ABI incompatibility may lead to incorrect cipher suites -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Yes, in general, a Linux distributor can be assigned a CVE ID if there is an unsatisfied ABI guarantee that results in weaker-than-intended security in a supported use case. We think you mean something like: Because of the ABI guarantee, a customer who has an NSS-based application can upgrade from RHEL 7.0 to fully patched 7.1, and feel confident that the security level provided by NSS will reflect the current security level offered by the 7.1 NSS packages. The customer does not need to touch their application in any way to make this happen. We didn't research what specific NSS upstream code is used in 7.0 versus 7.1, but as an example it looks like NSS 3.20 has 70 cipher suites whereas NSS 3.13 has 56 cipher suites. A direct truncation would apparently cut off at TLS_RSA_EXPORT_WITH_RC4_40_MD5 and not enable the next one (TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5) or any of the later ones. Is this an example of the security impact: The customer's application is a client that communicates with a server that only supports TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5, and no other cipher suite. The application is designed to fall back to no TLS if there is no mutually agreeable cipher suite. Under RHEL 7.0, the customer was happy: the security level was exactly the maximum security level available for that server. When the customer upgraded, they became sad because TLS was no longer used at all. ? (This type of example, if valid, is enough to assign a CVE ID.) (We realize that this isn't a great example. A better example would have forced the unavailability of an arguably "safe" cipher suite that had previously been used. Or, possibly, a better example would have caused the customer's application to fail to pick up a new and highly recommended cipher suite that exists only in newer NSS upstream code.) Is this also a security impact: The applicable NSS code begins with const PRUint16 SSL_ImplementedCiphers[] = { and ends with SSL_EN_RC2_128_CBC_EXPORT40_WITH_MD5, 0 }; in both cases. If SSL_ImplementedCiphers is truncated, then the "0" at the end is lost. In some or all cases, possibly depending on the machine architecture or compiler, this can result in a different type of unwanted behavior for an NSS-based application, such as an out-of-bounds read and application crash caused by a malicious TLS endpoint that intentionally has no mutually agreeable cipher suites. ? Or, is there simply no supported way in which any NSS-based application could have relied on the "0" at the end? - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV7a/PAAoJEL54rhJi8gl5+PkP/3yOcsgTLlwNNdEiZt+/HJ6B IorQawTQqXyb22OJ/PhIrEZXOsW5ChphFcQ+deFLTNRAPliiUZonvt9/ArLE/Cis 4YHETcEVanYpNU+707I8hQjrGGkrO0hvQf9B0zB/8tEPO9i0pLDwugaUNOboPm7p 8MT8aD1KV4mgbGYDeJBt4ce76smhsWLdGwA02lUk6VzvxSkn8wRShLEFXi/5SXPb AscLzWXH5pYBkOUXV0tJTeZS96e1Bs2YkmvXhoR8hbgfPjtuwdM2l8Dp43HJtBu/ Eha1EsRS6eVE+HKMF4QnJ5d1M3KbUNG7Urhk/ugHGCq9bFhRh+jm7TVTza2TJ3UR kGHe33CGB33ORAf7HAqg/z13P2flY0QzQ+js/IVq5PNmmtOBK68Os4t4NzE9ehb5 m5S/tBjLxmwHbnpn7/NK29DIXw/B4SM+cIOy2pL9RZM2kWNzFQYA3Jqb/HgmRrRk 101WbW11w3Jtf5ZpK09FSx4QQVIel6pP1p1NpJ629s5SKPhT8sPDeSi84meqQAb/ HXZF8jCH1pp/QIzIO+ZRo0ZxccayPnMjc5MA5LfXOczjqH5xSinkA+8c/28cgkJE ajc5cvy1vhKlU7vF79TMuDrOclSr9NNuaSROaykkhRV6MmsZP8leD3mKqCC998bo LsYiXHMirywXKNwA+DCY =rEv/ -----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.