Closed Bug 509319 Opened 15 years ago Closed 14 years ago

Enable FIPS throws uncaught exception in toggleFIPS

Categories

(Core :: Security: PSM, defect)

x86_64
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta1-fixed
blocking1.9.1 --- .4+
status1.9.1 --- .4-fixed

People

(Reporter: eagle3386, Assigned: KaiE)

References

Details

(Keywords: regression, Whiteboard: [verify on 1.9.2])

Attachments

(1 file, 4 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090808 Minefield/3.6a2pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090808 Minefield/3.6a2pre (.NET CLR 3.5.30729)

Updated to the latest nightly about some hours ago and tried to enable FIPS, after reading an article about improved security by doing so, which doesn't succeed.

Reproducible: Always

Steps to Reproduce:
1. Go to preferences -> Advanced -> Encryption-tab -> Security Devices
2. Click "NSS Internal PKCS #11 Module"
3. Click "Enable FIPS"
Actual Results:  
Clicking "Enable FIPS" doesn't work anymore (worked on earlier builds, i.e. latest Firefox release, etc.)

Expected Results:  
As in earlier versions, FIPS should be enabled and the button's label should be changed to "Disable FIPS"

Error console's message:

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]
Additionally, I can confirm this bug occurs on Windows XP with SP 3 and the same Minefield-version.
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
Confirmed in:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090809 Shredder/3.1a1pre
Status: UNCONFIRMED → NEW
Ever confirmed: true
separate issue: I filed bug 511320 to get us an error message when enable/disable fips mode fails.
Martin, did you set a master password before you attempted to enable FIPS? That's a requirement.

But Firefox should have told you, I'm not sure if we really have a prompt, or maybe that information prompt is broken?
Wan-Teh suspects it may be that FIPS checksum file nssdbm3.chk is missing or outdated.

I confirm that mozilla/Makefile.in does NOT yet contain the necessary step to re-sign nssdbm3.
Attached patch Patch v1 (obsolete) — Splinter Review
This patch is missing, it does a re-signing at build time for the newly added nssdbm3

However, it appears this code only gets executed on Windows, while this bug has been confirmed on Mac, too, I conclude something else must be missing or wrong.
Attachment #395229 - Flags: review?(wtc)
Attachment #395229 - Flags: review?(wtc) → review+
Comment on attachment 395229 [details] [diff] [review]
Patch v1

r=wtc.
Attached patch Additional Patch v2 (obsolete) — Splinter Review
Attachment #395242 - Flags: review?(wtc)
I searched through Mozilla and found additional places where softokn is mentioned, but nssdbm not yet.

Not sure if the linker command lines indeed need to be changed?

Do I need to worry about NSS_DISABLE_DBM ?
Comment on attachment 395242 [details] [diff] [review]
Additional Patch v2

libnssdbm3.so is only loaded dynamically like libfreebl3.so.
So we should not add -lnssdbm3.

Please remove the changes to configure.in from this patch.
In fact, libsoftokn3.so is also dynamically loaded now, so
you may want take this opportunity to remove libsoftokn3.so
from NSS_DEP_LIBS and NSS_LIBS in configure.in.

Please remove the changes to  security/manager/Makefile.in
from this patch.  Also remove softokn3.lib/libsoftokn3.so
from SDK_LIBS.

I don't think we need the change to xpcom/stub/Makefile.in
because libfreebl3.so is not in DEPENDENT_LIBS_LIST.

The change to xulrunner/installer/mozilla-nss.pc.in should
be removed from this patch.  Could you also remove -lsoftokn3?
Also, use this order:
  -lsmime3 -lssl3 -lnss3 -lnssutil3
Attachment #395242 - Flags: review?(wtc) → review-
Summary: Enable FIPS throughs uncaught exception in toggleFIPS → Enable FIPS throws uncaught exception in toggleFIPS
I have not yet been able to reproduce this bug using Linux.
Both my own Linux trunk build,
and a downloaded nightly Linux build
  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a2pre) 
  Gecko/20090818 Namoroka/3.6a2pre
