Closed
Bug 200704
Opened 21 years ago
Closed 16 years ago
PKCS11: invalid session handle 0
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
RESOLVED
FIXED
3.12.2
People
(Reporter: stef.hoeben, Assigned: nelson)
References
Details
Attachments
(1 file, 1 obsolete file)
4.34 KB,
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
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)
Comment 1•21 years ago
|
||
-> PSM
Assignee: mstoltz → ssaux
Component: Security: CAPS → Client Library
Product: Browser → PSM
QA Contact: carosendahl → bmartin
Version: Trunk → unspecified
Updated•21 years ago
|
Version: unspecified → 2.4
Assignee | ||
Comment 2•21 years ago
|
||
This is very likely an NSS issue. Adding NSS folks. Reporter, does this still occur with recent mozilla nightly builds?
Comment 3•21 years ago
|
||
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
Assignee: ssaux → rrelyea0264
Status: UNCONFIRMED → NEW
Component: Client Library → Libraries
Ever confirmed: true
Product: PSM → NSS
Target Milestone: --- → 3.9.1
Version: 2.4 → 3.8
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)
Comment 5•21 years ago
|
||
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[1]:
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[1]:
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[2]:
CKA_TOKEN True
CKA_CLASS CKO_CERTIFICATE
Returned: 0 CKR_OK
Updated•20 years ago
|
Target Milestone: 3.9.1 → 3.10
Assignee | ||
Comment 7•20 years ago
|
||
This bug has slipped several releases because it is unprioritized. Now it's P2. It should stay there until it's resolved, IMO.
Priority: -- → P2
Assignee | ||
Comment 8•19 years ago
|
||
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 ?
Priority: P2 → P1
Target Milestone: 3.10 → 3.11
Comment 9•19 years ago
|
||
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
Comment 10•19 years ago
|
||
Per our meeting today, lowering to P2. Bob, did you make any progress on this bug ?
Priority: P1 → P2
Assignee | ||
Comment 11•19 years ago
|
||
Stef, are you willing to take an NSS 3.11 beta build and test with it to see if the problem still persists?
Assignee | ||
Updated•18 years ago
|
QA Contact: bmartin → libraries
Comment 12•17 years ago
|
||
The target milestone is already released. Resetting target milestone.
Target Milestone: 3.11 → ---
Assignee | ||
Comment 13•16 years ago
|
||
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.
Assignee: rrelyea → nelson
Attachment #340986 -
Flags: review?(rrelyea)
Assignee | ||
Comment 14•16 years ago
|
||
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.
Attachment #340986 -
Attachment is obsolete: true
Attachment #340992 -
Flags: review?(rrelyea)
Attachment #340986 -
Flags: review?(rrelyea)
Comment 15•16 years ago
|
||
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.
Attachment #340992 -
Flags: review?(rrelyea) → review+
Assignee | ||
Comment 16•16 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.12.2
Comment 17•16 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•