Bug 730635 - opencryptoki: privilege escalation via pkcsslotd's shared memory modification
Summary: opencryptoki: privilege escalation via pkcsslotd's shared memory modification
Status: CLOSED CANTFIX
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: public=20110816,reported=20110813,sou...
Keywords: Security
Depends On:
Blocks: 730643
TreeView+ depends on / blocked
 
Reported: 2011-08-15 07:40 UTC by Tomas Hoger
Modified: 2019-06-08 18:53 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-08-16 07:52:42 UTC


Attachments (Terms of Use)

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.


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