Bug 730635

Summary: opencryptoki: privilege escalation via pkcsslotd's shared memory modification
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED CANTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dhorak, security-response-team, sgrubb
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-16 07:52:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 730643    

Description Tomas Hoger 2011-08-15 07:40:58 UTC 
The opencryptoki consists of several components - the slot manager daemon (pkcsslotd), the main API library, and the cryptographic device specific plugins slot token dynamic link libraries (STDLLs).  See the following for an overview:

http://www.ibm.com/developerworks/linux/library/s-pkcs/

pkcsslotd manages slots and tokens in the system.  When client applications wants to use any of the available cryptographic devices using the opencryptoki library, it calls library's C_Initialize API.  This makes opencryptoki to attach shared memory segment managed by the pkcsslotd to get information about available tokens.  The information about each token exported by pkcsslotd includes name of the STDLL library that implements support for the particular device.  The opencryptoki library then loads (using dlopen) STDLL for each available device.

Access to the pkcsslotd's memory requires pkcs11 group membership.  However, shared memory is writeable to pkcs11 group (the library updates some portions of that shared memory, e.g. when application opens new session).  Any user in the pkcs11 group can modify path to the STDLL exported for some slot/token, which may lead to an execution of arbitrary code with the privileges of some other user using opencryptoki (possibly root user).
Comment 3 Tomas Hoger 2011-08-16 07:52:42 UTC 
According to upstream, this is not a security problem.  All pkcs11 group members are assumed to be trusted and within the same trust boundary.  I have filed bug #730903 to see if we can improve the documentation provided with opencryptoki packages to warn about additional privileges granted with pkcs11 group membership.