Closed Bug 444974 Opened 16 years ago Closed 16 years ago

Crash upon reinsertion of E-Identity smartcard

Categories

(NSS :: Libraries, defect, P1)

Product:
NSS
Component:
Libraries
Version:
3.12.1
Platform:
x86
Windows Vista
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
3.12.2

People

(Reporter: mrajnoch, Assigned: nelson)

References

Details

(Keywords: crash, regression)

Attachments

(4 files)

Screenshot of Firefox 3.0.2 crash explanation
157.45 KB, image/png
Details
Requested secmod.db file
16.00 KB, application/octet-stream
Details
stack trace of crash
2.50 KB, text/plain
Details
Stop assuming session pointers are non-NULL (checked in)
18.14 KB, patch
rrelyea
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Secure Connection Failed just with FF3 (never happen with FF2)
root CA is correctly imported in "Authorities" section in "Certificate Manager"
into "Software Security Device" and also automaticly added with smartcard security device 'Aladdin eToken' (module: eTPKCS11.DLL). Smartcard is required for SSL client verification.
Also bypass with 'security exception' doesn't work (server certificate added in 'Servers' section in "Certificate Manager") - however, if  sec_error_unknown_issuer error occured, and I select "Or you can add an exception…" I got "This site provides valid, verified identification. There is no need to add an exception." what is opposed.

