Description of problem: In kernel versions beginning with 2.6.15 and including 2.6.24-rc7, it is possible for unprivileged local users to truncate any directory for which they have write permission. This renders all the contents of the directory inaccessible. It is then possible (given appropriate privileges) to remove the apparently empty directory. This can orphan inodes that had their only link from that directory. This issue description from LKML: <cite> Way back when (in commit 834f2a4a1554dc5b2598038b3fe8703defcbe467, aka "VFS: Allow the filesystem to return a full file pointer on open intent" to be exact), Trond changed the open logic to keep track of the original flags to a file open, in order to pass down the the intent of a dentry lookup to the low-level filesystem. However, when doing that reorganization, it changed the meaning of namei_flags, and thus inadvertently changed the test of access mode for directories (and RO filesystem) to use the wrong flag. So fix those test back to use access mode ("acc_mode") rather than the open flag ("flag"). Issue noticed by Bill Roman at Datalight. </cite> There is also patch provided together with this issue: patch 974a9f0b47da74e28f68b9c8645c3786aa5ace1a in mainline
" A security vulnerability was found in the Linux kernel virtual filesystem (VFS). The VFS used the "flag" variable rather than "acc_mode" variable to determine a process's access to files and directories. This allowed unprivileged local users to truncate any directory to which they had write permission, rendering the contents of the directory inaccessible. Given appropriate privileges the same user could then remove the truncated directory or exploit the damage to gain further privileges. (CVE-2008-0001, Important). "
FYI, 2.6.15+ seems to be incorrect. My colleague verified the problem on 2.6.9-67.0.1.ELsmp(x86_64) and code inspection seems to indicate that everything from 2.6.0 is affected.
Peter, the problem was introduced with this patch: commit 834f2a4a1554dc5b2598038b3fe8703defcbe467 Author: Trond Myklebust <Trond.Myklebust> Date: Tue Oct 18 14:20:16 2005 -0700 VFS: Allow the filesystem to return a full file pointer on open intent This means that kernel 2.6.14 and older are free of this bug. Proposed patch covers indirectly affected place of code.
I wasn't asking, I was telling you ;-). My colleague will shortly follow up with details as required.
As Peter says, I have actually reproduced this bug on older kernels. Specifically 2.6.9-67.0.1.ELsmp on an x86_64 machine running CentOS 4.6 (not a real RHEL, I'm afraid, but I believe they are equivalent in this respect). And after a quick look at the sources of 2.6.0 fetched from kernel.org, I believe this bug was present already then. I have sent more details in a mail to security-response-team, to avoid getting all details published publically here before you have updated kernel packages available. (I hope that was a good address to send it to.)
Red Hat Enterprise Linux doesn't run a plain vanilla kernel. As a part of internal kernel development process, upstream patch was backported to kernel 2.6.9-55.10: * Wed Jun 20 2007 Jason Baron <jbaron> [2.6.9-55.10] ... -only set implicit MAY_WRITE intent flag for permission check in open_namei() (Jeff Layton) [229177]
*Looks closer at the sources* Ah, now I understand why it didn't hit plain 2.6.9; the check for O_TRUNC was in filp_open() earlier, and set the flags argument to open_namei(). Still, it does affect the 2.6.9 variant that is used in RHEL 4.
Hello Thomas, You are right the sentence the CVE-2008-0001 issue affects only 2.6.15 kernel isn't true. We are considering this issue to affect the Linux kernel as shipped in RHEL-4 starting from Update 6 (2.6.9-67.EL) and RHEL-5 (all versions we have released till now). 2, Your sentence about: <cite> And after taking a quick look at the > source code for 2.6.0 fetched from kernel.org, it seems the bug > was present already then. </cite> Isn't also true. I have double checked this issue in RHEL-4 Update 5 kernel (2.6.9-55.EL) and this kernel is NOT affected. Even when you are trying to truncate the directory size to zero, the kernel access memory protection doesn't allow you to do this and also the subsequent attempt to "rmdir" of the non-empty testing directory (with "truncated" size) is unsuccessful. Maybe the code review could claim, the particular kernel version is affected, but it is better to try some testcase. So the final conclusion: The Linux kernels as shipped with Red Hat Enterprise Linux starting from version 2.6.9-67.EL and newer are affected by this issue (CVE-2008-0001). The Linux kernels as shipped with Red Hat Enterprise Linux starting from RHEL-2.1 kernel up to RHEL-4 Update 5 kernel (2.6.9-55.EL) are NOT affected by CVE-2008-0001. There might be another threshold kernel version when the kernel is NOT yet affected and is already affected (I didn't try to find exactly the particular kernel version). Hope this helps. Feel free to ask me for more information if you need it yet. Kind regards Jan iankko Lieskovsky
Jan, in your last comment you say that 2.6.9-55.EL is NOT affected, and that 2.6.9-67.EL is affected. However, just for clarification, what about the other 2.6.9-55 variants (2.6.9-55.0.2.EL, 2.6.9055.0.12.EL, etc). Thanks
Alex, kernel updates for RHEL-4.5 (2.6.9-55.0.x) are not affected, because issue was not ported from mainline internal kernel build (2.6.9-55.10). However, kernel updates for RHEL-4.6 (2.6.9-67.0.x) are affected until the latest one - 2.6.9-67.0.4.