Bug 428791 (CVE-2008-0001)

Summary: CVE-2008-0001 kernel: filesystem corruption by unprivileged user via directory truncation
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: bellman, cap, iboverma, jan.iven, jbacik, kreilly, romain.wartel
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commit;h=3093d39c9361dae001efaea9279b0b23e38f049c
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-08-24 16:00:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 428794, 428795, 428796, 428797    
Bug Blocks:    

Description Jan Lieskovsky 2008-01-15 10:41:02 UTC
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:


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

Issue noticed by Bill Roman at Datalight.


There is also patch provided together with this issue:

patch 974a9f0b47da74e28f68b9c8645c3786aa5ace1a in mainline

Comment 5 Mark J. Cox 2008-01-21 10:06:12 UTC
" 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). "

Comment 6 Peter K 2008-01-23 13:02:21 UTC
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.

Comment 7 Vitaly Mayatskikh 2008-01-23 13:22:33 UTC
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.

Comment 9 Peter K 2008-01-23 17:10:16 UTC
I wasn't asking, I was telling you ;-). My colleague will shortly follow up 
with details as required.

Comment 10 Thomas Bellman 2008-01-24 09:10:55 UTC
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.)

Comment 11 Vitaly Mayatskikh 2008-01-24 09:24:55 UTC
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

* 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]

Comment 12 Thomas Bellman 2008-01-24 14:21:25 UTC
*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.

Comment 13 Jan Lieskovsky 2008-01-24 14:57:32 UTC
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: 


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.


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

Comment 14 Alex Tang 2008-02-01 21:58:45 UTC
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).


Comment 15 Vitaly Mayatskikh 2008-02-02 11:36:11 UTC
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 -