841704 - Firefox crashes on smartcard insertion during SSL authentication

Status: RESOLVED DUPLICATE of bug 550258

(Core :: Security: PSM, defect)

Description

[Alvaro]

Attachment: Firefox Crash Dump

Hi,

We are experiencing a problem with SSL client authentication by smartcard when using Firefox 17.0.1, the browser crashes.
The card we are using is the CPS card, a smartcard used by French healthcare professionals.
This card is managed by a PKCS#11 middleware that is loaded as a Firefox security module.


These are the steps that we follow to reproduce the crash:

- Ensure the PKCS#11 middleware's certificate cache is empty.
- A USB PC/SC card reader is connected to the machine, but without a CPS card inserted.
- Run the browser and load a page (HTTP) that contains a link to the HTTPS test page.
- Insert the CPS card.
- Wait 3 or 4 seconds then click the link to the HTTPS test page (this is a page used specifically for testing the operation of the CPS cards).

Firefox then crashes 2 or 3 seconds later.

We note that the 'Details' button (on the 'Crash Report' dialogue box that is displayed) does not produce or display any information.
However the crash-dump files are attached.

Some technical details:

The PKCS#11 middleware is invoked by Firefox using the C_Initialize() function with the 'pInitArgs' structure initialised as follows:

- The pInitArgs->CreateMutex, pInitArgs->DestroyMutex, pInitArgs->LockMutex, pInitArgs->UnlockMutex are all set with values.
- The CKF_OS_LOCKING_OK flag is set.
- The CKF_LIBRARY_CANT_CREATE_OS_THREADS flag is set.


According to the RSA PKCS#11 v2.20 specifications, page 103, in the case of multi-threaded access, we come under category No 4: 
the middleware can use its own lock functions, even if Firefox provides its own.

Here is what states the specification for C_Initialize() case 4 :

If the flag is set, and the function pointer fields are supplied (i.e., they all have non-
NULL_PTR values), that means that the application will be performing multithreaded
Cryptoki access, and the library needs to use either the native operating
system primitives or the supplied function pointers for mutex-handling to ensure safe
multi-threaded access. If the library is unable to do this, C_Initialize should return
with the value CKR_CANT_LOCK.

We suspect that, in spite of the PKCS#11 specifications, Firefox does not support security modules that manage their own lock functions.

Comment 1

[Scoobidiver (away)]

Please provide the crash ID from the about:crashes page.
Does it happen in the current version that is 18.0.2 (17.0.1 is no longer maintained)?
Does it happen in Safe Mode (see https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode)?

Comment 2

[Alvaro]

Thank you for your reply.

We have reproduced the crash with Firefox 18.0.2 in safe mode.

The last crash ID is : 
bp-dbf2da6c-eaf2-41a4-80b7-93b172130215 

Regards.