oss-sec mailing list archives

Re: nss: SSL_ImplementedCiphers ABI incompatibility may lead to incorrect cipher suites


From: Florian Weimer <fweimer () redhat com>
Date: Wed, 9 Sep 2015 11:59:18 +0200

On 09/07/2015 05:44 PM, cve-assign () mitre org wrote:

(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.)

I looked at the upgrade from Red Hat Enterprise Linux 6.1 to 6.7
(nss-3.12.9-9.el6.x86_64 to nss-3.18.0-5.3.el6_6.x86_64), which is
larger.  See the attached text file.

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.

?

As far as I can tell, the value of SSL_ImplementedCiphers does not have
any impact on NSS by itself.  The cipher suites it enables by default do
not change based on the cipher suites listed in the array.

The hypothetical problem I can see is with an application traversing the
SSL_ImplementedCiphers array, looking up each cipher suite using
SSL_GetCipherSuiteInfo, and then changing the set of enabled ciphers
based on some application policy.  This could say, “disable all RC4
cipher suites” or “disable all MD5 cipher suites”.  If the
SSL_ImplementedCiphers array is truncated, the application would miss
cipher suites which are implemented and enabled, and would not be able
to disable them.  As a result the “no RC4” or “no MD5” policy is not
enforced.

-- 
Florian Weimer / Red Hat Product Security

Attachment: diff.txt
Description:


Current thread: