318546 - PKCS 11 library for SmartCard prevents Firefox 1.5 from closing properly

Status: RESOLVED INACTIVE

(NSS :: Libraries, defect, P3)

Description

[Michał Niklas]

User-Agent:       Opera/9.0 (Windows NT 5.1; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8) Gecko/20051111 Firefox/1.5  

I have just upgraded my web browser Firefox 1.0.7, to Firefox 1.5.
I use Eutron CryptoIdentity key (PKCS 11 from Siemens CardOS API v.2.4)
with this browser, and while Firefox 1.0.7 works fine,
the new version of Firefox don't close properly.

After some research I have found that browser can close
after removing SI_PKCS11.dll from Firefox 1.5 security devices.
When I add SI_PKCS11.dll browser cannot close.
While closing Windows I get get message that OS cannot
stop "XPCOM:EventReceiver".

After I close Firefox, it disappears from desktop and Task Bar
but Process Manager shows that firefox.exe is still running.
When I start Firefox again I have two copies of firefox.exe
in Process Manager and one copy on my desktop.

I have tested it with two version of drivers form Siemens and both
cause problems.  Old library is CardOS_PKCS11.dll and new is SI_PKCS11.dll.

Version info on both libraries is in additional info

Reproducible: Always

Steps to Reproduce:
1. Open Firefox
2. Close Firefox
3. View processes in Process Manager

Actual Results:  
Firefox disappears from desktop but firefox.exe remains on process list

Expected Results:  
Firefox disappears from desktop and process list

Version info on SI_PKCS11.dll:

c:\windows\system32\SI_PKCS11.dll
on Microsoft Windows XP Workstation version 5.2600

Creation Date: 2005/05/10  13:22:16
Last Modif. Date: 2004/04/07  15:05:02
Last Access Date: 2005/12/01  11:53:05
FileSize: 208896 bytes
Target OS: Win32 API (Windows NT) (0x40004)
File/Product version: 2.0.21.14 / 2.4.0.10
CompanyName: Siemens Informatica S.p.A.
FileDescription: CardOS_PKCS11
FileVersion: 2,0,21,14
InternalName: CardOS_PKCS11
LegalCopyright: Copyright (C) 2000-2004
LegalTrademarks: Siemens Informatica (TM)
OriginalFilename: CardOS_PKCS11.dll
ProductName: CardOS API
ProductVersion: 2,4,0,10
Comments: Author: DevTeam



Version info on CardOS_PKCS11.dll:

Creation Date: 2005/12/01  12:33:09
Last Modif. Date: 2003/06/09  17:08:06
Last Access Date: 2005/12/01  12:33:15
FileSize: 208896 bytes ( 204.000 KB,  0.199 MB )
FileVersionInfoSize: 1988 bytes
File type: Dynamic Link Library (0x2)
Target OS: Win32 API (Windows NT) (0x40004)
File/Product version: 2.0.21.12 / 2.2.0.49
CompanyName: Siemens Informatica S.p.A.
FileDescription: CardOS_PKCS11
FileVersion: 2,0,21,12
InternalName: CardOS_PKCS11
LegalCopyright: Copyright (C) 2000-2003
LegalTrademarks: Siemens Informatica (TM)
OriginalFilename: CardOS_PKCS11.dll
ProductName: CardOS API
ProductVersion: 2,2,0,49
Comments: Author: Fabio Mazzocchi

Comment 1

[Matthias Prager]

I can confirm this Problem - I have Firefox 1.5 installed in combination with the OpenSC pkcs#11 lib. As soon as I insert my SmartCard Firefox produces 100% System load and won't close nor do anything else.

Removing the module helps, but isn't a solution - if I interpret this ( http://www.opensc.org/opensc/ticket/45 ) correctly the newest Version of the OpenSC lib circumvents this problem, perhaps their workaround helps to solve this problem. Unfortunatly OpenSC has only an old SmartCardBunlde 0.5 Version compiled for Windows - since I haven't compiled the new source myself I cannot test if it's working.

Comment 2

[Kai Engert (:KaiE:)]

I can not reproduce your problem on Linux. I do not have a Windows system.

I can exit Firefox 1.5 cleanly, without or without smartcard inserted.

However, I do notice a problem that might be related.
When my system smartcard daemon is running, and while no smartcard is inserted, I get 100% cpu usage in firefox, too. However, everything still works, nothing is being blocked.

Comment 3

[Wan-Teh Chang]

I'm wondering if this has anything to do with the
smartcard monitoring thread, which is a new feature
of Firefox/Thunderbird 1.5.  Bob?

Comment 4

[Robert Relyea]

It could be an interaction. Do either of these smart cards implement C_WaitForSlotEvent()? If they do, and their implementation does busy waiting, that could cause a problem.

The SmartCardMonitoring thread should be well behaved if C_WaitForSlotEvent is not implemented. It instead creates a loop pulling the token and sleeping for a specified interval time. If there is a bug in sleep, or the parameters passed in, that also could cause busy waiting problems.

bob

Comment 5

[Matthias Prager]

Is there anything I can do to help?

I don't have my smartcard configured under my linux system, and I don't have the time to do so right now, so I can just test things for the windows side.

Also, I just wanted to turn your attention again (if not already done) to the opensc-bug-ticket - they seem to have analyzed and partially fixed the issue for the OpenSC lib.

Comment 6

[Michał Niklas]

> Do either of these smart cards implement C_WaitForSlotEvent()?

There is C_WaitForSlotEvent() in SI_PKCS11.dll export table.
Don't know how to check if it behaves well :(
If you have test app I can run it on my machine.

