[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120907133239.669c2bd3@redhat.com>
Date: Fri, 7 Sep 2012 13:32:39 +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 Thu, 6 Sep 2012 20:03:20 -0500 Raphael Geissert wrote:
> Niels Heinen (Google) discovered that openCryptoki 2.4.0 and older,
> when spinlocks are used, incorrectly handle lock files stored
> in /tmp.
AFAIK, this was reported to upstream more than once before it got
fixed.
> 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.
> 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.
> 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/).
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
attack
> Even 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...
--
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.