work fine for
(fresh profile, set master password, enable fips, open ssl site).

So this may happen only on mac and windows?
Worksforme on Windows XP, downloaded FF 3.6a nightly.

Is it specific to existing profiles?
Could you please try using a fresh profile and report back?
Attached patch Patch v3 (obsolete) — Splinter Review
Combined patch after addressing Wan-Teh's requests
Attachment #395229 - Attachment is obsolete: true
Attachment #395242 - Attachment is obsolete: true
Attachment #395274 - Flags: review?(wtc)
(In reply to comment #4)
> Martin, did you set a master password before you attempted to enable FIPS?
> That's a requirement.

That was a bit "ugly", because Firefox told me that it was already set.
However, entering the password resulted in another password-prompt, because Firefox seemed to think the password was wrong.

After some research, I figured out that my secmod.db got somehow corrupted (probably due to a failure of my hard disk, replaced the drive already) and deleted that file in order to force Firefox to create a new one.

Afterwards, I successfully created a new master password (same as the old one) and then clicked FIPS - but the exception reported above still occured.

> But Firefox should have told you, I'm not sure if we really have a prompt, or
> maybe that information prompt is broken?

Since I created the password first, I could test it.

But because of the current situation, I'm going to created a blank profile and test it there. I'll post my results ASAP.
Err, there's a typo in my sentence "Since I created the password first, I could test it." - of course, it should state "Since I created the password first, I could _not_ test it."

I apologize myself for that!
Well, I think I've got a problem here now:

After closing my Namoroka-nightly, I was told that updates are being installed right now. Afterwards, I visited the Security Devices-section, clicked "Enable FIPS" and BANG - it worked just fine and I got both files within Namoroka's application-folder: nssdbm3.chk and nssdbm3.dll!

Additionally, I tested the procedure for enabling FIPS and I can confirm that a warning dialog is shown, requesting me to set the master password first.

Enabling FIPS was no problem and went the way as expected - so, is this bug already fixed with the latest nightly?

My build ID is:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a2pre) Gecko/20090818 Namoroka/3.6a2pre (.NET CLR 3.5.30729) ID:20090818052058
Christian, is the bug fixed for you, too?
Comment on attachment 395274 [details] [diff] [review]
Patch v3

r=wtc.  Thanks.
Attachment #395274 - Flags: review?(wtc) → review+
Keywords: checkin-needed
I could not test Shredder/3.1 any more (accounts not showing up, not being able to use preferences/add accounts, should probably open a bug for this one too), but I tried the latest Shredder/3.0 and was able to activate FIPS: it prompted me to set a master password, then FIPS could be enabled.

Tested with:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090822 Shredder/3.0b4pre

Thanks!
Attached patch Patch v4 (obsolete) — Splinter Review
I added two files to the patch.

1. toolkit/mozapps/installer/packager.mk

libnssdbm3 always exists, so we don't need to test for its
existence before signing it.

2. xpcom/stub/Makefile.in

We don't have link time dependency on libsqlite3 and libsoftokn3.
They are loaded at run time, just like libfreebl3 and libnssdbm3.
Attachment #395274 - Attachment is obsolete: true
Attachment #398736 - Flags: review?(kaie)
Attached patch Patch v5Splinter Review
My change to xpcom/stub/Makefile.in is incorrect, so I removed
it from the patch.

I still think the DEPENDENT_LIBS_LIST variable in xpcom/stub/Makefile.in
needs changing, but it's not essential for this bug.

Note: DEPENDENT_LIBS_LIST is used to generate a text file named
dependentlibs.list for "embedders".  dependentlibs.list is used by the
XPCOMGlueLoadDependentLibs function:
http://mxr.mozilla.org/mozilla-central/ident?i=XPCOM_DEPENDENT_LIBS_LIST
Attachment #398736 - Attachment is obsolete: true
Attachment #398750 - Flags: review?(kaie)
Attachment #398736 - Flags: review?(kaie)
Comment on attachment 398750 [details] [diff] [review]
Patch v5