I tried another smartcard (actividentity activkey - module acpkcs201-ns.dll, and OKSmart with module okpkcs11.dll, ) with the same result.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
I remember seeing a report of this before - a security error that handed off to our exception dialog, which saw no problem with the cert (and hence wouldn't add an exception) but I'm failing to find it right now.  Anyhow, moving this to the right component.
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
same error also occures on this page (https://bugzilla.mozilla.org/show_bug.cgi?id=444974), when I click on the link in e-mail. Without using any token/smartcard.

bypass with 'security exception' doesn't work, and of course is not needed at all,
but was proposed cause sec_error_unknown_issuer error occured.

strange.
We get this error too.  We have Argos Mini II smartcard readers from Todos Data System AB in Sweden, issued by Hypothekarbank Lenzburg to its customers in Switzerland.  The bank supplies driver v2.5.2.9 for the reader, but I've upgraded to the driver v3.3.0.0 on the todos.se website, without improvement.  Hypothekarbank Lenzburg supplies its own self-signed Root Cert, which must be manually installed.  All of this works flawlessly under Firefox 2.x, and unreliably under Firefox 3.0.1.  The symptom is that if the reader and smartcard are plugged in, then sometimes, but not always, when visiting an https site we see a panel

  Secure connection failed
  foo.baz.com uses invalid certificate
  Error code: sec_error_unknown_issuer

and the panel offers the option to add an exception.  When we try to add an exception, we can't, because on closer inspection within Firefox the certificate is valid after all.  But we can't proceed, either.  An apparently bulletproof work-around is to shut down all Firefox windows, unplug the smartcard reader, and restart Firefox.
Is there any relation between the https sites you are visiting and the "Lenzburg" root CA certificate? Are the authority certificates visible in the certificate viewer when your eToken is loaded?
I have seen it both ways.  Sometimes it complains about a certificate from hbl.ch (Hypothekarbank Lenzburg), and sometimes about others.  A few days ago, for example, we got a sec_error_unknown_issuer on a certificate presented by wb1.ubs.com.  The root of its chain of trust is the browser's built-in Verisign Class 3 Public Primary Certificate Authority.

Side comment: Goodness knows why Hypothekarbank Lenzburg imagines they need to be their own CA.  Worse yet, they transport replacement root certs to you via http.  It's like sending the keys to the national gold reserves by bicycle courier.  Fortunately, it's a small bank, and a relatively small number of their customers use their security hardware (most of their online banking uses strike lists), so there are much more lucrative targets for Internet criminality.  In other words, security by obscurity.  The risk is that if you ever install a fake root cert, it can hang around for a long time, you'll probably never know it's there, and it can be used to "validate" very dangerous websites.

I'm running Firefox 3.0.1, my Hypothekarbank Lenzburg e-Identity eToken is now loaded and logged in (Tools > Options... > Advanced > Encryption > Security Devices > HBL E-Identity > Log In), and I can see the Verisign Class 3 Public Primary root cert and the four (!) different Hypothekarbank Lenzburg root rerts (Tools > Options > Advanced > Encryption > View Certificates > Authorities).

On the other hand, the problem is sporadic.  The next time it happens, I'll capture the "offending" certificate and dig for roots in the certificate viewer before restarting Firefox.  Stay tuned...
It happens from time to time that servers aren't configured correctly and don't send the complete chain. If it happens again please check (and make a screen-shot perhaps) if the issuer CA certificate is indeed a root in the authorities store and not an intermediate CA. If an intermediate CA signs the EE cert, but the server doesn't send out the full chain sec_error_unknown_issuer happens. In that case you should contact the server administrator.
The problem happened again today, and this time I got a pretty clean trace of screen shots.  As background, I had been using this Firefox 3.0.1 window for hours, and the Hypothekarbank security hardware (Todos Argos card reader and HBL E-Identity card) had been connected, but I hadn't been using it.  I was ordering some photo prints, and reached the payment stage.  When I clicked to pay with a credit card, not involving the security hardware, the error window popped.  I'm still new to tho bugzillao, so I'll just post my diagnostic files here, if you don't mind:

  http://web.mccreight.com/bugzilla/444974/www.saferpay.com_13sep2008/

The files step1.png through step6.png are the successive steps through the error boxes.  The file www.saferpay.com.crt is the "offending" certificate delivered by the error dialog boxes.  In the end, my only working option in Firefox was "Get me out of here!".

Once out of the error boxes, I set off to examine Firefox' certificate store as you suggested.  The files crypto1.png through crypto9.png are successive screens of that.

My first surprise was that my Hypothekarbank hardware wanted its PIN just in order that I be allowed to view Firefox' certificate store.  The second surprise was the complexity of my security devices and modules.  I had forgotten to mention earlier that I also have a Swiss Post security token.  It was installed a long time ago, I seldom use it, and neither its smart card nor its OMNIKEY Cardman card reader had been connected since the last system reboot, but you can see them in the security devices and modules.  Apparently both card readers are listed under each security token, but when a smart card is plugged into a reader, the name of the reader changes to the name of the smart card.  In this case, Todos Argos ... changed to HBL E-Identity.

After satisfying myself that the right roots were present in my certificate store, and closing the Options... boxes, I tried, without making any other changes, to browse to https://mail.google.com/a/mccreight.com.  The same sec_error_unknown_issuer error happened.  I dismissed it with "Get me out of here!".

Then I simply unplugged the Hypothekarbank Lenzburg E-Identity smart card from the Todos Argos Mini II USB smart card reader, and tried accessing https://mail.google.com/a/mccreight.com again.  Nooo problem!
Thanks for the thorough explanation and screen shots. I checked out the web sites you tested, doing so with an Aladdin smart card and Athena reader without any problems. Due to your description I suspect that something isn't quite right with the Omnikey driver or the presence of the CA certificates in the smart card somehow interfere with the proper functioning of the NSS module.
Since I've only certificates issued from a BUILTIN CA root, any CA certificate on the token has no negative effect. Perhaps some more testing is required to rule out a bug by NSS.

Did you try to import the various CA roots into the NSS authorities software device and remove them from the smart card?
As best I can tell, there's only ever one certificate in the Hypothekarbank Lenzburg E-Identity smart card: a "Your Certificates" client-side cert.  Its validator is the HBL eBanking CA cert, whose validator is the HBL Root CA self-signed cert.  Those latter two are installed in the Firefox certificate store either by the HBL-provided installation CD or else manually from http://www.hbl.ch/zertifikate.html (the keys to the gold reserves delivered by bicycle courier).  Both are indeed present in my "Authorities" section with a Security Device of "Software Security Device".
Further observation: We believe that whenever we hit a bogus sec_error_unknown_issuer error, the Hypothekarbank Lenzburg E-Identity card is plugged into its Todos Argos USB card reader.  To get past the error, if we unplug the card from the reader, click Firefox's Back button, and then redo whatever we tried to do before, that always seems to work.
I have a testable hypothesis.  
I suspect this is another manifestation of Bug 444850, which is partially
(mostly) fixed in NSS 3.12.1 RC2, which is used in FF 3.0.2 Build 5.
So, this _may_ be already fixed in FF 3.0.2.  
I understand that pre-release builds of FF 3.0.2 are available for testing
(or perhaps, unknown to me, FF 3.0.2 is out now).  So I suggest that the 
people who experience this try FF 3.0.2 pre-release versions.  If that 
solves the problem, then that result will effectively prove my hypothesis.
If that does not solve the problem, that result does not necessarily 
disprove my hypothesis, but may only indicate that the "fix" in NSS 3.12.1
is incomplete (which we already know).  In that case, more diagnostic steps
will be suggested.

The problem, by the way, is that NSS goes looking through all the PKCS#11
modules and slots for certificates while building a certificate chain.
If any PKCS#11 module misbehaves, and returns a "fatal" error rather than 
normally completing the search for certificates, NSS gives up and stops
trying to build the chain.  The fix was to simply ignore the failed  
PKCS#11 module and go on trying the other PKCS#11 modules to complete the
search for the certificates with which to complete the chain.  

Now, this is actually caused by a PKCS#11 module misbehaving.  But NSS 
should be able to withstand such behavior and go on.  And in 3.12.1, it
does so in most (not all) circumstances).
speaking for myself only, #ifdef DEBUG_nelsonb appears in only 3 places in NSS.
Two of them can be deleted.  One can be converted into simple ifdef DEBUG, I think.

In sslsnce.c, these lines can be deleted:

1182 #if defined(DEBUG_nelsonb)
1183     printf("sizeof(sidCacheEntry) == %u\n", sizeof(sidCacheEntry));
1184 #endif

In selfserv.c, these lines can be deleted:

2064 #ifdef DEBUG_nelsonb
2065         WaitForDebugger();
2066 #endif

and the following #ifdef can be converted to #ifdef DEBUG

1769 #ifdef DEBUG_nelsonb
1770 
1771 #if defined(XP_UNIX) || defined(XP_OS2) || defined(XP_BEOS)
1772 #define SSL_GETPID getpid
1773 #elif defined(_WIN32_WCE)
1774 #define SSL_GETPID GetCurrentProcessId
1775 #elif defined(WIN32)
1776 extern int __cdecl _getpid(void);
1777 #define SSL_GETPID _getpid
1778 #else
1779 #define SSL_GETPID() 0   
1780 #endif
...

and the following function WaitForDebugger can be deleted.
D'oh!  comment 12 was added to the wrong bug.  sorry.

Ed & Marcos, in case it wasn't obvious, I'm asking you to do the test 
described in comment 11.
Right, I will do that test, and thanks for the explanation.  It makes sense.  I believe the Hypothekarbank Lenzburg E-Identity security hardware contains only a single public client-side cert, together with its matching private key.  Their security subsystem uses a manually-input PIN, input through a dialog box.  The PIN seems to time out after a few hours.

I would imagine that a recently input PIN should only be required if the hardware is being asked to use its private key, to sign or to decrypt.  So theoretically, for example, when the question is asked, "Do you have any root certs I should know about?", the hardware's driver should answer "No" immediately without regard to a PIN.  In practice, at a time when that question would be reasonable and milliseconds later I see a bogus sec_error_unknown_issuer error, I often see the PIN dialog box.

I'm curious.  MisterSSL, could you point me to documentation of the API that Firefox expects security hardware/drivers to implement?  Is that API the Smart Card Module Functions of the Microsoft CryptoAPI?
If I tried the nightly build of firefox-3.1b1pre.en-US.win32.installer.exe, would that tell you what you need to know?  Otherwise, could you give me a clear pointer to the installer you'd like me to try?
In reply to comment 15,
Eddy, Can you provide Ed with a URL for downloading FF 302pre?

In reply to comment 14,
Ed, Most smart cards, crypto accelerators and "hardware security modules" 
require authentication before they allow access to ANY of their storage
or crypto engines.  Some (few) do allow access to stored objects marked 
as "public", without authentication.  Such devices are said to be "friendly"
devices.  NSS's own PKCS#11 modules are friendly.  Most others are not.

There is no way for a device to tell NSS that it is "friendly" or not.  
NSS assumes that devices are NOT friendly unless it is configured to 
know that they are friendly.  For an unfriendly module, NSS/PSM will 
prompt the user to authenticate before first use, even if that use is a 
mere search for certificates.  I suspect that your device is not marked
as "friendly" even if it actually is friendly.  

Bob Relyea and/or Kai Engert should probably write a few words here about 
how PKCS#11 modules are marked friendly using PSM's device manager UI.

The interface specification used for all crypto devices is Public Key 
Cryptography Standard number 12 (PKCS #12), which is an OS-independent
and vendor-independent standard.  Mozilla uses it on all platforms.
See http://www.rsa.com/rsalabs/node.asp?id=2133 for the spec
Oops!  It's PKCS#11, not PKCS#12.  Sorry.
PKCS#12 is a file format for storing private keys and their related certs.
The URL I gave above is the correct one for PKCS#11.
I have an additional request for the people who are able to reproduce this 
problem.  Please find the file named secmod.db in your profile directory,
and attach it to this bug.  If you're not already familiar with your 
profile directory, you can find information about the location of that 
directory on the web page http://support.mozilla.com/en-US/kb/Profiles
You could also just search your hard drive for files named secmod.db, but
you might find more than one, and we want the one from your current 
browser profile's directory.
OBTW, the secmod.db file doesn't contain any keys or certificates or other
really confidential information.  It contains the configuration information
for the library that operates your smart card (reader).
Pre-release nightly build of FF 3.0.2, crashed on https://mail.google.com/... link, security hardware attached with PIN probably timed out.
Requested secmod.db file, which did not change with the update of FF 3.0.1 to FF 3.0.2.  Theoretically, this file describes two USB-connected hardware security products, one from Hypothekarbank Lenzburg, and the other from the Swiss Post.
OK, so I installed nightly build pre-release Firefox 3.0.2, plugged in my Hypothekarbank Lenzburg security card, logged in the card with Tools > Options... > Advanced > Encryption > Security Devices > HBL E-Identity > Log In, and visited my bank's website.  All normal.  Then I continued to browse and compute for a couple of hours (during which the PIN might have timed out).  Then I clicked on an https://mail.google.com/... link and blammo!  Attachment id 339032 above is what Microsoft told me straightforwardly about the problem.  I also let Microsoft collect and ship the crash report; do you guys have any way of reading those collected crash reports?
Ed, thanks for the secmod.db file.  It disproves my hypothesis that the
cause of bug 455554 was also the cause of this bug.  

Firefox has its own crash reporter, which reports crashes to Mozilla. 
If that ran for you, then the results may be available to Mozilla, 
but if your results really went to Microsoft, then we have no access.

I think that one may conclude from your comment 25 that, apart from some 
crash that may or may not be related, the use of FF 302pre resolved the 
unknown issuer problem.  Do you concur?
To clarify a bit, I've had two hypotheses:
a) cause is related to bug 455554 - this is now disproved.
b) cause is related to bug 444850 - comment 24 seems to confirm this.

