oss-sec mailing list archives
Re: CVE request: opencryptoki insecure lock files handling
From: Raphael Geissert <geissert () debian org>
Date: Fri, 7 Sep 2012 11:26:34 -0500
Hi, On Friday 07 September 2012 06:32:39 Tomas Hoger wrote:
On Thu, 6 Sep 2012 20:03:20 -0500 Raphael Geissert wrote:It is possible for an attacker to replace the lock files with symlinks and have pkcsslotd (or others) fchmod the target of the symlink to make it world-writable, create arbitrary files, etc.There were following problems that I'm aware of: - /tmp/.pkapi_xpk - This was normally created by pcksslotd (running as root). Symlink attack on this did not allow corrupting / truncating files, but allowed creating new empty files at arbitrary locations. - /tmp/.pkcs11spinloc - I believe this is created by opencryptoki clients. In addition to the above, there's a chmod to make this file world writable. This may get created by non-root user, but chmod may still run later with root privileges later. Those files do not seem to get removed as part of the normal operation, so replacing them with symlinks if they already exist is limited by /tmp stickiness. Attacker does not need to be pkcs11 group member.
Correct, and to make it clear: /tmp/.pkcs11spinloc *is* chmod'ed by pcksslotd to make it world-writable.
In response, upstream released 2.4.1[1] which fixed the fchmod issue (commits [3] and [4]).2.4.1 moved those files that became /var/lock/LCK..opencryptoki and /var/lock/LCK..opencryptoki_stdll respectively.Niels discovered that 2.4.1 still allowed arbitrary files creation by following symlinks.Would you mind clarifying? As files were moved to /var/lock, this should require attacker to have permissions to write to that directory.
At least in Debian (and its derivatives): $ stat -c %a /var/lock/ 1777
Upstream then released 2.4.2[2], fixing this last issue (commits [5] and [6]).What do 2.4.2 actually fix? I think the move of /tmp/.pkcs11spinloc to /var/lock/LCK..opencryptoki_stdll probably created a regression in use cases where opencryptoki clients run without root privileges (or better to say without privileges to create the file in /var/lock/).
Given the above (/var/lock/ is world-writable), 2.4.1 doesn't cause a regression for non-root users. The move to the subdirectory in /var/lock limits the attack surface to members of the pkcs11 group, who are fully trusted, therefore becoming a non-issue.
Another move to pkcs11 group writable /var/lock/opencryptoki seems to resolve that, but it also negates benefits of the 2.4.1 security fix. Based on the rather quick look at the patches you pointed out, 2.4.2 seems to have the same problems pre-2.4.1 had, with following changed conditions: - attacker now needs to be pkcs11 group member - lack of directory stickiness should make it easier to execute the attackEven with the fixes in 2.4.2, members of the pkcs11 group could still use symlink attacks. However, as per upstream's documentation, members of such group are expected to be trusted[7].Correct, any pkcs11 group member can easily compromise any other user using opencryptoki library see: https://bugzilla.redhat.com/show_bug.cgi?id=730635 Upstream does not see that as an issue though...
Yeah, I saw it... Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
Current thread:
- CVE request: opencryptoki insecure lock files handling Raphael Geissert (Sep 06)
- Re: CVE request: opencryptoki insecure lock files handling Tomas Hoger (Sep 07)
- Re: CVE request: opencryptoki insecure lock files handling Raphael Geissert (Sep 07)
- Re: CVE request: opencryptoki insecure lock files handling Tomas Hoger (Sep 09)
- Re: CVE request: opencryptoki insecure lock files handling Raphael Geissert (Sep 12)
- Re: CVE request: opencryptoki insecure lock files handling Tomas Hoger (Sep 20)
- Re: CVE request: opencryptoki insecure lock files handling Raphael Geissert (Sep 24)
- Re: CVE request: opencryptoki insecure lock files handling Kurt Seifried (Sep 26)
- Re: CVE request: opencryptoki insecure lock files handling Raphael Geissert (Sep 07)
- Re: CVE request: opencryptoki insecure lock files handling Tomas Hoger (Sep 07)