[<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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