In comment 25, I wrote "...conclude from your comment 25".  
Of course, I meant "your comment 24".
In response to comment 25 above, I really can't say whether FF 302pre resolves the bogus sec_error_unknown_issuer problem or not.  In the first place, the bogus sec_error_unknown_issuer problem occurred only sporadically with FF 301, perhaps after a formerly valid PIN for the E-Identity hardware had timed out.  In the second place, the crash of FF 302pre occurred at just such a moment as I would have imagined a bogus sec_error_unknown_issuer under FF 301.
(In reply to comment #19)
> I think that would be [3.0.2build5]

We're testing build6 now, a re-spin for bug 454406 plus a roboform (addon) crash.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/build6/
The http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/build6/firefox-3.0.2.en-US.win32.installer.exe dated 17-Sep-2008 11:47, which I presume to be Build 6, is dead on arrival for my E-Identity hardware.  The following is completely reproducible:

  1) Launch FF,
  2) Plug in the E-Identity card,
  3) Browse to https://mail.google.com/a/mccreight.com/#inbox (for example;
        apparently the only important thing is https),
  4) FF crashes.

I sent in a crash report with a pointer to this bug.

If I don't plug in my E-Identity card, or if I don't browse to an https:// link, FF behaves normally.
Ed, do you have the crash report identification number?
The file in my Crash Reports\submitted directory says

