PKCS11: invalid session handle 0



15 years ago
9 years ago


(Reporter: stef, Assigned: Nelson Bolyard (seldom reads bugmail))


Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



15 years ago
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 (   Result: 0x0 

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) 
-> PSM
Assignee: mstoltz → ssaux
Component: Security: CAPS → Client Library
Product: Browser → PSM
QA Contact: carosendahl → bmartin
Version: Trunk → unspecified


15 years ago
Version: unspecified → 2.4

Comment 2

14 years ago
This is very likely an NSS issue.  Adding NSS folks.

Reporter, does this still occur with recent mozilla nightly builds?

Comment 3

14 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.

Assignee: ssaux → rrelyea0264
Component: Client Library → Libraries
Ever confirmed: true
Product: PSM → NSS
Target Milestone: --- → 3.9.1
Version: 2.4 → 3.8

Comment 4

14 years ago
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

14 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).


Comment 6

14 years ago
>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
[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 ( '
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      flags:                   6
Returned:  0 CKR_OK

16: C_FindObjectsInit
[in] hSession = 0x0
[in] pTemplate[1]: 
    CKA_CLASS             Value CE534354 not found for type CK_OBJECT_CLASS

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


14 years ago
Target Milestone: 3.9.1 → 3.10

Comment 7

13 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


13 years ago
Blocks: 293319

Comment 8

12 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

12 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.


Comment 10

12 years ago
Per our meeting today, lowering to P2. Bob, did you make any progress on this bug ?
Priority: P1 → P2

Comment 11

12 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?  


12 years ago
QA Contact: bmartin → libraries

Comment 12

10 years ago
The target milestone is already released. Resetting target milestone.
Target Milestone: 3.11 → ---
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.
Assignee: rrelyea → nelson
Attachment #340986 - Flags: review?(rrelyea)
Created attachment 340992 [details] [diff] [review]
revised patch

In PK11_InitSlot, we don't want to call
(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

9 years ago
Comment on attachment 340992 [details] [diff] [review]
revised patch


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+
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.
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → 3.12.2

Comment 17

9 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....).

You need to log in before you can comment on or make changes to this bug.