316167 - Mozilla crashes when cryptoki.dll is loaded (PKCS#11)

Status: RESOLVED INCOMPLETE

(NSS :: Libraries, defect)

Description

[Maciej Fuchs]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051107 Firefox/1.5

Firefox 1.5 RC2 Crashes when loading cryptoki.dll 


Reproducible: Always

Steps to Reproduce:
1. Go to: Tools/Options/Security Devices
2. Press Load and select cryptoki.dll
3. Press OK button
Actual Results:  
The instruction at "0x00000000 referenced memory at "0x00000000". The memory could not be "read".

Expected Results:  
The dll is loaded without message

Comment 1

[Adam Guthrie]

Could you install with talkback and get a talkback ID for the crash? http://kb.mozillazine.org/Talkback

Comment 2

[Wan-Teh Chang]

What is cryptoki.dll?

Comment 3

[Hermann Schwab]

http://www.google.com/search?q=cryptoki.dll

https://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/pkcs_11_provider/quick_start
https://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/pkcs_11_provider/using

Comment 4

[Hermann Schwab]

Dupe of Bug 292809 ?
NSS treatment of CKR_CRYPTOKI_ALREADY_INITIALIZED may be incorrect

see Bug 292809 comment 2

another cryptoki bug: Bug 265620
Use buffer to reduce C_DigestUpdate calls to Cryptoki during SSL handshake

https://jce.iaik.tugraz.at/sic/products/core_crypto_toolkits/pkcs_11_wrapper
PKCS#11 Wrapper

This is a Java library which makes PKCS#11 (also known as Cryptoki) modules accessible from within Java. A PKCS#11 module is a software library with a defined API which allows access to cryptographic hardware. It usually comes with hardware security modules (HSM), smart cards and crypto tokens (e.g. USB tokens). Thus, the PKCS#11 Wrapper provides Java software access to almost any crypto hardware. 

Comment 5

[Robert Relyea]

Please provide a stack traceback.

Mozilla should still be processing 'CKR_CRYPTOKI_ALREADY_INITIALIZED' as an error. A full stack traceback should indicate whether or not this is occuring.

Thanks.

bob

NOTE: accessing PKCS #11 modules directly from the process address space of Mozilla is not supported for the reasons sighted in Bug 292809. The solution provided in Bug 292809 is not extensible to Mozilla because it presumes, a priori, that all PKCS #11 modules *Must* be threadsafe. This assumption does not hold for those modules which have traditionally been used by Mozilla (e.i. placing that restriction would cause regressions in a large number of already functioning pkcs #11 modules.)

Comment 6

[Maciej Fuchs]

(In reply to comment #1)
> Could you install with talkback and get a talkback ID for the crash?
> http://kb.mozillazine.org/Talkback
> 

requested info: TB11953962Q

Comment 7

[Hermann Schwab]

TB11953962Q is showing only one symbol: SECMOD_WaitForAnyTokenEvent 
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib/pk11wrap/pk11util.c&mark=1078&rev=MOZILLA_1_8_BRANCH#1078

It seems to crash in C_WaitForSlotEvent(), though there is a test before to prevent calling C_WaitForSlotEvent() in a cryptoki version where it doesn't exist.

Function starts here:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/security/nss/lib/pk11wrap/pk11util.c&mark=1078&rev=MOZILLA_1_8_BRANCH#1049


/* if the module is version 2.0,
1066                                       * C_WaitForSlotEvent() doesn't exist */

Comment 8

[Adam Guthrie]

Does this crash in trunk builds? I'm thinking you could be seeing bug 308727, which had a fixed checked into trunk, but not branch.

Comment 9

[Wan-Teh Chang]

The fix for bug 308727 is in Firefox 1.5 RC 1 or later.
Since this bug was originally reported in RC 2, this
bug can't be a duplicate of bug 308727.

Maciej, who is the vendor of cryptoki.dll and which
cryptographic token is cryptoki.dll for?

Comment 10

[Wan-Teh Chang]

It is also possible that the fix for bug 308727 is
not effective for cryptoki.dll.  Perhaps cryptoki.dll
reports its CryptokiVersion incorrectly and doesn't
implement the C_WaitForSlotEvent method.  Strictly
speaking, this would be a bug of cryptoki.dll, but
NSS may be able to protect itself against this kind
of bugs.

Talkback says that we crashed on line 1078:

1070     /* first the the PKCS #11 call */
1071     PZ_Lock(mod->refLock);
1072     if (mod->evControlMask & SECMOD_END_WAIT) {
1073         goto end_wait;
1074     }
1075     mod->evControlMask |= SECMOD_WAIT_PKCS11_EVENT;
1076     PZ_Unlock(mod->refLock);
1077     crv = PK11_GETTAB(mod)->C_WaitForSlotEvent(flags, &id, NULL);
1078     PZ_Lock(mod->refLock);

But we just called PZ_Lock(mod->refLock) on line 1070
without crashing.  So I suspect that Talkback is off by
one line and the crash is actually on line 1077.

Comment 11

[Robert Relyea]

It's quite likely that cryptoki.dll claims to be PKCS #11 2.01 or greater. If it does, it needs to supply a C_WaitForSlotEvent function (which can return CKR_FUNCTION_FAILED).

bob

Comment 12

[Ratul]

Attachment: GoDaddySecureCertificateAuthority-G2.crt