Don't Authenticode sign nssdbm3.dll (FIPS broken in Win32 3.5.4 build1, and any release that'll use NSS 3.12.4)

VERIFIED FIXED

Status

defect
--
major
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: rjohnson19, Assigned: nthomas)

Tracking

({regression, verified1.9.1})

Dependency tree / graph

Firefox Tracking Flags

(blocking1.9.1 .4+, status1.9.1 .4-fixed)

Details

Attachments

(3 attachments)

Reporter

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4) Gecko/20091007 Firefox/3.5.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4) Gecko/20091007 Firefox/3.5.4

SSL does not work, and you get a "Could not initialize the application's security component" message on startup if you upgrade from 3.5.3 to 3.5.4 with FIPS mode enabled.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox 3.5.3
2. Set a Master Password
3. Enable FIPS mode
4. Upgrade to Firefox 3.5.4 candidate.
Actual Results:  
Error message appears on startup:
"Could not initialize the application's security component. The most likely cause is problems with files in your application's profile directory. Please check that this directory has no read/write restrictions and your hard disk is not full or close to full. It is recommended that you exit the application and fix the problem. If you continue to use this session, you might see incorrect application behaviour when accessing security features."

SSL connections result in an error page (Error code: ssl_error_ssl_disabled)

Expected Results:  
Firefox starts up normally, SSL connections work after entering the master password.

I was able to workaround the issue by downgrading to 3.5.3, disabling FIPS and the master password, then upgrading, then re-enabling a master password. I couldn't get FIPS enabled in 3.5.4:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPKCS11ModuleDB.toggleFIPSMode]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://pippki/content/device_manager.js :: toggleFIPS :: line 545"  data: no]

