Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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[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

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