Closed Bug 1069405 Opened 10 years ago Closed 10 years ago

PKCS#1 v1.5 RSA signature verification vulnerabilities due to ASN.1 parsing of DigestInfo

Categories

(NSS :: Libraries, defect)

defect
Not set
normal

Tracking

(firefox32+ verified, firefox33+ verified, firefox34+ verified, firefox35+ verified, firefox-esr3132+ verified, b2g-v1.4 fixed, b2g-v2.0 fixed, b2g-v2.0M fixed, b2g-v2.1 fixed, b2g-v2.2 fixed)

RESOLVED DUPLICATE of bug 1064636
Tracking Status
firefox32 + verified
firefox33 + verified
firefox34 + verified
firefox35 + verified
firefox-esr31 32+ verified
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed
b2g-v2.0M --- fixed
b2g-v2.1 --- fixed
b2g-v2.2 --- fixed

People

(Reporter: curtisk, Unassigned, NeedInfo)

References

Details

(Keywords: sec-critical)

Attachments

(3 files)

From: Intel Product Security Incident Response Team
	<Intel.Product.Security.Incident.Response.Team@intel.com>
To: "'security@mozilla.org'" <security@mozilla.org>
Subject: NSS Issue
------/------
Intel Security’s Advanced Threat Research (ATR) team has discovered a variant of the signature forgery attack previously published by Daniel Bleichenbacher, which enables this attack to be used to forge RSA certificates on multiple crypto libraries with incorrect implementation of verification. Due to the way affected libraries parse BER encoded fields, it is possible for an attacker to skip garbage bytes, enabling signature forgery. These attacks target RSA keys with a low exponent (such as 3). The vulnerability is due to the implementation of signature checking in particular crypto libraries; each library must be assessed separately for the conditions that allow for the issue. For that reason, the Intel ATR team continues to assess many other libraries. 

Intel's ATR team has recently determined Mozilla NSS to be vulnerable, and the team has a proof of concept using Firefox root certificates. Details are in the attached document.

NOTE: This vulnerability has not been shared publicly, but the team plans to publish eventually. Because a large number of people/products may embed vulnerable libraries and thereby be affected by this issue, Intel PSIRT has requested that CERT/CC lead the coordination of this issue and assign CVEs. They will likely contact you shortly.

Please contact Intel PSIRT at secure@intel.com for updates or additional information. Our PGP key can be retrieved from our website https://security-center.intel.com/PGPPublicKey.aspx.

Thank you,
- John
Intel PSIRT

gpgkeys: key 52E518C5C7B0C436 not found on keyserver
Summary: signature forgery attack → PKCS#1 v1.5 RSA signature verification vulnerabilities due to ASN.1 parsing of DigestInfo
It seems other people are aware that many implementations have these issues. In the attachment, they describe exactly bug 1064670 and bug 1067214. It clearly took Intel quite a bit of time to prepare the attached report, so I guess they've known about it for a while.
Group: core-security
See Also: → CVE-2014-1568
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #2)
> It seems other people are aware that many implementations have these issues.
> In the attachment, they describe exactly bug 1064670 and bug 1067214. It
> clearly took Intel quite a bit of time to prepare the attached report, so I
> guess they've known about it for a while.

Since July, according to them.
We've known about the general issue from looking at other libraries since July. We only became aware that NSS was affected more recently. In mid July, the Intel ATR team discovered the variant of Daniel Bleichenbacher's attack from 2006 which is enabled by incorrect parsing of ASN.1 encoded DigestInfo. Since then, the team has reviewed the implementations of many libraries in order to determine if they are affected. 

Intel has made several non-public disclosures on this issue since September 3. Upon discovering the same issue in NSS, we became concerned that many parties may be affected. As a result, we have been attempting to start industry-wide coordination of the issue, so that affected parties will be aware of the need to quickly update products that embed the NSS crypto library. We provided information to CERT/CC on Sept 17, 2014. Unfortunately, we have yet to hear back from them.
Intel: who else is affected? We know that OpenSSL accepts high-valued tags at least but doesn't allow unlimited overflow so hopefully that's not critical. But we would want to know before we release updates for FF and Chrome and shine a large spotlight on the issue.
Attached image nss.png
screenshot demonstrating forged certificate
:dveditz/:bsmith,