A second attempt resulted in a delayed crash (http://crash-stats.mozilla.com/report/index/18a0ef70-ad24-4e80-8096-d28d32091012)

In the broken 3.5.4 profile with FIPS enabled, there were duplicate NSS/PSM entries in Security Devices.
Assignee

Comment 1

10 years ago
I can confirm this problem on WinXP after updating from 3.5.3 to 3.5.4 on the beta channel (didn't try the workaround). In the Firefox preferences the "Use a master password" box is not set, and there is an "Enable FIPS" button in the Security Device Manager; you get an "Unable to set Master password" message if you try to set one.

A fresh profile with 3.5.4 allows you to set a master password but not enable FIPS - the error console has the toogleFIPSMode exception from above.

I've verified that all three chk files - freebl3.chk, nssdbm3.chk, softokn3.chk - are present in the installer, but I don't recall how to verify they're valid.
Status: UNCONFIRMED → NEW
blocking1.9.1: --- → ?
Component: General → Password Manager
Ever confirmed: true
Product: Firefox → Toolkit
QA Contact: general → password.manager
Version: unspecified → 1.9.2 Branch
This seems quite similar to Bug 503418.
Bug 520063 may have been the same thing, with the Thunderbird nightly from either 2009-10-01 or 2009-09-30.
Assignee: nobody → kaie
Component: Password Manager → Security: PSM
Product: Toolkit → Core
QA Contact: password.manager → psm
(In reply to comment #1)
> I can confirm this problem on WinXP after updating from 3.5.3 to 3.5.4 on the
> beta channel (didn't try the workaround). In the Firefox preferences the "Use a
> master password" box is not set, and there is an "Enable FIPS" button in the
> Security Device Manager; you get an "Unable to set Master password" message if
> you try to set one.
> 
>

Also confirmed the workaround, enabling the FIPS Mode in 3.5.4 does not work even when you had FIPS disabled (not selected) before the update. Seems to be a regression.
Keywords: regression
We would need a regression range. Possible related bugs which have been fixed for 3.5.4 especially for FIPS mode: bug 509558, bug 509319.
Severity: normal → major
OS: Windows Vista → All
Hardware: x86 → All
Is this only on 1.9.1? Is 1.9.2 or trunk affected?
(In reply to comment #6)
> Is this only on 1.9.1? Is 1.9.2 or trunk affected?

i see the same in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091011 Minefield/3.7a1pre 

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPKCS11ModuleDB.toggleFIPSMode]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://pippki/content/device_manager.js :: toggleFIPS :: line 545"  data: no]
I will start with a regression test now.
If you open such a profile with a build on 1.9.2 or trunk the browser will crash immediately. See bug 522041.
Regressed between the builds 09091603 and 09091703:

Pass: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b7dd9891657f
Fail: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f3f8aeecc2bd

Changesets: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=b7dd9891657f&tochange=f3f8aeecc2bd

Definitely a regression from bug 509319 as already thought in comment 5. So I believe bug 522041 is the same fallout but crashes on 1.9.2 and trunk.
We're going to respin Firefox 3.5.4 builds for this issue.
blocking1.9.1: ? → .4+
While there may well be other FIPS bugs on other platforms and branches, I'd expect that _this_ is Windows/1.9.1 only - if you look at the Firefox3.5 tinderbox logs, you'll see that on Linux and OS X, signing of nssdb3 goes just fine, but on Windows it appears to silently crap out somewhere (in a path through the program that I can't spot), so that you don't get the "moduleSpec..." or "Generate a DSA key pair ..." lines that you get on non-Windows, and on Windows for the other two dlls being signed, but still manage to make it down to the "Library File:..." and following lines.
Assignee

Comment 13

10 years ago
Looks OK to me, what am I missing Phil ?
Assignee

Comment 14

10 years ago
Gah, we Authenticode signed nssdbm3.dll and therefore invalidated nssdbm3.chk. We don't signed freebl3.chk or softokn3.dll for this reason.
Assignee: kaie → nobody
Component: Security: PSM → Release Engineering
Product: Core → mozilla.org
QA Contact: psm → release
Version: 1.9.2 Branch → other
Assignee

Updated

10 years ago
Assignee: nobody → nthomas
OS: All → Windows XP
Summary: SSL broken after 3.5.3 -> 3.5.4 upgrade with FIPS mode (FIPS broken in 3.5.4) → Don't Authenticode sign nssdbm3.dll (FIPS broken in Win32 3.5.4 build1, and any release that'll use NSS 3.12.4)
Assignee

Comment 15

10 years ago
This should do the trick, I'll go verify that.
Assignee

Updated

10 years ago
Attachment #406103 - Attachment description: Add nss3dbm3.dll to signing exception list → Add nssdbm3.dll to signing exception list
What you were missing is that we were talking about two different signings: yours is from http://mxr.mozilla.org/mozilla1.9.1/source/security/nss/cmd/shlibsign/Makefile#118 while building NSS, mine is from http://mxr.mozilla.org/mozilla1.9.1/source/toolkit/mozapps/installer/packager.mk#233 while making package|installer.
And it can't (just) be Authenticode signing, can it? We don't sign nightlies or hourlies, which I assume were the source of Henrik's range, and Bob Lord's probable dupe bug 520063.
Assignee

Comment 18

10 years ago
This also looks OK. Could the -j4 of nightlies be mixing up the logs a lot ? What I've got here is already a mixture of stdout and stderr, and buildbot sometimes gets the ordering a little wrong. Otherwise I don't understand that.

make installer doesn't regenerate the chk files as far as I can see.
Assignee

Comment 19

10 years ago
Comment on attachment 406103 [details] [diff] [review]
Add nssdbm3.dll to signing exception list

I re-signed an en-US and de installer for 3.5.4 build1 using this patch, and was able to enable FIPS mode and visit https sites. 

Also confirmed that linux and mac are not affected. Don't know what to make of Tomcat's comment #7.
Attachment #406103 - Flags: review?(ccooper)
Assignee

Comment 20

10 years ago
We may be fine for 3.0.15, where we're using NSS 3.12.3. We sign nssdbm3.dll but we're not packaging a chk file (which became a requirement in 3.12.4 IIRC) so that's OK. Good even, since we should sign every binary we can except where restricted.

FIPS behaves slightly weirdly though: When you press "Enable FIPS" the button label changes to "Disable FIPS" but the button is disabled. You can still visit https sites and there's no error in the console. If you restart Firefox then the button is re-enabled. Same thing if you then go "Disable FIPS"
Nick, OS X is definitely affected. My regression tests are based on nighly builds on OS X. So I wonder if we should file a new bug for OS X (and Linux)?
Ok, I did the tests again and now I'm crashing too with Shiretoko. Looks like the OS X part is bug 522041.

Comment 23

10 years ago
Comment on attachment 406103 [details] [diff] [review]
Add nssdbm3.dll to signing exception list

Is release/signing/signing.py in any MXR search?
When I worked on the nssdbm3.chk issue, I searched
mozilla-central for "softokn" to make sure I changed
every file that needed changing.  But
release/signing/signing.py isn't in
http://mxr.mozilla.org/mozilla-central/.  What is
a Mozilla developer to do?  So now I know I also
need to search in http://mxr.mozilla.org/build/.
Anything else?
Attachment #406103 - Flags: review?(ccooper) → review+
Assignee

Comment 24

10 years ago
Comment on attachment 406103 [details] [diff] [review]
Add nssdbm3.dll to signing exception list

http://hg.mozilla.org/build/tools/rev/115349b92de8
Attachment #406103 - Flags: checked-in+
Assignee

Comment 25

10 years ago
To avoid this in future we should fix bug 489961 in a way that
* signs freebl3.dll etc rather than excepting them
* regenerates all chk files present in unsigned build
* puts the regenerated chk files in the complete mar to also fix bug 404340
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(In reply to comment #20)

> FIPS behaves slightly weirdly though: When you press "Enable FIPS" the button
> label changes to "Disable FIPS" but the button is disabled. You can still visit
> https sites and there's no error in the console. If you restart Firefox then
> the button is re-enabled. Same thing if you then go "Disable FIPS"

ss: dveditz: is this expected behavior, or should we spin this out into a
separate bug?

Comment 27

10 years ago
John: that's expected behavior.  The button is disabled after
you press it to prevent you from toggle it again in the same
browsing session.  I forgot the reason why NSS doesn't allow
you to toggle the FIPS mode twice.
Assignee

Comment 28

10 years ago
(In reply to comment #23)
> So now I know I also need to search in http://mxr.mozilla.org/build/.
> Anything else?

Can't think of anywhere else we stash signing scripts (that we still use).
(In reply to comment #25) Nick Thomas wrote:
> To avoid this in future we should fix bug 489961 in a way that
> * signs freebl3.dll etc rather than excepting them
> * regenerates all chk files present in unsigned build
> * puts the regenerated chk files in the complete mar to also fix bug 404340

Hear! Hear!  

I asked Dan Veditz why those steps aren't already happening.  As I understood
(or perhaps misunderstood) the response, it was due the the belief that regenerating the .chk files meant moving the signed .DLLs from the special system where they are authenticode signed back to the system (and build tree) 
where they were built, and then re-running part of the make that built them, 
the part that runs shlibsign to generate the .chk files.  This is deemed 
awkward, perhaps labor intensive, potentially error prone, and generally ugly 
from an automated release generation perspective.  

But I have good news (No, I didn't switch to GEICO :).  Unlike the authenticode signing process, which requires a secret key that must be carefully protected, and is generally restricted to just one system for that reason, the process of
generating the .chk files can be done on any windows system.  It need not be 
the system on which the build was orignally done, and it need not be done 
with the very same copy of shlibsign that was built along with the DLLs being
"signed" by shlibsign.  Yes, we've integrated the use of shlibsign into the 
NSS build, but that's not essential.  You can run shlibsign whenever you like.

In essence, you can regard shlibsign as just another tool, like another 
compiler or post processor of some kind.  You can build it once, and keep 
that one built copy and use it over and over for days, weeks, months, years
on end.  shlibsign itself hasn't changed in a long time.  You could use a 
copy built (say) a year ago and it would work just fine today.  

You could put a copy of shlibsign on the authenticode signing system 
(if that appeals to you), and then just run it for each .DLL file whose .chk 
file needs to be regenerated, after that DLL has been authenticode signed. 
Or, if there's some other system on which you do packaging after you do the
authenticode signing, and you would rather do the .chk file regeneration 
there, just put the shlibsign program (and the DLLs it needs) there, and use
it there.  

I hope this helps.
Assignee

Comment 30

10 years ago
Nelson, that's very much what I had in mind, but lets have that discussion in bug 489961.
Verified fixed with 3.5.4 build2: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091014 Firefox/3.5.4 (.NET CLR 3.5.30729) ID:20091014223740
Status: RESOLVED → VERIFIED
Keywords: verified1.9.1
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.