200704 - PKCS11: invalid session handle 0

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[stef]

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

[Matthias Versen [:Matti]]

-> PSM

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

This is very likely an NSS issue.  Adding NSS folks.

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

Comment 3

[Robert Relyea]

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

Comment 4

[stef]

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

[Robert Relyea]

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 
 

Comment 6

[stef]

>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

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

This bug has slipped several releases because it is unprioritized.  
Now it's P2.  It should stay there until it's resolved, IMO.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

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 ?

Comment 9

[Robert Relyea]

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

[Julien Pierre]

Per our meeting today, lowering to P2. Bob, did you make any progress on this bug ?

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

Stef, are you willing to take an NSS 3.11 beta build and test with it to see
if the problem still persists?  

Comment 12

[Christophe Ravel]

The target milestone is already released. Resetting target milestone.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

Attachment: 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.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

Attachment: 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 15

[Robert Relyea]

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.

Comment 16

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 17

[Robert Relyea]

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