Can you comment on how far back the gecko's are impacted in-order to guage the impacted on older firefox OS releases and also give me the bug# where this regression came from.

Also, cc'ing paultjt for OS.
Flags: needinfo?(dveditz)
Flags: needinfo?(brian)
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/quickder.c&rev=1.1#170

This has been in NSS since it was open-sourced (at least 2002).
Flags: needinfo?(brian)
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #11)
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/util/
> quickder.c&rev=1.1#170
> 
> This has been in NSS since it was open-sourced (at least 2002).

I take that back. At some point in 2006 or so, the parsing was changed from the old ASN.1 parser to QuickDER. I don't know if the old ASN.1 parser has the same problems. However, I think for your purposes of determining what Firefox/FirefoxOS/Thunderbird releases are affected, it is fair to say this has been in the product "forever."
For coordination purposes, we need to have a common publication date that we can tell all affected parties. What is the present thinking regarding when NSS can have an update ready? Are we planning to publish full details at that time or can we wait a bit to give other affected projects some time? We are meeting with CERT on Monday, and this would be helpful info. Similarly, if there is anything else we should relay to CERT regarding parties that should be contacted or anything else, just let me know.

Also, is there any way to share an early patch with others who may embed NSS into other applications, giving them a chance to prepare?
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #12)
> I take that back. At some point in 2006 or so, the parsing was changed from
> the old ASN.1 parser to QuickDER. I don't know if the old ASN.1 parser has
> the same problems.

I believe that was changed as part of https://www.mozilla.org/security/announce/2006/mfsa2006-60.html (that is, bug 350640, bug 351079, and bug 351848).

