Closed Bug 921090 Opened 6 years ago Closed 6 years ago

Upgrade Firefox to NSS 3.15.2 to fix bug 894370

Categories

(Firefox :: Security, defect, P1)

25 Branch
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox24 --- wontfix
firefox25 + fixed
firefox26 --- fixed
firefox27 --- fixed
firefox-esr17 25+ fixed
firefox-esr24 25+ fixed
b2g18 25+ fixed
b2g-v1.1hd --- fixed
b2g-v1.2 --- fixed

People

(Reporter: dveditz, Assigned: geekboy)

References

Details

(Keywords: assertion, regression, sec-moderate, Whiteboard: [adv-main25-][adv-esr24-1-])

Attachments

(2 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #894370 +++

We need to fix NSS security bug 894370 in older Firefox branches. mozilla-central and -aurora (firefox 26+) already have NSS 3.15.2 containing this fix, but Firefox ESR-24 and Firefox 25 (aurora) are currently using NSS 3.15.1 which does not.

ESR-17 and b2g18 branches are using the older NSS 3.14.3 which is affected, but we don't think this sec-moderate bug is severe enough to worry about on those EOL/near-EOL branches given the larger NSS jump required.
No longer blocks: 532972, CVE-2013-1620
Kaie - can you take this?
Assignee: nobody → kaie
Assignee: kaie → brian
I suggest that we fix bug 894370 for b2g18 by applying the patch for bug 894370 directly to the mozilla-b2g18 repo, instead of upgrading all of NSS in mozilla-b2g18 to NSS 3.15.2. Note that we already have two other private patches to NSS in mozilla-b2g18.

bug 894370 is a bug fix to the code that prevents the Lucky 13 attack and is sec-moderate. The patch for bug 894370 applies cleanly to the mozilla-b2g18 branch.

The mozilla-b2g18 branch uses NSS 3.14.3, which apparently was before we did the big switch to NSS and before we re-arranged the NSS directory structure (e.g. before we moved security/coreconf to be security/nss/coreconf and before we moved security/dbm to be security/nss/lib/dbm). To upgrade NSS 3.14.3 all the way to NSS 3.15.2 in mozilla-beta we would need to make updates to the customized build system we have for NSS in Gecko (security/build). In addition, we will get all the TLS 1.2 code and other unrelated fixes.

This seems like a lot of changes to be adding to a branch that is supposed to be very stable and which Aki said is supposed to be limited to chemspill-type bug fixes.

Dan, does applying the patch for bug 894370 as a private patch sound reasonable to you?
Flags: needinfo?(dveditz)
Also, what to do about ESR17? I suggest we apply the patch as a private patch for ESR17 too, BUT change configure.in to require NSS 3.15.2 for when --use-system-nss is used.
Flags: needinfo?(mh+mozilla)
sounds fair enough.
Flags: needinfo?(mh+mozilla)
> Dan, does applying the patch for bug 894370 as a private patch
> [to b2g18] sound reasonable to you?

To b2g18, certainly.

(In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment #4)
> Also, what to do about ESR17? I suggest we apply the patch as a private
> patch for ESR17 too, BUT change configure.in to require NSS 3.15.2 for when
> --use-system-nss is used.

Sounds OK since we've only got one last ESR17 release. Can we fiddle the version strings so the DLLs don't claim to be stock 3.14.3?
Flags: needinfo?(dveditz)
Are we checking in something for ESR17 here, Brian?
Whiteboard: [adv-main25-][adv-esr24-1-]
I think Brian is out today. I'm guessing that our time is running out for 17esr. Sid, any ideas?
Flags: needinfo?(sstamm)
needinfo :dveditz to help with the decision on esr17 here , given the gtb timeline.
Flags: needinfo?(dveditz)
I'm working through this with the nss dev team to make a new release NSS 3.14.4 which is 3.14.3 plus the patch in 894370 so we don't have to fiddle with version strings (for the DLL).

Do we still want the changes to Configure.in? I'm unaware of what effect that will have on linux distros where users want system NSS but don't have access to the latest and greatest 3.15.2.
Flags: needinfo?(dveditz)
-> sid based on comment 10.

(In reply to Sid Stamm [:geekboy or :sstamm] from comment #10)
> I'm working through this with the nss dev team to make a new release NSS
> 3.14.4 which is 3.14.3 plus the patch in 894370 so we don't have to fiddle
> with version strings (for the DLL).
> 
> Do we still want the changes to Configure.in? I'm unaware of what effect
> that will have on linux distros where users want system NSS but don't have
> access to the latest and greatest 3.15.2.

If you make an NSS 3.14.4 then you need to change configure.in to require NSS 3.14.4 or later. If we skip the NSS 3.14.4 release then we need to change configure.in to require NSS 3.15.2. If you don't change configure.in then it is almost guaranteed that some Linux distros that configure Firefox to use system NSS won't be updated with the bug fix (this has happened before in similar situations when we forgot to update configure.in).
Assignee: brian → sstamm
(In reply to Brian Smith (:briansmith, was :bsmith@mozilla.com) from comment #11)
> > 
> If you make an NSS 3.14.4 then you need to change configure.in to require
> NSS 3.14.4 or later. If we skip the NSS 3.14.4 release then we need to
> change configure.in to require NSS 3.15.2. If you don't change configure.in
> then it is almost guaranteed that some Linux distros that configure Firefox
> to use system NSS won't be updated with the bug fix (this has happened
> before in similar situations when we forgot to update configure.in).


While this is reasonable, it has been forgotten on earlier updates to the ESR 17 branch. That branch currently uses NSS 3.14.3, but the min_nss_version set in configure.in is still at the much older version 3.13.2

So, if you want to minimize changes on ESR 17, you could keep the min_nss_version in configure.in - Obviously, ESR 17 already relies on distribution package maintainers to be smart and doublecheck which NSS version is necessary.

On the other hand, updating configure.in forces admins to notice, and given we create an updated release, all consumers of ESR 17 who separately build NSS should be able to upgrade their NSS version, too.
Attached patch update ESR17 to 3.14.4 RC0 (obsolete) — Splinter Review
I've create a NSS 3.14.4 release candidate (RC0). I'm waiting for Bob or Wan-Teh to approve the release as prepared.

This is a patch that updates ESR 17 to that RC0. Let's wait a bit until I get a "go".
Attachment #820532 - Flags: review?(wtc)
Notice to self: When landing, also update TAG-INFO, TAG-INFO-CKBI to the final release tag, and the dummy whitespace change to coreconf.dep.
Attachment #820532 - Attachment is obsolete: true
Attachment #820532 - Flags: review?(wtc)
Comment on attachment 820575 [details] [diff] [review]
update ESR17 to 3.14.4 RTM - final patch

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: 
Fix Landed on Version:
Risk to taking this patch (and alternatives if risky): 
String or UUID changes made by this patch: 

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: is regression and sec-moderate, want our users to be safe
User impact if declined: users of esr may be vulnerable to attack
Fix Landed on Version: fix is in bug 894370 (fx 26+, also in latest NSS)
Risk to taking this patch (and alternatives if risky): minimal, fixes a bug in old version of NSS used by ESR17
String or UUID changes made by this patch: none


dveditz: I assume we should upgrade configure.in as well (attachment 820581 [details] [diff] [review])?
Attachment #820575 - Flags: approval-mozilla-esr17?
Adding the two other bugs included in the patch to the depends on list. (Bug 832942 and Bug 863947)
Depends on: 832942, 863947
Comment on attachment 820575 [details] [diff] [review]
update ESR17 to 3.14.4 RTM - final patch

ESR-17 didn't really need those two extra patches, but they don't increase the risk much and I'd rather use an officially-blessed NSS release than not and this is preferable to the much larger 3.15.x upgrade.

a=dveditz
Attachment #820575 - Flags: approval-mozilla-esr17? → approval-mozilla-esr17+
Checked in
https://hg.mozilla.org/releases/mozilla-esr17/rev/73391f62b265

We agreed that we better not upgrade configure.in, but I accidentally had included it.
Backed that out:
https://hg.mozilla.org/releases/mozilla-esr17/rev/c3750e0515f7
Attachment #820575 - Flags: checkin+
Attachment #820581 - Flags: feedback-
Attachment #820581 - Flags: checkin-
Flags: needinfo?(sstamm)
Can you please mention in the ESR 17 release notes that Firefox 17.0.10 should be used with NSS 3.14.4 (or alternatively using NSS 3.15.2 or later)?
Attachment #820575 - Flags: review+
(In reply to Kai Engert (:kaie) from comment #21)
> Can you please mention in the ESR 17 release notes that Firefox 17.0.10
> should be used with NSS 3.14.4 (or alternatively using NSS 3.15.2 or later)?

This is why we update configure.in. Why wouldn't we want to update configure.in? We know from past experience that when we don't, Linux distros don't upgrade NSS.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Do we want this on b2g18 as well?
Group: core-security
You need to log in before you can comment on or make changes to this bug.