Bug 251774 - (CVE-2007-4129) CVE-2007-4129 coolkey file and directory permission flaw
CVE-2007-4129 coolkey file and directory permission flaw
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Bob Relyea
: Security
Depends On: 253164 253168 253169 280091
  Show dependency treegraph
Reported: 2007-08-10 21:16 EDT by Steve Grubb
Modified: 2012-05-24 17:18 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-05-24 17:18:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch starting to fix the issues being reported (1.35 KB, patch)
2007-08-10 21:16 EDT, Steve Grubb
no flags Details | Diff
RHEL 5.1 patch. Includes both the patch file and patch to the spec file (6.08 KB, patch)
2007-08-14 22:12 EDT, Bob Relyea
no flags Details | Diff

  None (edit)
Description Steve Grubb 2007-08-10 21:16:28 EDT
Description of problem:
It looks like coolkey creates /tmp/.pk11ipc1 as a world writable directory
without the sticky bit. And...it creates the files under that potentially as
world writable with the execute bit turned on or uses the file without any
sanity check. coolkey runs as root sometimes and that makes it susceptible to
doing symlink attacks.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ls -la /tmp | grep pk11ipc1

Actual results:
drwxrwxrwx  2 root   root    4096 2007-08-03 19:57 .pk11ipc1

Expected results:
drwxrwxrwt  2 root   root    4096 2007-08-03 19:57 .pk11ipc1

Additional info:
Will attach a patch that starts to address the problem. But I'd say that after
the mkdir, you'd want to opendir and check that the dir has the sticky bit set
and set it if not, check that the dir is not a symlink with fstat, then use
openat passing that dir fd to it, when the file is open check that its a regular
file via fstat, and then use it. You may also want to check the owner ID and
file perms too. I'm not sure what this apps really expects, but it needs to be
more paranoid about what its opening and using.
Comment 1 Steve Grubb 2007-08-10 21:16:29 EDT
Created attachment 161102 [details]
patch starting to fix the issues being reported
Comment 2 Mark J. Cox 2007-08-14 08:18:32 EDT
moving to security response bug, assigned CVE-2007-4129
Comment 3 Bob Relyea 2007-08-14 18:23:19 EDT
I can patch and release:
1) the upstream coolkey.
2) RHEL 5.1 version of coolkey.

Do I need to patch RHEL 5.0? If so what is the procedure (since there is already
a 5.1 update to coolkey.

Comment 4 Bob Relyea 2007-08-14 22:12:26 EDT
Created attachment 161324 [details]
RHEL 5.1 patch. Includes both the patch file and patch to the spec file

I'd like a review of this. Opening file in a world writable directory can be
tricky, and I want to make sure I've coverred all the basis.

The current patch takes Steve's changes, and adds some checks when we open to
make sure the 1) the file is owned by us, 2) the file has only one instance 3)
the file has the permissions we expect, and 4) the file has the size we expect.

The RPM also precreates the directory so the permissions and ownership are
right, and the package ownership is identified. The cache is now in

Comment 5 Steve Grubb 2007-08-15 08:42:41 EDT
I think this patch appears to fix the issues. But, I wanted to build a new
package and go over the resulting code just to be sure. The patch appears to
simply create a new file rather than patch the source:

[coolkey-1.1.0]$ patch -p0 < ../../coolkey/coolkey.patch 
patching file coolkey-cache-dir-move.patch

Would you mind attaching a new patch that would apply to the source code fixing
the problem? Thanks.
Comment 6 Bob Relyea 2007-08-15 12:16:57 EDT
The patch patches the RHEL5 build tree. The new file is the patch file for the
build tree, so you can patch the tree with patch -p0 < coolkey-cache-dir-move.patch.

The patch also contains changes to the RHEL5 .spec file (not the .spec file in
the build tree) which should also be reviewed.

Comment 7 Mark J. Cox 2007-08-17 05:03:04 EDT
Previous symlink flaws have been given low impact severity, and NVD CVSSv2
agrees.  We therefore propose that it gets fixed in the existing 5.1 update to

1. I'll create a 5.1 tracking bug in a moment with the required acks
2. I'll move RHBA-2007:0631 to RHSA-2007:0631 and add details of this issue,
moving it into NEED_RESPIN state
3. I'll tell vendor-sec folks and propose an embargo of 20070904

Please build updated 5.1 packages with this fix and add to RHSA-2007:0631

Comment 10 Steve Grubb 2007-08-17 10:21:34 EDT
The new code looks good. The patch to the specfile looks good. The only issue is
how to get rid of the old world writable directory in /tmp ?

Dan, would there be any selinux impact by moving the .pk11ipc1 directory from
/tmp to /var/cache (and getting rid of the '.' in its name?
Comment 12 Daniel Walsh 2007-08-22 08:47:11 EDT
I am not sure that coolkey has a policy yet.
Comment 13 Bob Relyea 2007-08-22 13:55:13 EDT
coolkey itself is strictly a shared library. Does policy's apply to shared
libraries or only to processes?
Comment 14 Daniel Walsh 2007-08-23 09:21:35 EDT
Only processes.  So this may affect login programs, or any program that needs to
write to this directory.
Comment 16 Mark J. Cox 2007-09-06 03:44:08 EDT
removing embargo
Comment 19 Red Hat Product Security 2008-01-16 09:15:08 EST
This issue was addressed in:

Red Hat Enterprise Linux:

Note You need to log in before you can comment on or make changes to this bug.