Crash ID: bp-31f04e2e-861c-11dd-a19e-001a4bd43ef6
You can view details of this crash at http://crash-stats.mozilla.com/report/index/31f04e2e-861c-11dd-a19e-001a4bd43ef6?date=2008-09-19-07
The crash occurs at 
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/dev/devtoken.c&rev=1.50&mark=311#311
seen below

307     nssSession *session = (sessionOpt) ? sessionOpt : tok->defaultSession;
308 
309     /* Don't ask the module to use an invalid session handle. */
310     PORT_Assert(session->handle != CK_INVALID_SESSION);
311     if (session->handle == CK_INVALID_SESSION) {
312         ckrv = CKR_SESSION_HANDLE_INVALID;
313         goto loser;                
314     }

Evidently, tok->defaultSession is NULL, leading to a crash trying to 
dereference its value at line 311.  

This proves my hypothesis from comment 11, that "this is another 
manifestation of Bug 444850", and it tells me that the "fix" for that bug
didn't go far enough.  There are still cases where unexpected PKCS#11 module 
behavior makes NSS misbehave.  

I wish I could get a card and reader and software like yours, so that I 
could debug it here.  I'm guessing that won't likely be possible.  
The next best thing is to get you some software that would trace the 
activity between your browser and the software for your smart card.
Perhaps we can understand what's going on from that trace output.
(In reply to comment #29)
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/build6/firefox-3.0.2.en-US.win32.installer.exe
> dated 17-Sep-2008 11:47, which I presume to be Build 6, is dead on arrival for
> my E-Identity hardware.  The following is completely reproducible:
> 
>   1) Launch FF,
>   2) Plug in the E-Identity card,
>   3) Browse to https://mail.google.com/a/mccreight.com/#inbox (for example;
>         apparently the only important thing is https),
>   4) FF crashes.

