Closed
Bug 192179
Opened 22 years ago
Closed 22 years ago
CMS libraries inconsistent in use of NSSCMSGetDecryptKeyCallback
Categories
(NSS :: Libraries, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
3.7.2
People
(Reporter: javi, Assigned: rrelyea)
Details
Attachments
(1 file)
528 bytes,
patch
|
rrelyea
:
review+
|
Details | Diff | Splinter Review |
When encoding or decoding an NSSCMSEncrytpedData message, the CMS libraries ask the application to provide a callback that determines the symmetric to use when encrypting/decrypting the EncryptedData. Unfortunately, the code is inconsistent in it's calling of PK11_FreeSymKey on the symmetric key that is returned. So depending on whether the app decides to call PK11_ReferenceSymKey or not in its callback implementation, the app runs the risk of either leaking a reference to the key's slot (causing NSS_Shutdown to fail) or having a dangling pointer while decoding an encrypted data. For now, the workaround is to call PK11_ReferenceSymKey before calling decode and having the callback implementation not call PK11_RefernceSymKey. The 2 blocks where the callback is used: http://lxr.mozilla.org/security/source/security/nss/lib/smime/cmsencdata.c#156 (encoding) http://lxr.mozilla.org/security/source/security/nss/lib/smime/cmsencdata.c#230 (decoding)
Assignee | ||
Comment 1•22 years ago
|
||
You should return a reference to the key. Encrypt should free the reference when it is done. The bug is the code is assuming that NSS_CMSContentInfo_SetBulkKey is adopting the key, but it gets it's own reference. The app has to return the reference because otherwise there is a race between the app freeing the key and the CMS code getting it's own reference. bob
Summary: CMS libraries inconsistent in use of NSSCMSGetDecryptKeyCallback → CMS libraries inconsistent in use of NSSCMSGetDecryptKeyCallback
Comment 2•22 years ago
|
||
Assigned the bug to Bob.
Assignee: wtc → relyea
Priority: -- → P1
Target Milestone: --- → 3.7.2
Comment 3•22 years ago
|
||
Bob, this is the fix you described, right?
Assignee | ||
Comment 4•22 years ago
|
||
Comment on attachment 113857 [details] [diff] [review] Proposed patch Yes, that's the correct patch
Attachment #113857 -
Flags: review+
Comment 5•22 years ago
|
||
Bob, could you check this fix in on the trunk and the NSS_3_7_BRANCH?
Assignee | ||
Comment 6•22 years ago
|
||
Fix checked into branch and trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 7•22 years ago
|
||
Kai, I'd like you to verify that PSM is not affected by this bug. This bug is concerned with the NSSCMSGetDecryptKeyCallback function, which has this prototype: typedef PK11SymKey *(*NSSCMSGetDecryptKeyCallback)(void *arg, SECAlgorithmID *algid); I did a search for "SECAlgorithmID" and "PK11SymKey" in mozilla/security/manager, and the only function with that prototype is in mozilla/security/manager/ssl/src/nsNSSComponent.cpp: static PK11SymKey * GetDecryptKeyCallback(void *arg, SECAlgorithmID *algid) { return nsnull; } This function is not returning any bulkkey, so PSM can't possibly be affected by this bug, which has to do with the reference count of the returned bulkkey. Do you agree?
Comment 8•22 years ago
|
||
Wan-Teh, I fully agree with your analysis, I also can't find other areas of code that would be affected, from what you are describing.
You need to log in
before you can comment on or make changes to this bug.
Description
•