Hide Forgot
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): coolkey-1.1.0-3 How reproducible: always 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.
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. bob
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 /var/cache/coolkey. bob
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. bob
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 Coolkey. 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.
removing embargo
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2007-0631.html