Is this the same hardware you were using with 3.0.1 all along? You're saying we managed to turn unreliable/failing cert authentication (few sites) into a crash on any and every SSL site (hundreds of thousands) in 3.0.2?

anyone fancy another 3.0.2 rebuild? relnote it?

Nelson: you say this is related to bug 444850, but that bug was written against NSS 3.11 which is used in Firefox 2. Both Maros (comment 0) and Ed (comment 3) say they never had a problem with Firefox 2.

You also said Ed's symptoms showed the fix for 444850 "didn't go far enough", but that bug is not marked fixed and there's still an unreviewed patch in the bug. Are parts of it in 3.12.1 ? (I see some checkins, but it's unclear to me which NSS tags they made it into).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.2?
Keywords: regression
Summary: Error code: sec_error_unknown_issuer - with smartcard usage and correctly imported Root CA → Error code: sec_error_unknown_issuer - with smartcard usage and correctly imported Root CA (crash in 3.0.2)
Maybe the new crash in 3.0.2 that appears to be a regression from the NSS upgrade ought to get a separate bug.
It's the same Hypothekarbank Lenzburg E-Identity hardware I've had for years.  IE never had a problem with it, nor did Firefox 1 or 2.  We started seeing the bogus sec_error_unknown_issuer messages in FF 3.0 and they continued in FF 3.01.  What's new with FF 3.02pre is that Firefox crashes.

I don't think it ever had to do with what https:// website I visited.  I think it had to do with whether the E-Identity hardware needed a PIN.  In 3.0 and 3.01 I speculate it only happened when the PIN needed to be renewed.  In 3.02 I speculate it happens whenever an E-Identity PIN is needed, even for the very first https:// URL.

In addition, I never saw FF 3.0 or 3.01 crash; they just hit a bogus sec_error_unknown_issuer dead end.  You could hit the Back button, remove the E-Identity card, click again on the https:// link, and as long as you weren't trying to go to https://www.hbl.ch, you were fine.  FF 3.02pre really crashes.
Dan,
NSS has had a number of long-standing, but only recently discovered, bugs
in its handling of PKCS#11 modules that misbehave.  These bugs are all 
triggered by an unkosher behavior of a PKCS#11 module.  They include:
- NSS gets into internally inconsistent states when a module claims to 
have a token in an impossible state (unremovable, but removed), or when
a module fails to do the most basic and fundamental operation, creating 
a "session" for future operations. In such cases, NSS constructs entire
object hierarchies on the foundation of a PKCS#11 session that does not
exist.  
- NSS terminates operations prematurely, giving up after a PKCS#11 module
fails, rather than going on and trying the other PKCS#11 modules. 

The bug described in comment 0 is exactly one of those issues.  A PKCS#11 
module that returned an error (rather than a mere negative result) when 
asked to search for a certificate that it doesn't have caused NSS to abort 
the search through all the modules for the certificate, resulting in an
erroneous report of "unknown issuer", because the issuer certificate was 
not found, due to the aborted search.  

bug 444850 exists to cover all of those bugs presently known.  It is a 
compound bug, describing a number of distinct problems, all in the category
of NSS misbehavior triggered by PKCS#11 module misbehavior.  Perhaps that 
bug should be broken up into separate bugs for separate issues, and that 
bug should serve as an umbrella bug.  

