Red Hat Bugzilla – Bug 251774
CVE-2007-4129 coolkey file and directory permission flaw
Last modified: 2012-05-24 17:18:37 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):
Steps to Reproduce:
1. ls -la /tmp | grep pk11ipc1
drwxrwxrwx 2 root root 4096 2007-08-03 19:57 .pk11ipc1
drwxrwxrwt 2 root root 4096 2007-08-03 19:57 .pk11ipc1
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.
Created attachment 161102 [details]
patch starting to fix the issues being reported
moving to security response bug, assigned CVE-2007-4129
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.
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
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.
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.
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
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?
I am not sure that coolkey has a policy yet.
coolkey itself is strictly a shared library. Does policy's apply to shared
libraries or only to processes?
Only processes. So this may affect login programs, or any program that needs to
write to this directory.
This issue was addressed in:
Red Hat Enterprise Linux: