Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon,  7 Sep 2015 11:44:01 -0400 (EDT)
Subject: Re: nss: SSL_ImplementedCiphers ABI incompatibility may lead to incorrect cipher suites

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




  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 ]
Version: GnuPG v1


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.