Date: Sun, 9 Sep 2012 14:29:23 +0200 From: Tomas Hoger <thoger@...hat.com> To: oss-security@...ts.openwall.com Cc: geissert@...ian.org Subject: Re: CVE request: opencryptoki insecure lock files handling On Fri, 7 Sep 2012 11:26:34 -0500 Raphael Geissert wrote: > > 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. When do pkcsslotd does that, and which version? It does not happen on its start or stop, or when client as pkcsconf queries for some data. > > > In response, upstream released 2.4.1 which fixed the fchmod > > > issue (commits  and ). > > > > 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 Right, agree that 2.4.1 does not make any relevant change where /var/lock has such permissions. > > > Upstream then released 2.4.2, fixing this last issue (commits > > >  and ). > > > > 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. If pkcs11 group member can make pkcsslotd chmod lock file, pkcs11 group membership need to be assumed root equivalent without any additional condition. -- Tomas Hoger / Red Hat Security Response Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