Bug 444850 is reported against an older release than 3.12, because these 
problems are problems in the original code for working with PKCS#11 modules, 
added in NSS 3.4, IINM.  It is also targeted against NSS 3.11.x because we 
intend to fix all those issues in both NSS 3.11.x and 3.12.x.  It is the 
practice of the NSS team to target bugs against the smallest version number
in which a fix will appear.  So a bug targeted against 3.11.x will generally
also be fixed in the trunk, but a bug targeted against 3.12 will not also 
be fixed in 3.11.x.

The problem originally reported in this bug was one of the issues described 
in bug 444850, and as such is a duplicate of bug 444850.  A fix for one of 
the symptoms described in bug 444850 has been committed to both the NSS 
3.11.x branch and the trunk (3.12.x).  That fix fixes the original symptom
described in this bug.  However it appears that fixing one bug has unmasked
another.

I could just mark this bug as a duplicate of bug 444850, and file a new bug 
about the crash, but I choose instead to let this bug serve as the new bug 
for the new crash.  

As part of the work done for bug 444850, NSS now detects many of these
PKCS#11 failures earlier, and so avoids constructing these object hierarchies on a non-existent foundation.  As a result of that, we are now find bugs in
other code that depended on that formerly buggy behavior.  There is code that
depends on the fact that the object heriarchies were created even when the 
foundation was absent.  That code now crashes in the absence of the object 
hierarchies.  It doesn't test for their presence before using them.  

I plan to fix that PDQ.  There is a discussion of this issue in bug 444850 comment 79.  (Perhaps that discussion should take place in this bug instead.)
It is relatively straight forward to find all the functions that assume 
that certain objects exist, and change them to test for its presence.  
However, those functions SHOULD NOT be called at all under these circumstances.
It is reasonable for those functions to assume what they assume, because they
should never be called unless that assumption is true.  Indeed, they should
ASSERT that the condition is true.  

I would like to fix the higher level bug, that causes these functions to be 
called when they should not.  However, doing that will take longer (I fear) 
than the quick-and-dirty low level test, so I will do that first.
Assignee: kaie → nelson
Component: Security: PSM → Libraries
Priority: -- → P1
Product: Core → NSS
QA Contact: psm → libraries
Summary: Error code: sec_error_unknown_issuer - with smartcard usage and correctly imported Root CA (crash in 3.0.2) → Crash upon reinsertion of E-Identity smartcard
Target Milestone: --- → 3.12.1
Version: unspecified → 3.12.1
Oh, I meant to reiterate that all this is due to PKCS#11 modules that don't
behave as one would predict based on the PKCS#11 specification.  I have a 
smart card that I use frequently, inserting and removing it, and I do not
experience this crash with NSS 3.12.1.1.  Presumably this is because my 
PKCS#11 module is behaving as the specification indicates.
I need to test this a bit more before requesting review.
Hmm what worries me about this bug is it's happening on token reisertion, which means the token is in, why doesn't it have a valid session?

bob
Comment on attachment 339706 [details] [diff] [review]
Stop assuming session pointers are non-NULL (checked in)

I've tested this with one of my smart cards (Aladdin eToken) and it doesn't crash for me, but then, it didn't crash without this patch, either.  

Bob, please review.
Attachment #339706 - Flags: review?(rrelyea)
I sent Ed McCreight a debug build to test the fix in the patch above.
He reports that, with it, he is able to use his Estonian ID card with
his bank without crashing.  

He reports that, after removing and reinserting his smart card, he is not 
prompted to log in to his smart card again. His bank server treats his 
client as if he does not have a cert, asking him to authenticate with a 
password.  Even if he manually logs in with device manager, his bank's
server will treat his browser as if he does not have a client cert until
he restarts the browser.  However, he reports that that behavior is not
new in FF 3.0.2, so it is outside the scope of this bug.
Comment on attachment 339706 [details] [diff] [review]
Stop assuming session pointers are non-NULL (checked in)

r+

These changes are all safe and are less likely to crash than the existing code.

I did not review if everything was caught or if each change was really necessary.

The other clean up changes are all semantically identical, so no problem there.

This patch does add a potential error return without setting an error code in pk11_fastCert(). I'll preapprove a change that adds an else { PORT_SetError(); } (appropriately formated) to the added if.

bob
Attachment #339706 - Flags: review?(rrelyea) → review+
Comment on attachment 339706 [details] [diff] [review]
Stop assuming session pointers are non-NULL (checked in)

