Re: CVE request: opencryptoki insecure lock files handling

[Tomas Hoger <thoger () redhat com>]

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[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

Right, agree that 2.4.1 does not make any relevant change
where /var/lock has such permissions.

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

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