I pushed this patch to mozilla-central in changeset  2f2d60444774:
http://hg.mozilla.org/mozilla-central/rev/2f2d60444774
This fix is required on the 1.9.2 and 1.9.1 branches, right?
blocking1.9.1: --- → ?
status1.9.1: --- → ?
Flags: wanted1.9.2?
Flags: blocking1.9.2?
This fix is required on the 1.9.2 branch now.

This fix will be required on the 1.9.1 branch
when we land NSS 3.12.4 on the 1.9.1 branch.
Comment on attachment 398750 [details] [diff] [review]
Patch v5

I don't know why Kai hasn't reviewed this patch.  Ted, could you
please review it?  Thanks.
Attachment #398750 - Flags: review?(ted.mielczarek)
Attachment #398750 - Flags: review?(kaie)
Attachment #398750 - Flags: approval1.9.2?
Attachment #398750 - Flags: approval1.9.1.4?
Comment on attachment 398750 [details] [diff] [review]
Patch v5

r=kaie
Attachment #398750 - Flags: review?(ted.mielczarek) → review+
Blocks: 504080
blocking1.9.1: ? → .4+
Keywords: regression
Comment on attachment 398750 [details] [diff] [review]
Patch v5

Approved for 1.9.1.4, a=dveditz for release-drivers
Attachment #398750 - Flags: approval1.9.1.4? → approval1.9.1.4+
Comment on attachment 398750 [details] [diff] [review]
Patch v5

I pushed the patch to mozilla-1.9.2 in changeset 22ca62414e15:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/22ca62414e15
I pushed the patch to mozilla-1.9.1 in changeset a8259fe85982:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a8259fe85982
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Keywords: checkin-needed
Flags: blocking1.9.2? → blocking1.9.2+
Based on all the commentary, it isn't clear how to reproduce this issue. Are the initial repro steps valid for everyone? I see a lot of "I corrupted a file" and "This works fine for me" above.
Attachment #398750 - Flags: approval1.9.2?
Flags: wanted1.9.2?
Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b2pre) Gecko/20091020 Namoroka/3.6b2pre, I still get this exception in the console when I set a master password and then toggle FIPS:

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]

Using the Firefox 3.6 Beta 1 candidate, Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b1) Gecko/20091019 Firefox/3.6b1 GTB6 this does work for me fine.

I also get the error using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091020 Minefield/3.7a1pre, but I know that nothing was checked in on that branch.
I'm reopening this, because with latest trunk (downloaded a couple of minutes ago), this _does_ still occur and a fix is still needed!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sorry, forgot to mention:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100108 Minefield/3.7a1pre (.NET CLR 3.5.30729)

Build-ID: 20100108043818
But it's FIXED on the 1.9.2 branch?
If it would, why does it occur even with the latest trunk?
It doesn't really make sense that this should be fixed on 1.9.2 but not on trunk, being that the same patch was used for both branches. It's possible, though, that there's a different issue on trunk, and that this specific issue has been fixed, being that (I think) trunk is using an updated version of nss. Someone should verify this, one way or another...
Keywords: qawanted, verifyme
Whiteboard: [verify on 1.9.2]
I tried the latest trunk:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20100118 Minefield/3.7a1pre GTB6

I'm also running other builds, and I don't see any problems getting into FIPS mode.
I'm sorry, but I mixed up this bug with #521849 - this is indeed fixed.
Again, I'm sorry for any inconvenience I've possibly caused. :(
Status: REOPENED → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100124 Minefield/3.7a1pre

I can reproduce this exception on today's nightly.  Reopen?
Flags: in-testsuite-
Target Milestone: mozilla1.9.2a1 → mozilla1.9.3a1
Version: unspecified → Trunk
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.