I have reported this bug to Eutron but received only auto-response.
Now test machines with Firefox 1.5 have to use file certificates,
while machines with Firefox 1.0.7 can use Eutron devices.

Michal

Comment 7

[Juha Luoma]

Duplicate of bug 308785?

Comment 8

[Matthias Prager]

Update: With Firefox 1.5.0.3 in combination with SmartCardBundle 0.7-rc2 (library version 0.11.1) this bug seems to be fixed - or at least it works.

Probably because of a workaround that was added to SmartCardBundle (qoute from changelog: "New in 0.10.1; 2006-01-08; Andreas Jellinghaus [...] * fix firefox problems (no real fix, only ugly workaround)".

I don't know weather or not it would still be a good idea to find the reason for this bug in firefox and fix it there, since this might affect other PKS#11 libs as well (if they don't use some kind of workaround too).

Comment 9

[Kai Engert (:KaiE:)]

-> NSS

Should Andreas be contacted to learn about the workaround they used?

Comment 10

[Nicolas JUSTIN]

This bug still exists, at least for me, with Gecko 1.9. I can reproduce this behavior with two PKCS#11 middlewares (Oberthur and Aladdin).
I believe I have spotted the problem, and it only occurs when a nsSmartCardMonitor thread is running and handling events through C_WaitForSlotEvent. Firefox or Xulrunner will only exit properly when a smartcard event is received, insert or remove.

When the exiting process is initiated, SmartCardMonitoringThread::Stop() is called, then SECMOD_CancelWait(), which will call the middleware C_Finalize function, but the middleware is immediately reinitialized with secmod_ModuleInit(mod, &alreadyLoaded) which will prevent the C_WaitForSlotEvent function to exit immediately.
If the secmod_ModuleInit(mod, &alreadyLoaded) is not called (C_Initialize), C_WaitForSlotEvent will exit properly at the end of SECMOD_CancelWait() with the appropriate return code CKR_CRYPTOKI_NOT_INITIALIZED; otherwise it will wait (on PR_JoinThread(mThread) in SmartCardMonitoringThread::Stop()) until an event is received and then returning with a CKR_OK.

Please find as attachment a patch proposal, which use the alreadyLoaded flag to see if we were the last user of this module, if so, another C_Finalize is issued so C_WaitForSlotEvent will exit immediately.
I do not know if this is the proper fix, especially because I do not understand why secmod_ModuleInit() is called; but it works for me :-)

I also think that bug 308785 and bug 292699 are duplicate of this ticket.

Comment 11

[Nicolas JUSTIN]

Attachment: Proposed patch

Comment 12

[Robert Relyea]

Comment on attachment 331112 [details] [diff] [review]
Proposed patch

So here's the problem with this. If we are in this code, with a valid 'mod', it means we still have outstanding references to 'mod', and code expects the module to be there and initialized. Calling C_Finalize will always finalize the entire module, alreadyLoaded will always return FALSE, even if there were 'someone' using the token still. The semantics of CancelWait is such that we need to return with the token in the same state that we entered cancel wait (that is initialized or not).

If this actually fixes your problem, then there are 2 possible true sources of the error....

source 1, a reference leak. If mozilla is still holding on to so much as a single key or cert associated with the token (or NSS failed to release such a reference), then your token's C_Finalize will never get called (and the mod structure will leak).

The other possibility is for some reason the SECMOD_CancelWait is being called after we free up the mod. This seems unlikely, since we free the mod structure shortly after finalizing on the module. One would also expect C_Finalize to fail in this case, but it is possible there is some funky code path that allows this to happen.

I would suggect setting the NSS_STRICT_SHUTDOWN environment variable and try your test. If mozilla crashes on shutdown, then you have a reference leak.

bob

Comment 13

[Loopkin]

Actually, whatever the exact cause of the problem is, the proposed patch is interesting: there are multiple PKCS#11 libraries out there, lots of them being of bad quality. Therefore, IMHO, any patch tending to isolate more FF from these libraries is a Good Thing (TM). If i understand correctly, this patch forces C_Finalize whatever the token and FF status are, when closing FF. This is good, because the reference leak (or whatever the real cause is) could be caused by the PKCS#11 library bad behaviour in the first place.

However, since this behaviour seems to be triggered with any the PKCS#11 library, it's almost certain that there's a bug somewhere else in FF. Since:
- nobody seems to dig into FF to find the problem, 
- IMHO, the proposed patch is good anyway (see my previous §),
- the patch works for me.
I vote for comitting this patch.

Comment 14

[Carlo]

I confirm Bug 318546 and bug 415414 (the same problem). It is a very serious problem for me.
I'm a Firefox user since the first release of this excellent browser. I want to report you about a problem I am encountering. I have just installed a  security module called SI_PKCS11.
I had to do it because it is required for a smart car I need to use for my job.
The problem is that now Firefox browser (both 2 and 3 release), after being  closed, remains open in a hidden session and you need to use Window's Task manager in order to close it.
Sometimes, on Task manager, I find 2, 3 and even more open hidden sessions.
This is a very annoying problem because it slows my work.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to Carlo from comment #14)

I confirm Bug 318546 and 415414 (the same problem).

Bug 415414 was closed invalid "There was ruToken's bug. Now it works fine with new PKCS#11 module from ruToken developers."

Comment 16

[Wayne Mery (:wsmwk)]

Reasonably certain everyone here is gone, no updates in 12 years, and related bugs are closed.
Any reason to believe this still exists?

Comment 17

[Kevin Jacobs [:kjacobs]]

(In reply to Wayne Mery (:wsmwk) from comment #16)

Reasonably certain everyone here is gone, no updates in 12 years, and related bugs are closed.
Any reason to believe this still exists?

Almost certainly not. Let's close it.