Checking in dev/ckhelper.c; new revision: 1.38; previous revision: 1.37
Checking in dev/devtoken.c; new revision: 1.51; previous revision: 1.50
Checking in dev/devutil.c;  new revision: 1.32; previous revision: 1.31
Checking in pk11wrap/dev3hack.c; new revision: 1.25; previous revision: 1.24
Checking in pk11wrap/pk11cert.c; new revision: 1.168; previous revision: 1.167

I made the change you suggested in your last comment, Bob.
Attachment #339706 - Attachment description: Stop assuming session pointers are non-NULL → Stop assuming session pointers are non-NULL (checked in)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: 3.12.1 → 3.12.2
Blocks: 293319
So this fix is checked in, but that doesn't actually help Firefox users until we update the version of NSS we pull. Is there another bug that makes that change, or should that be a patch here?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.4?
Flags: blocking1.9.0.2?
Keywords: crash
In reply to comment 46,
There should be a "core" bug that calls for the core makefile that pulls
NSS to pull a different tag.  And, of course, there should be a new tag 
to pull. :)  

Dan, what's the expected timeframe for the next 190x FF release?
The wiki currently has code freeze at October 24, however, we'd want to take a new NSS at least a week before that.

See also: https://wiki.mozilla.org/Releases/Firefox_3.0.4

(These things should always be on https://wiki.mozilla.org/Releases for what it's worth. If they're not, it means we're firedrilling and too busy.)
Blocks: 444850
Today I was auto-updated to public FF v3.0.4, and the bug is still present in the public release.  Fortunately when I replace the updated application's nss3.dll file (unchanged since v3.0.2) with a workaround nss3.dll file available from Nelson Bolyard, the bug goes away for me, as it did in earlier versions.  Nelson, any idea when the fix will become part of the public release?

As Nelson and I discussed privately last month, Hypothekarbank Lenzburg believes that it has about 1500 to 2000 instances of this security hardware in use among its customers.  Mine, however, is the only complaint they've received regarding FF 3.x crashes.  I've been puzzling over how that could possibly be the case, given the relative popularity of Firefox 3.

The only idea I've had is a possible problematic interaction with the installed driver for a *second* USB-interfaced security token that I also own, from the Swiss Post.  The Post token was never plugged in during the experiments reported above, but its driver (called "OMNIKEY CardMan 6121 0") was installed, and is listed along with the driver for the Hypothekarbank Lenzburg E-Identity card (called "Todos Argos Mini II USB 0") in the Tools > Options... > Advanced > Encryption > Certificates > Security_Devices > Security Modules and Devices list.
Ed, I'm sorry that the fix has not yet made it into Firefox 3.  I thought 
that would have happened by now.  I cannot tell you with any certainty when
it will happen, but I continue to believe (or at least hope) it will be 
"soon", meaning, in the time frame of the next release or two.
Depends on: 465270
Flags: wanted1.8.1.x?
A very similar bug has re-emerged in the public releases of Firefox 3.5 - 3.5.1 for XP.  The symptom is that when I browse to

  https://ebanking.hbl.ch

with my smart card all connected and ready, I get a pop-up box asking for the smart card's PIN, but after I input and confirm the PIN, the browser (including all windows I had open) hangs.  If I then use the Windows Task Manager to kill Firefox, wait until everything quiets down, and then re-launch Firefox, everything works normally until I try browsing to

  https://ebanking.hbl.ch

again, when the problem repeats.

I have found a work-around.  The problem seems to be in the auto-login of the security device.  If, before browsing to the deadly URL, I go to

  Tools > Options... > Advanced > Encryption > Security Devices

and manually log in to the HBL E-Identity Security Device, then I can browse the deadly URL normally.

A couple of weeks ago I tried resolving this by sending an email directly to Nelson Bolyard, but I haven't heard back from him, so now I'm announcing it more broadly.  Is this posting enough, or should I post a new bug and refer for background to this one, or what?
this fix was in firefox 3.0.5 and any version of firefox 3.5+, please file a new bug.

https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
!analyze -v -hang
Hi Ed, good to hear from you.  The most recent email I have from you is 
dated 2008-09-29.  Perhaps you didn't get the message about my change of
email address which happened last November.  You'll find my new email 
address in the email that notifies you of this comment. 

Please do file a new bug about this new problem, and put my current email 
address on the bug's CC list.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: