Bug 730636 (CVE-2012-4454, CVE-2012-4455)

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).

(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

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.

(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.

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.