|Summary:||CVE-2015-2721 NSS: incorrectly permited skipping of ServerKeyExchange (MFSA 2015-71)|
|Product:||[Other] Security Response||Reporter:||Huzaifa S. Sidhpurwala <huzaifas>|
|Component:||vulnerability||Assignee:||Elio Maldonado Batiz <emaldona>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||emaldona, huzaifas, jrusnack, magoldma, nmavrogi, rrelyea, security-response-team, tmraz|
|Target Milestone:||---||Keywords:||Reopened, Security|
|Fixed In Version:||nss-3.19.1-1.el5_11||Doc Type:||Bug Fix|
It was found that NSS permitted skipping of the ServerKeyExchange packet during a handshake involving ECDHE (Elliptic Curve Diffie-Hellman key Exchange). A remote attacker could use this flaw to bypass the forward-secrecy of a TLS/SSL connection.
|Last Closed:||2015-09-01 07:54:02 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1247487|
Description Huzaifa S. Sidhpurwala 2015-06-30 05:24:59 UTC
Security researcher Karthikeyan Bhargavan reported an issue in Network Security Services (NSS) where the client allows for a ECDHE_ECDSA exchange where the server does not send its ServerKeyExchange message instead of aborting the handshake. Instead, the NSS client will take the EC key from the ECDSA certificate. This violates the TLS protocol and also has some security implications for forward secrecy. In this situation, the browser thinks it is engaged in an ECDHE exchange, but has been silently downgraded to a non-forward secret mixed-ECDH exchange instead. As a result, if False Start is enabled, the browser will start sending data encrypted under these non-forward-secret connection keys. This issue was fixed in NSS version 3.19.1. External Reference: http://www.mozilla.org/security/announce/2015/mfsa2015-71.html Acknowledgements: Red Hat would like to thank the Mozilla project for reporting this issue. Upstream acknowledges Karthikeyan Bhargavan as the original reporter.
Comment 1 Huzaifa S. Sidhpurwala 2015-07-06 08:21:41 UTC
Upstream commits: https://hg.mozilla.org/projects/nss/rev/6b4770c76bc8 Test case at: https://hg.mozilla.org/projects/nss/rev/1865635f5df5 This issue was fixed in NSS version 3.19.1.
Comment 2 Huzaifa S. Sidhpurwala 2015-07-14 05:29:26 UTC
This issue was fixed in Red Hat Enterprise Linux 6 and 7 via the following advisory: https://rhn.redhat.com/errata/RHSA-2015-1185.html
Comment 3 Huzaifa S. Sidhpurwala 2015-07-14 05:45:44 UTC
Comment 11 Elio Maldonado Batiz 2015-07-29 21:46:15 UTC
Created attachment 1057422 [details] all changes required for rebasing to nss-3.19.1 For informational purpose ostly. To apply, in a convenient location do: rhpkhg clone nss; cd nss; rhpkg switch-branch patch -p1 < a-to/allchanges4rebase.patch It's not easy on the eyes so I'll attach the nss.spec portion next.
Comment 12 Elio Maldonado Batiz 2015-07-29 21:55:12 UTC
Created attachment 1057423 [details] spec file changes - in patch format deleted: expired-cert.patch, nss-3.18.1-ca-2.3-to-2.4.patch, and syntaxfix.patch which were rendered obsolete with the rebase. modified: nss-revert-tls-version-defaults.patch on account of the rebase, same patch but was generated with gendiff, same as previously done on rhel 6 and.
Comment 13 Elio Maldonado Batiz 2015-07-30 13:30:05 UTC
Comment on attachment 1057423 [details] spec file changes - in patch format This patch is not yet complete as it missed picking up a post release fix to a 3.19.1 caused regression which is a main driver for this. Upstream bug is: https://bugzilla.mozilla.org/show_bug.cgi?id=1173413. Thanks to Bob for that and other reminders. Doing other checks for upstream changes to default behavior that need to be reversed.
Comment 14 Elio Maldonado Batiz 2015-07-30 17:47:12 UTC
Created attachment 1057769 [details] all changes for rebase
Comment 15 Elio Maldonado Batiz 2015-07-30 17:50:04 UTC
Created attachment 1057770 [details] nss.spec changes - in patch format Extracted from the other patch, easier to read and review.
Comment 16 Bob Relyea 2015-07-31 18:02:23 UTC
Comment on attachment 1057769 [details] all changes for rebase r- Please explain why the keep tls default patch changed from a -R (revert) to no -R as in the comment. Do you have a different keep tls defaults patch? Also, include the min_key_sizes patch for review.
Comment 17 Elio Maldonado Batiz 2015-07-31 18:27:20 UTC
(In reply to Bob Relyea from comment #16) > Comment on attachment 1057769 [details] > all changes for rebase > > r- > > Please explain why the keep tls default patch changed from a -R (revert) to > no -R as in the comment. Do you have a different keep tls defaults patch? The reason is that originally it was excactly the same patch as the one upstream this we needed the -R (revert) to tell the tool the intention is to revert. The patch no longer applies due to code changes since then. This patch was manually generated using gendiff and -R. can't be used. This the same as change I had to for RHEl-6, actually I copied it from there. I should have added add a brief version of this explanation to the nss.spc. > > Also, include the min_key_sizes patch for review. Yes, coming next.
Comment 18 Elio Maldonado Batiz 2015-07-31 18:35:46 UTC
Created attachment 1058106 [details] Reverts upstream changes that bumped the minimum key sizes This patch reverts the upstream change but there I have meaning to ask you, should we instead change them but choose our minimum values values?
Comment 19 Bob Relyea 2015-07-31 20:35:01 UTC
Comment on attachment 1058106 [details] Reverts upstream changes that bumped the minimum key sizes r+