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.
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):
Note that the above patch was applied after upstream removed all other locking schemes except of spinlocks:
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):
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:
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:
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.
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:
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:
The erratum update opencryptoki packages to upstream version 18.104.22.168, 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.