[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 9 Sep 2015 11:59:18 +0200
From: Florian Weimer <fweimer@...hat.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: nss: SSL_ImplementedCiphers ABI incompatibility may lead to
incorrect cipher suites
On 09/07/2015 05:44 PM, cve-assign@...re.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
View attachment "diff.txt" of type "text/plain" (3256 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.
