Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