Bug 730636 (CVE-2012-4454, CVE-2012-4455) - CVE-2012-4454 CVE-2012-4455 opencryptoki: insecure handling of files in the /tmp directory
Summary: CVE-2012-4454 CVE-2012-4455 opencryptoki: insecure handling of files in the /...
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2012-4454, CVE-2012-4455
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:
Depends On:
Blocks: 730643
TreeView+ depends on / blocked
 
Reported: 2011-08-15 07:41 UTC by Tomas Hoger
Modified: 2021-02-24 14:55 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-23 19:34:34 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Debian BTS 689417 0 None None None 2012-10-02 14:26:11 UTC
Novell 779211 0 None None None 2012-09-07 13:27:43 UTC

Description Tomas Hoger 2011-08-15 07:41:40 UTC
opencryptoki, when compiled with -DSPINXPL (as it is in Red Hat Enterprise Linux and Fedora), creates certain dot files in the /tmp directory, such as .pkapi_xpk and .pkcs11spinloc.  These are not temporary files and are rather used for locking purposes.  They are created in a way that allows symlink attacks.

As files are opened RDWR, and not written to, they don't seem to allow file corruption as typical symlink attacks do.  It is still possible to create new files at arbitrary locations (e.g. /etc/nologin) or make arbitrary file world writable (e.g. /etc/shadow) with the privileges of the user running pkcsslotd or an application using opencrpytoki library.  Attacker does not need to be a member of the pkcs11 group, though symlinks would usually need to be created before the first use of the opencryptoki on the system.

Comment 2 Tomas Hoger 2012-03-07 16:52:32 UTC
This was recently fixed upstream via following commit, which moves lock files to /var/lock (.pkapi_xpk -> /var/lock/LCK..opencryptoki, .pkcs11spinloc -> /var/lock/LCK..opencryptoki_stdll):

http://sourceforge.net/p/opencryptoki/opencryptoki/ci/58345488c9351d9be9a4be27c8b407c2706a33a9

Note that the above patch was applied after upstream removed all other locking schemes except of spinlocks:

http://sourceforge.net/p/opencryptoki/opencryptoki/ci/b7fcb3eb0319183348f1f4fb90ede4edd6487c30

The fix is included in version 2.4.1 (currently in Fedora 17 and later).

Comment 6 Tomas Hoger 2012-09-07 12:55:12 UTC
(In reply to comment #2)
> This was recently fixed upstream via following commit, which moves lock
> files to /var/lock (.pkapi_xpk -> /var/lock/LCK..opencryptoki,
> .pkcs11spinloc -> /var/lock/LCK..opencryptoki_stdll):
> 
> http://sourceforge.net/p/opencryptoki/opencryptoki/ci/5834548

There are additional changes in 2.4.2, moving lock files to pkcs11 group writable /var/lock/opencryptoki directory.  This seems to re-introduce problems described in comment #0, but only allowing pkcs11 group members to exploit them.  In the current openCryptoki implementation, users of the pkcs11 group need to be fully trusted (see bug #730635).

This is now public via:
http://thread.gmane.org/gmane.comp.security.oss.general/8334

Comment 8 Tomas Hoger 2012-09-27 13:04:43 UTC
CVE-2012-4454 was assigned to the insecure handling of files in the /tmp directory that affected openCryptoki versions 2.4.0 and earlier, as described in comment #0:

http://thread.gmane.org/gmane.comp.security.oss.general/8334/focus=8509

Additional CVE-2012-4455 was assigned for the fix in 2.4.1 (the move of files to /var/lock), which does not address the original issue on systems with world-writable /var/lock directory.  Red Hat Enterprise Linux was never affected by this problem, as it does not yet contain a change moving lock files from /tmp.  openCryptoki version is currently available in Fedora 17.  However, Fedora (and Red Hat Enterprise Linux) do not have world-writable /var/lock and are hence unaffected by this CVE.

Statement CVE-2012-4455:

Not vulnerable. This issue did not affect the openCryptoki packages as shipped with Red Hat Enterprise Linux 5 and 6.

Comment 11 Tomas Hoger 2014-07-23 10:49:04 UTC
(In reply to Tomas Hoger from comment #6)
> There are additional changes in 2.4.2, moving lock files to pkcs11 group
> writable /var/lock/opencryptoki directory.

Relevant upstream commit from 2.4.2 is:
http://sourceforge.net/p/opencryptoki/opencryptoki/ci/8a63b3b17d34718d0f8c7525f93b5eb3c623076a

Quick overview of lock file changes across opencryptoki versions:

* /tmp/.pkapi_xpk (version 2.4 and earlier)
  -> /var/lock/LCK..opencryptoki (version 2.4.1)
  -> /var/lock/opencryptoki/LCK..APIlock (version 2.4.2)

* /tmp/.pkcs11spinloc (version 2.4 and earlier)
  -> /var/lock/LCK..opencryptoki_stdll (version 2.4.1)
  -> /var/lock/opencryptoki/<token>/LCK..<token> (version 2.4.2, there is a
     per-token sub-directory in /var/lock/opencryptoki, with possible
     additional per-user sub-directory for tpm token)

> This seems to re-introduce problems described in comment #0, but only
> allowing pkcs11 group members to exploit them.

These changes in 2.4.2 indeed re-introduce the problems described in comment #0, but they can only be exploited by users in a fully-trusted pkcs11 group (which should be considered root-equivalent).  However, as all directories as pkcs11 group writable, there's no longer a requirement that malicious symlink needs to be created before those lock files are first created.

Comment 14 Tomas Hoger 2014-07-23 19:34:34 UTC
This issue was mitigated in Red Hat Enterprise Linux 6 via RHBA-2013:1592, released as part of Red Hat Enterprise Linux 6.5:

https://rhn.redhat.com/errata/RHBA-2013-1592.html

The erratum update opencryptoki packages to upstream version 2.4.3.1, which stores lock files in /var/lock/opencryptoki directory instead of /tmp.  As the directory is only accessible to users in the pkcs11 group, only members of that group can exploit this insecure temporary file handling issues.  However, as the group is privileged and should only contain fully trusted users, the change greatly reduces impact of the issue.  This behavior may be restricted further in future updates if the behavior is changed upstream.

There is currently not plan to address these issues in opencryptoki packages in Red Hat Enterprise Linux 5.


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