Bug 251774 (CVE-2007-4129) - CVE-2007-4129 coolkey file and directory permission flaw
Summary: CVE-2007-4129 coolkey file and directory permission flaw
Alias: CVE-2007-4129
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bob Relyea
QA Contact:
Depends On: 253164 253168 253169 280091
TreeView+ depends on / blocked
Reported: 2007-08-11 01:16 UTC by Steve Grubb
Modified: 2019-09-29 12:20 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-05-24 21:18:37 UTC

Attachments (Terms of Use)
patch starting to fix the issues being reported (1.35 KB, patch)
2007-08-11 01:16 UTC, 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-15 02:12 UTC, Bob Relyea
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2007:0631 0 normal SHIPPED_LIVE Low: coolkey security and bug fix update 2007-11-07 16:23:04 UTC

Description Steve Grubb 2007-08-11 01:16:28 UTC
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-11 01:16:29 UTC
Created attachment 161102 [details]
patch starting to fix the issues being reported

Comment 2 Mark J. Cox 2007-08-14 12:18:32 UTC
moving to security response bug, assigned CVE-2007-4129

Comment 3 Bob Relyea 2007-08-14 22:23:19 UTC
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-15 02:12:26 UTC
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 12:42:41 UTC
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 16:16:57 UTC
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 09:03:04 UTC
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 14:21:34 UTC
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 12:47:11 UTC
I am not sure that coolkey has a policy yet.

Comment 13 Bob Relyea 2007-08-22 17:55:13 UTC
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 13:21:35 UTC
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 07:44:08 UTC
removing embargo

Comment 19 Red Hat Product Security 2008-01-16 14:15:08 UTC
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.