User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Mozilla does a C_OpenSession, on which our pkcs11 lib returns a session handle of 1 (at first, the next C_openSession will return a session handle of 2, etc). However, later on a C_FindObjectsInit() with a session handle of 0 is done (which returns a CKR_SESSION_HANDLE_INVALID) A strange detail: if we change our pkcs11 lib to return session handles starting from 0 instead of 1, the first cert on the card is NOT shown (?). Reproducible: Always Steps to Reproduce: 1. Add a pkcs11 module that logs the pkcs11 calls 2. Open Mozilla, view the certificates, close Mozilla 3. View the logs Actual Results: A pkcs11 session handle of 0 is given in C_FinObjectsInit(), while C_OpenSession never returned this session handle. Expected Results: A pkcs11 session handle of 1 should have been returned, as this was what was returned by C_OpenSession. Here's part of the log: ... C_OpenSession (17:40:54) IN slotID: 0x0 = 0 IN flags: 0x4 = 4 IN pApplication: 0x41819020, address = 0x8956078 IN Notify: not shown OUT phSession: 0x1, address = 0xbfffcc88 Result: 0x0 (CKR_OK) C_GenerateRandom (17:40:54) IN hSession: 0x1 = 1 OUT RandomData: d0 4e 33 0c cc 7f 5d 2f a9 2e 3b e6 9b ca 38 34 bf 3f b4 11 3a 98 28 c0 64 92 b8 a6 18 75 ce a7 (32 bytes) Result: 0x0 (CKR_OK) C_SeedRandom (17:40:54) IN hSession: 0x1 = 1 IN pSeed: 59 c6 4c 02 52 02 db 02 04 d1 77 32 d6 26 8c cd b9 91 a3 ef e6 00 e2 1e f7 59 aa fc 9f f1 93 fa (32 bytes) Result: 0x0 (CKR_OK) C_FindObjectsInit (17:40:54) IN hSession: 0x1 = 1 IN pTemplate: 1 attribute(s): type 0 (CKA_CLASS), val = 54 43 53 ce (4 bytes) Result: 0x0 (CKR_OK) C_FindObjects (17:40:54) IN hSession: 0x1 = 1 IN ulMaxObjectCount: 0x1 = 1 OUT phObject: -1073754848, ulObjectCount=0 Result: 0x0 (CKR_OK) C_FindObjectsFinal (17:40:54) IN hSession: 0x1 = 1 Result: 0x0 (CKR_OK) C_GetSlotInfo (17:40:54) IN slotID: 0x1 = 1 OUT pInfo: HW Version: 0.0, SW Version: 0.0, flags = 0x6 slotDescr: ACS ACR 30u 0 0 manufacturerID: OpenSC project (www.opensc.org) Result: 0x0 (CKR_OK) C_FindObjectsInit (17:40:55) IN hSession: 0x0 = 0 IN pTemplate: 1 attribute(s): type 0 (CKA_CLASS), val = 54 43 53 ce (4 bytes) Result: 0xb3 (CKR_SESSION_HANDLE_INVALID)
This is very likely an NSS issue. Adding NSS folks. Reporter, does this still occur with recent mozilla nightly builds?
So there are 2 problems reported here: 1) NSS is not happy when '0' is returned from C_OpenSession(). Session handle '0' is reserved for 'CK_INVALID_HANDLE'. NSS uses this value quite extensively in it's error handling. See Section 9.3 in the PKCS #11 spec for more info. 2) NSS is using CK_INVALID_HANDLE in a C_FindObjectInit. This usually indicates either 1) and error in NSS, or 2) an attempt to do something that your token doesn't support. In this case it looks like NSS is trying to extract the trust objects from your token. It's very likely there's a latent bug in NSS since no pluggable token I know of knows how to store trust objects. I'll take the bug and close it if it turns out to be innocuous. bob
Hi bob, >1) NSS is not happy when '0' is returned from C_OpenSession(). sorry if I misunderstood, but our pkcs11 lib didn't return 0 for the session handle, it returned 1. Stef (who filed this bug)
I was responding to 'A strange detail:' comment. > A strange detail: if we change our pkcs11 lib to return > session handles starting from 0 instead of 1, the first > cert on the card is NOT shown (?). If you mean object handles, the same issue applies (seed 9.4). I haven't closed this bug because the base problem you describe may be a result of a bonified NSS bug (masked by the fact that few tokens understand the NSS trust objects). bob
>Reporter, does this still occur with recent mozilla nightly builds? Yes: as shown in the following part of our logs for the 2004.01.09 Nightly build (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040109) : 9: C_OpenSession [in] slotID = 0x0 [in] flags = 0x4 pApplication=026439A8 Notify=033C1E20 [out] *phSession = 0x1 Returned: 0 CKR_OK 10: C_GenerateRandom [in] hSession = 0x1 [out] RandomData[ulRandomLen] [size : 0x20 (32)] E6E58222 CE4D6D9D 549BF743 C2AD10E5 4EC0C3DE BC8713C8 09FEE86C CA02A6C2 Returned: 0 CKR_OK 11: C_SeedRandom [in] hSession = 0x1 [in] pSeed[ulSeedLen] [size : 0x20 (32)] 9C32170F 0EABF2BC DE6D6470 EA598FE0 679C00F3 A02FA332 BCC88CD0 0DF51A56 Returned: 0 CKR_OK 12: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate: CKA_CLASS Value CE534354 not found for type CK_OBJECT_CLASS Returned: 0 CKR_OK 13: C_FindObjects [in] hSession = 0x1 [in] ulMaxObjectCount = 0x1 [out] ulObjectCount = 0x0 Returned: 0 CKR_OK 14: C_FindObjectsFinal [in] hSession = 0x1 Returned: 0 CKR_OK 15: C_GetSlotInfo [in] slotID = 0x1 [out] pInfo: slotDescription: 'OMNIKEY CardMan 4000 0 ' manufacturerID: 'OpenSC project (www.opensc.org) ' hardwareVersion: 0.0 firmwareVersion: 0.0 flags: 6 CKF_REMOVABLE_DEVICE CKF_HW_SLOT Returned: 0 CKR_OK 16: C_FindObjectsInit [in] hSession = 0x0 [in] pTemplate: CKA_CLASS Value CE534354 not found for type CK_OBJECT_CLASS Returned: 179 CKR_SESSION_HANDLE_INVALID And after a while, it starts working fine again: 44: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate: CKA_TOKEN True CKA_CLASS CKO_CERTIFICATE Returned: 0 CKR_OK
This bug has slipped several releases because it is unprioritized. Now it's P2. It should stay there until it's resolved, IMO.
This was filed against 3.8, wasn't fixed for 3.9 or 3.10. I'm marking it P1 for 3.11. We really don't want to ever pass invalid handles (zero handles) to the various PKCS11 modules we use. Bob, do you think it may be fixed as a side-effect of the recent checkins for bug 292049 ?
I think the problem here is in nss/lib/dev or nss/lib/pki (STAN code). If I could reproduce the problem myself, I could go look at find_objects, but I suspect it's an interaction between stan and this PKCS #11 module. bob
Per our meeting today, lowering to P2. Bob, did you make any progress on this bug ?
Stef, are you willing to take an NSS 3.11 beta build and test with it to see if the problem still persists?
The target milestone is already released. Resetting target milestone.
Created attachment 340986 [details] [diff] [review] Fix more uses of invalid session handles There have been many MANY bugs in NSS that cause it to send a zero session handle to PKCS#11 modules. I have fixed some of them in my patches for bug 444850 and bug 444974. This patch fixes some more.
Created attachment 340992 [details] [diff] [review] revised patch In PK11_InitSlot, we don't want to call pk11_isRootSlot(slot) (which requires a valid session) unless and until we've called PK11_InitToken *AND* it has succeeded. Only then will we have a session established.
Comment on attachment 340992 [details] [diff] [review] revised patch r+ Definately include the pk11_InitSlot patch. The rest of the patch is correct, though I'm a little more reluctant about it. My issue here is we are really doing the PKCS #11 job (validating the session handle). For any correctly implemented PKCS #11 module this code should have the identical function as the previous code. If there is a problem with the session being NULL in these cases, then the code is meerly masking the underlying problem of these sessions being '0'. Though I've given it a r+, I'd like to take a step back and see if this is really what we want to do, however if you have a strong need for this patch to avoid a political situation, go ahead and check it in.
Checking in pk11wrap/pk11obj.c; new revision: 1.19; previous revision: 1.18 Checking in pk11wrap/pk11slot.c; new revision: 1.96; previous revision: 1.95 Thanks Bob. The problems that cause us to try to use an invalid session handle appear to be all NSS bugs. Our authority to say "Your PKCS#11 module is not following the spec" is greatly diminished when NSS itself clearly violates it in these circumstances. There are several reasons why these problems have persisted for years. One is that we don't test with third party PKCS#11 modules much, so we only exercise error paths that occur in our own module. Another is that many of these problems are due to project Stan having been aborted, something that will probably never be fixed. None of us has time to finish project Stan in the pk11wrap area. So, at this point, the best we can do is to make our own software be a better player, not breaking the rules so often. If someday someone really wants to tear into this problem, we can always put in assertions where these new tests are going. I'm marking this fixed. There are other causes of using zero session handles, but they have their own separate bugs.
I'm just worried the patch will silence the complaints without fixing any underlying problems.... but I r+'ed it under the assumption that the complaints were noisy enough as is. I'd rather fix those places where NSS actually violates the spec (which, BTW, this isn't one of them....). bob