(In reply to Intel PSIRT from comment #13)
> For coordination purposes, we need to have a common publication date that we
> can tell all affected parties. What is the present thinking regarding when
> NSS can have an update ready?

We were planning on landing the patches Monday and releasing on Tuesday, although that was after testing other browsers and not finding any affected by the same issue (other than Chrome on Linux? Chrome on Windows is OK). We had not thought about non-browser, non-openssl libraries.

> Are we planning to publish full details at that time or can we wait a bit
> to give other affected projects some time?

We wouldn't publish full bug details for several weeks to help protect slow updaters, but the patch alone may be revealing enough.
Flags: needinfo?(dveditz)
(In reply to Daniel Veditz [:dveditz] from comment #14)
> We were planning on landing the patches Monday and releasing on Tuesday,
> although that was after testing other browsers and not finding any affected
> by the same issue (other than Chrome on Linux? Chrome on Windows is OK). We
> had not thought about non-browser, non-openssl libraries.

Chrome is affected on all platforms except Android. Even though certificate verification might not be affected on Windows and OS X, verification of ServerKeyExchange messages is. (Additionally, we can't patch on Linux because we use the system libnss.)

I fear that Tuesday might be a quick since you're only giving notice now. If nothing else, I think you need to alert distros that an important NSS update is coming on Sept 2${x}th at a given time. If you plan on that being Tuesday then that notice should go out Monday morning. (If you don't have distro contacts to hand, please let me know; someone here certainly does.)
tracking-firefox-esr24 is affected too even if the tracking flags are not up to date and we will do a 
Firefox ESR 24.8.1.

Daniel, it would be nice to warn distributors about this by the normal channel. For example, Debian security team is not aware of this issue yet and libnss is used a lot (libreoffice, chromium, openjdk, evolution, etc).
If needed, just like Adam, I can forward the information to the Debian security team (I know many folks there) and they can take care of forwarding the info to the other distributions.
(In reply to Adam Langley from comment #15)
> I fear that Tuesday might be a quick since you're only giving notice now. If
> nothing else, I think you need to alert distros that an important NSS update

Is Wednesday better then? There's some concerns that we don't want to slip to Thursday since that's the start of Rosh Hashanah and we'll be missing some folks (and other orgs might be as well).
(In reply to Daniel Veditz [:dveditz] from comment #17)
> Is Wednesday better then?

I'll check here, but provisionally, I think that we can say Wednesday @ 10am is good. Are you planning on checking in the change in a public repo? Or are you going to build from a private copy of NSS and only release the code with the update?

A heads-up to the disto security list should probably happen today also once we've confirmed the time.
(In reply to Sylvestre Ledru [:sylvestre] from comment #16)
> tracking-firefox-esr24 is affected too even if the tracking flags are not up
> to date and we will do a 
> Firefox ESR 24.8.1.

Why are we shipping an update to ESR24 when it is out of support? They should upgrade to ESR31 for security updates (which we have already been telling people).
I'm a bit worried that, at this point, Wednesday might still be early. A lot of NSS based projects could be potentially affected, and the patch reveals an issue that is likely present in other crypto libraries as well. It would be better to have a solid heads-up to affected projects and other crypto library maintainers first.

I'll be asking CERT to help contact as many as possible. To allow some flexibility, I will tell CERT that updates may be available "as early as mid this week" and that they should try to contact affected parties asap.

Do any of you have a relatively good list of parties/projects that are potentially impacted? Here's what I've got:
Red Hat, Debian, (every linux distro), Google, Oracle, ...

Similarly, other crypto libraries may have the same problem. Here's a preliminary list of libraries to contact and check with:
openssl, gcrypt, gnupg, discretix, wolfssl, axtls, ...

I'll ask CERT to do some research and contact others as well. Please reply with any additions/changes/concerns.
(In reply to Al Billings [:abillings] from comment #19)
> Why are we shipping an update to ESR24 when it is out of support?

Because it's not out of support. We said we'd support a two-cycle overlap after releasing a new ESR, so ESR24 is supported until ESR31.2 is released. We didn't _plan_ another 24-based release, but "support" means "it gets a chemspill if necessary".
Bug 1064636, where this is being fixed, has been assigned CVE-2014-1568 for tracking.
To second Intel's concern: Any chance of delaying public disclosure, even a week or two?  I don't think I saw patches out yet in mozilla-central.  Arguments for delaying include:

1. Assessing whether other non-NSS implementations are vulnerable to the same/similar bugs, and
2. giving major downstream users a bit more advance warning.

CERT will continue coordination with other crypto libraries with or without a disclosure delay.
(In reply to cert from comment #23)

> 2. giving major downstream users a bit more advance warning.
> 

dveditz asked me to contact linux-distros[1] to give a heads-up which i did, so these distros basically know that something is coming up (Not full details of-course)

[1] http://oss-security.openwall.org/wiki/mailing-lists/distros
(In reply to cert from comment #23)
> To second Intel's concern: Any chance of delaying public disclosure, even a
> week or two?  I don't think I saw patches out yet in mozilla-central. 
> Arguments for delaying include:
> 
> 1. Assessing whether other non-NSS implementations are vulnerable to the
> same/similar bugs, and

We've already done this for the major libraries. Intel have even contacted a couple of more minor ones (discretix, wolfssl). I have a test suite on one of the other bugs if that's helpful. The only one that I haven't seen mentioned yet is CAPI, but it doesn't take more than an hour to test that. (I would - but a kernel update broke VMware for me.)

> 2. giving major downstream users a bit more advance warning.

How is this helpful? Notice has been sent that something is coming, without details. Without the actual patch, what benefit do users get from more time? They can't do testing or impact analysis and we can't give details without giving the game away in this case.

On the other hand, we have two different reporters of this issue, a clear demo exploit and we're ready to go tomorrow with the update. Waiting needs a strong justification.

At this point, Chrome is still working on the assumption that we're doing an update tomorrow.
(In reply to Adam Langley from comment #25)
> (In reply to cert from comment #23)
> > To second Intel's concern: Any chance of delaying public disclosure, even a
> > week or two?  I don't think I saw patches out yet in mozilla-central. 
> > Arguments for delaying include:
> > 
> > 1. Assessing whether other non-NSS implementations are vulnerable to the
> > same/similar bugs, and
> 
> We've already done this for the major libraries. Intel have even contacted a
> couple of more minor ones (discretix, wolfssl). I have a test suite on one
> of the other bugs if that's helpful. The only one that I haven't seen
> mentioned yet is CAPI, but it doesn't take more than an hour to test that.
> (I would - but a kernel update broke VMware for me.)


Adam,

Would you know if openssl is affected? (i saw a few previous comments about it being not affected, but they appeared vague to me, hence this direct question)
(In reply to Huzaifa Sidhpurwala from comment #26)
> Would you know if openssl is affected? (i saw a few previous comments about
> it being not affected, but they appeared vague to me, hence this direct
> question)

OpenSSL has too much flexibility in parsing the ASN.1 signatures (it accepts things like leading zeros in lengths, at least on trunk) but it doesn't appear to be exploitable because there's only a small amount of freedom. Nothing like NSS.

I'll give OpenSSL team the test cases when this is public so that they can tighten up, but it looks like they're fine.
Did Chrome land patches already? Can they be shared, so that there is some clarify, specially w.r.t discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1064636
Group: crypto-core-security
(In reply to Huzaifa Sidhpurwala from comment #28)
> Did Chrome land patches already? Can they be shared, so that there is some
> clarify, specially w.r.t discussion in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1064636

We have not landed patches in public, but we're working off code that was posted to that bug. Whether it's the right code for NSS in the long term is unclear but we believe that it fixes the issue in the short term. The patches will be landed in public at 11am Wednesday.
Curtis, could you help us out by providing clear testing instructions for verification of this fix? Anything that can help us make sure this is fixed. Maybe someone in your team can comment.
Flags: needinfo?(curtisk)
(In reply to juan becerra [:juanb] from comment #30)
> Curtis, could you help us out by providing clear testing instructions for
> verification of this fix? Anything that can help us make sure this is fixed.
> Maybe someone in your team can comment.

There is a test site at https://bad.ht.vc:666. However, Brian remarked elsewhere that it might not work, even in unpatched versions of Firefox, because of an unrelated issue. Still, you might be able to see different errors between the patched and unpatched versions with that site.
yes, the test site in comment 31 exhibits this bug up to Firefox 31, but doesn't connect in Firefox 32 for other unrelated issues. It can't be used to verify this fix on Firefox 32 or higher but could be used in ESR-31 and below.
(In reply to Adam Langley from comment #31)

> There is a test site at https://bad.ht.vc:666. However, Brian remarked
> elsewhere that it might not work, even in unpatched versions of Firefox,
> because of an unrelated issue. Still, you might be able to see different
> errors between the patched and unpatched versions with that site.

That site - specifically port - seems to be unreachable. Maybe it's a firewall issue for me, not sure. Who owns this site? 

This would be very useful for us to test with. We can at least verify the NSS change in ESR builds of Fx24 and Fx31, which ostensibly tells us that Fx versions >31 with latest NSS should be fixed as well.
(In reply to Matt Wobensmith from comment #33)
> That site - specifically port - seems to be unreachable. Maybe it's a
> firewall issue for me, not sure. Who owns this site? 

Ah, Antoine has taken it down. That's a shame.

> This would be very useful for us to test with. We can at least verify the
> NSS change in ESR builds of Fx24 and Fx31, which ostensibly tells us that Fx
> versions >31 with latest NSS should be fixed as well.

Give me a minute.
(In reply to Adam Langley from comment #34)
> Give me a minute.

https://www.imperialviolet.org:4405/ is a server that requires the bug to function. However, it also requires TLS 1.2 so it will always fail in FF prior to 27. (Wikipedia says that FF 27 was the first to enable TLS 1.2 support. You may be able to enable via about:config in FF going back to 23 however.)
Very helpful Adam, that is workable. Thanks very much!
Dveditz or bsmith are likely the best people to ask
Flags: needinfo?(dveditz)
Flags: needinfo?(curtisk)
Flags: needinfo?(brian)
I'm not sure what the question is, but maybe the answer is "security.tls.version.max=3"?

Adam, CERT, et al.: Are we making a distinction between publicly exposing the patches, which has happened today at https://hg.mozilla.org/projects/nss, and public discussion of the issue?
Flags: needinfo?(brian)
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #38)
> Adam, CERT, et al.: Are we making a distinction between publicly exposing
> the patches, which has happened today at
> https://hg.mozilla.org/projects/nss, and public discussion of the issue?

I think so. Indeed, dveditz has asked that Chrome not give details of the bug for some time after release.
A couple questions about process here: 
1. Is there going to be a Mozilla advisory or anything? Any chance of previewing the content to see the level of detail? 

2. How are the independent research/reports going to be addressed?

3. At what point are people planning to release more detail? 

We should try to align our description of these things, if possible.
(In reply to Intel PSIRT from comment #40)
> A couple questions about process here: 
> 1. Is there going to be a Mozilla advisory or anything? Any chance of
> previewing the content to see the level of detail? 
> 
> 2. How are the independent research/reports going to be addressed?
> 
> 3. At what point are people planning to release more detail? 
> 
> We should try to align our description of these things, if possible.

Hi,

Al sent out on email on moz-secritiy-group mailing list with the details of draft advisory, i am attaching it to this bug so that you guys can sync up.
Attached file mfsa2014-73.html
Thanks for posting here! Did Al mention dates regarding details in the mail to moz-security-group?

While PSIRT is doing the communications, we're not really the team that should be mentioned. Instead of mentioning Intel PSIRT, please instead say "The Advanced Threat Research team at Intel Security also independently discovered and reported this issue."
(In reply to Intel PSIRT from comment #43)
> Thanks for posting here! Did Al mention dates regarding details in the mail
> to moz-security-group?
> 
Usual release time is 11:00 pacific time.

> While PSIRT is doing the communications, we're not really the team that
> should be mentioned. Instead of mentioning Intel PSIRT, please instead say
> "The Advanced Threat Research team at Intel Security also independently
> discovered and reported this issue."

I have communicated these proposed changes to Al.
OK. 11am PDT tomorrow for the release of updates... what about releasing details about the issue? There was a mention that this would come later. Any idea when?

Also, can we be listed in the "reporter" section as well, or do you only list the first one?
Also, even though a release is going out tomorrow, please keep this bug security-sensitive (private, restricted access). We want to finish the coordination activities before releasing details in our attached paper or in the ticket history.
In order to verify this:

Using Fx32.0.2 go to https://www.imperialviolet.org:4405/
- You should see an error: "NSS RSA handshake bug test server. If you can see this message then you are affected."
Using Fx32.0.3 (build1) and going to the same URL
- You should see: "Secure Connection Failed. An error occurred during a connection to www.imperialviolet.org:4405. Peer's certificate has an invalid signature. (Error code: sec_error_bad_signature)"

Using Fx31.1.0 ESR go to https://www.imperialviolet.org:4405/
- You should see an error: "NSS RSA handshake bug test server. If you can see this message then you are affected."
Using Fx31.1.1 (build1) ESR and going to the same URL
- You should see: "Secure Connection Failed. An error occurred during a connection to www.imperialviolet.org:4405. Peer's certificate has an invalid signature. (Error code: sec_error_bad_signature)"

Using Fx24.8.0 ESR go to about:config and set the preference security.tls.version.max = 3, then go to https://www.imperialviolet.org:4405/
- You should see an error: "NSS RSA handshake bug test server. If you can see this message then you are affected."
Using Fx24.8.1 (build1) ESR and going to the same URL
- You should see: "Secure Connection Failed. An error occurred during a connection to www.imperialviolet.org:4405. Peer's certificate has an invalid signature. (Error code: sec_error_bad_signature)"

This is a basic verification, but we'll do some exploratory testing around secure sites.
Flags: needinfo?(dveditz)
(In reply to Adam Langley from comment #25)

> > 1. Assessing whether other non-NSS implementations are vulnerable to the
> > same/similar bugs, and
> 
> We've already done this for the major libraries. Intel have even contacted a
> couple of more minor ones (discretix, wolfssl). I have a test suite on one
> of the other bugs if that's helpful. The only one that I haven't seen
> mentioned yet is CAPI, but it doesn't take more than an hour to test that.
> (I would - but a kernel update broke VMware for me.)

There's no (or only a little) evidence of this, originally we thought it was a more widespread/cross-implementation issue.

> > 2. giving major downstream users a bit more advance warning.
> 
> How is this helpful? Notice has been sent that something is coming, without
> details. Without the actual patch, what benefit do users get from more time?
> They can't do testing or impact analysis and we can't give details without
> giving the game away in this case.
>
> On the other hand, we have two different reporters of this issue, a clear
> demo exploit and we're ready to go tomorrow with the update. Waiting needs a
> strong justification.

Even without upstream patches, some vendors can use additional time to even identify products that may be affected.  This is a generic consideration, and like #1 doesn't seem to apply here.  IOW, no strong justification for waiting.
(In reply to Intel PSIRT from comment #45)
> OK. 11am PDT tomorrow for the release of updates... what about releasing
> details about the issue? There was a mention that this would come later. Any
> idea when?
> 
> Also, can we be listed in the "reporter" section as well, or do you only
> list the first one?

CERT will wait to see what Mozilla and Google publish, and we'll either hold our publication or tone down the detail to match.
We've verified this using details from comment 47 on Win 7 x64, Win 8.1 x86, Mac OS X 10.9.4, Ubuntu 13.04 x64, on the following versions:
- 32.0.3 - BuildID=20140923175406
- ESR 31.1.1 - BuildID=20140923184509
- ESR 24.8.1 - BuildID=20140923194127
- 33 Beta 7 - BuildID=20140923222114
- 34 Aurora - BuildID=20140924004001
- 35 Nightly - BuildID=20140923165902

On older versions (32.0.2, ESR 24.8.0, ESR 31.1.0, yesterday's Aurora and Nightly) we get the "NSS RSA handshake bug test server. If you can see this message then you are affected." message, while on the new versions we get the "Secure Connection Failed" page as expected. This works fine on both clean install and after an update.

Also some smoke testing has been performed on 32.0.3, ESR 31.1.1, ESR 24.8.1 and partially so far on 33 Beta 7. Main focus was on browsing secure sites, but also verified stuff like: Web compatibility, Add-on & Plug-in compatibility, Common media format playback, Sync & Persona sign-on. There were several known issues encountered but no new ones. Detailed test results can be found at: https://mozqa.etherpad.mozilla.org/Fx32-0-3, https://mozqa.etherpad.mozilla.org/ESR31-24-Testing, and https://mozqa.etherpad.mozilla.org/Fx33b7.
Reproduced the issue using the link from comment #35 using the following builds:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/24.8.0esr/win32/en-US/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/24.8.0esr/linux-x86_64/en-US/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/24.8.0esr/mac/en-US/

Win 8.1 x64: PASSED

Build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/24.8.1esr-candidates/build1/win32/en-US/
- security.tls.version.max = 3
- Visited https://www.imperialviolet.org:4405
- page didn't load, received "Secure Connection Failed (Error code: sec_error_bad_signature)"

Ubuntu 13.10 x64: PASSED

Build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/24.8.1esr-candidates/build1/linux-x86_64/en-US/
- security.tls.version.max = 3
- Visited https://www.imperialviolet.org:4405
- page didn't load, received "Secure Connection Failed (Error code: sec_error_bad_signature)"

OSX 10.9.4 x64: PASSED

Build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/24.8.1esr-candidates/build1/mac/en-US/
- security.tls.version.max = 3
- Visited https://www.imperialviolet.org:4405
- page didn't load, received "Secure Connection Failed (Error code: sec_error_bad_signature)"
Any updates on the advisory? 

FYI, Intel Security is preparing a similar publication.
Verified fixed on Fx 31.1.1 ESR - Mac/Win/Linux.
Verified fix on 32.0.3 - Android
We have released:
Firefox 32.0.3
Thunderbird 31.1.2
Thunderbird 24.8.1

Pending
Firefox ESR 31.1.1
Firefox ESR 24.8.1
Firefox for Android 31.1.0
The advisory is public: https://www.mozilla.org/security/announce/2014/mfsa2014-73.html

I changed the comment in the second paragraph to match Intel's request. I did not change the reporter section as we'd already been working with Antoine on this issue and I've later noted Intel's report on its own line in the body of the advisory.

Firefox 32.0.3 is public at this point and other releases are in process.
Update on Mozilla product releases. We have now released updates for all products with the exception of SeaMonkey. SeaMonkey 2.29.1 is expected to release in the next few hours. SeaMonkey 2.30 beta1 is targeted for release next week.
Weirdly, I can't reproduce with either 24.8.0 or 24.8.1, I'm getting a ssl_error_protocol_version_alert error (I did set security.tls.version.max to 3, and did test with mozilla.org builds)
I believe all the details of this have now been publicly disclosed. The last remaining undisclosed bit was: https://www.reddit.com/r/netsec/comments/2hd1m8/rsa_signature_forgery_in_nss/cksnr02
(In reply to Mike Hommey [:glandium] from comment #60)
> Weirdly, I can't reproduce with either 24.8.0 or 24.8.1, I'm getting a
> ssl_error_protocol_version_alert error (I did set security.tls.version.max
> to 3, and did test with mozilla.org builds)

FTR, this is because agl changed the server configuration, which now doesn't work with esr24.
I see all flags were set to "fixed". However, verification was already done on: 32.0.3, ESR 31.1.1, ESR 24.8.1, 33 Beta 7, 34 Aurora, 35 Nightly (see comment 50, comment 51, comment 53, comment 54). 

Is there any additional testing needed here?
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #64)
> I see all flags were set to "fixed". However, verification was already done
> on: 32.0.3, ESR 31.1.1, ESR 24.8.1, 33 Beta 7, 34 Aurora, 35 Nightly (see
> comment 50, comment 51, comment 53, comment 54). 
> 
> Is there any additional testing needed here?

I think our testing is complete.
I see there are plans to make bug 1064636 public. Please do NOT make this one public yet, since we mentioned that we're coordinating with others. We would like to confirm that all that is resolved before making this one public.
Attached file DRAFT-NSS_BERserk.pdf
NSS-specific details planned to be posted/released by Intel Security
Intel Security is planning to post additional detail (see attachment above). Please let us know if there are any comments or concerns.
Intel: Can this bug be un-hidden now, or do you still need more time?
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(secure)
Resolution: --- → DUPLICATE
See Also: CVE-2014-1568
CERT/CC contacted other vendors on the chance they were affected by similar vulnerabilities. Here are the results of our coordination outreach:

Vendors that have notified us that they are not affected: 

Cryptlib, Crypto++, EMC (specifically BSAFE C and Java toolkits), GnuTLS, IAIK, Bouncy Castle, Microsoft, and OpenSSL.

Vendors that have not replied and whose status remains unknown: 

Attachmate, Cisco, Discretix, LibTomCrypt, MatrixSSL, Oracle, SafeNet, Spyrus, VMware, WolfSSL, and Yahoo.
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: