-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Name: Linux kernel
Version: up to 2.2.20 and 2.4.18
Homepage: http://www.kernel.org/
Author: Wojciech Purczynski <[email protected]>
Date: March 26, 2002
Issue:
======
In case of excessively long path names d_path kernel internal function
returns truncated trailing components of a path name instead of an error
value. As this function is called by getcwd(2) system call and
do_proc_readlink() function, false information may be returned to
user-space processes.
Description:
============
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
Details:
========
d_path kernel function resolves a string of absolute path name of a dentry
passed as an argument to the function.
The path is a concatenation of subsequent path components starting from
trailing path component. The concatenated path name is stored into a
fixed-length buffer of PAGE_SIZE bytes.
If a dentry points to a path that exceeds PAGE_SIZE - 1 characters length,
leading path components are not written to the buffer and function returns
truncated path without an error value.
Because getcwd(2) system call uses d_path() function, it may return
invalid path to the user-space process. However, if a returned path is
longer than user-space buffer a correct error value is returned.
readlink(2) system call called on proc filesystem uses do_proc_readlink()
function which is also vulnerable to d_path() bug.
Impact:
=======
Privileged process may be tricked to think it is inside of arbitrary
directory. Other scenarios are possible if readlink() is used on files on
proc filesystem (like "/proc/self/exe").
PS: Please CC to [email protected] as I may not be subscribed to the list.
- --
Wojciech Purczynski
iSEC Security Research
http://isec.pl/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oHpKC+8U3Z5wpu4RAn6qAJ4seIO2xfXvrHmTMFQoMkGus23fJwCgjka7
ew84vFEFTO8lI7PQgEdyG0c=
=sEfh
-----END PGP SIGNATURE-----
This is a copy of a mail i've sent to bugtraq, i'm not currently a subscriber of linux mailing list but i've thought it could interest you.
Welcome i've made a quick patch for 2.2.20 internationnal kernels. I think it should work also for standard 2.2.20 kernels.
It's just quick so i've not made a lot of test but it works.
you need to apply it to path-to-linux-source/fs/dcache.c
Say me if it doesn't work...
S/ash
*** dcache.c.old Wed Mar 27 14:05:23 2002
--- dcache.c Wed Mar 27 14:34:13 2002
***************
*** 795,801 ****
--- 795,804 ----
namelen = dentry->d_name.len;
buflen -= namelen + 1;
if (buflen < 0)
+ {
+ retval = buffer - 1;
break;
+ }
end -= namelen;
memcpy(end, dentry->d_name.name, namelen);
*--end = '/';
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Back in March 2002, Wojciech Purczynski <[email protected]> wrote (original
article at http://online.securityfocus.com/archive/1/264117 ):
> Name: Linux kernel
> Version: up to 2.2.20 and 2.4.18
> ...
> In case of excessively long path names d_path kernel internal function
> returns truncated trailing components of a path name instead of an error
> value. As this function is called by getcwd(2) system call and
> do_proc_readlink() function, false information may be returned to
> user-space processes.
The problem is still present in Debian 2.4.19 kernel. I have not tried 2.5,
but see nothing relevant in the Changelogs at http://www.kernel.org/ .
Cheers,
Paul Szabo - [email protected] http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics University of Sydney 2006 Australia
On Wed, Nov 27, 2002 at 01:04:04PM +1100, Paul Szabo wrote:
> Back in March 2002, Wojciech Purczynski <[email protected]> wrote (original
> article at http://online.securityfocus.com/archive/1/264117 ):
>
> > Name: Linux kernel
> > Version: up to 2.2.20 and 2.4.18
> > ...
> > In case of excessively long path names d_path kernel internal function
> > returns truncated trailing components of a path name instead of an error
> > value. As this function is called by getcwd(2) system call and
> > do_proc_readlink() function, false information may be returned to
> > user-space processes.
>
> The problem is still present in Debian 2.4.19 kernel. I have not tried 2.5,
> but see nothing relevant in the Changelogs at http://www.kernel.org/ .
FWIW, I've included a workaround for this (covering the getcwd(2) case
only, not other uses of d_path() by the kernel or modules) in 2.2.21-ow1
patch and it went into 2.2.22 release in September.
This kind of proves the need for double-checking newer kernel branches
(2.4.x and 2.5.x currently) for fixes going into what many consider
stable kernels.
--
/sd
Solar Designer wrote:
> FWIW, I've included a workaround for this (covering the getcwd(2) case
> only, not other uses of d_path() by the kernel or modules) in 2.2.21-ow1
> patch and it went into 2.2.22 release in September.
Another reply shows that a patch has been submitted, but not acted upon:
> From [email protected] Wed Nov 27 21:39:07 2002
> Date: Wed, 27 Nov 2002 11:38:25 +0100 (CET)
> From: Jirka Kosina <[email protected]>
> To: Paul Szabo <[email protected]>
> Subject: Re: d_path() truncating excessive long path name vulnerability
>
> On Wed, 27 Nov 2002, Paul Szabo wrote:
>
> > > In case of excessively long path names d_path kernel internal function
> > > returns truncated trailing components of a path name instead of an error
> > > value. As this function is called by getcwd(2) system call and
> > > do_proc_readlink() function, false information may be returned to
> > > user-space processes.
> > The problem is still present in Debian 2.4.19 kernel. I have not tried 2.5,
> > but see nothing relevant in the Changelogs at http://www.kernel.org/ .
>
> I've sent patch to linux-kernel, but noone seemed interested
> (http://www.cs.helsinki.fi/linux/linux-kernel/2002-13/0054.html)
>
> --
> JiKos.
Cheers,
Paul Szabo - [email protected] http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics University of Sydney 2006 Australia