On Tue, Nov 09, 1999 at 11:39:39AM +0100, Mariusz Marcinkiewicz
wrote:> After reading lcamtuf's posts I decided write this one. Few months ago
one
> of my friends - digit - found bug in linux nfsd daemon. I made example
> sploit about IV 1999. Now in distributions is new nfsd and nowhere was
> information about security weaknes of old version!
Well, one gets used to people posting to bugtraq without bothering to
send any mail whatsoever to the maintainer of a free software package.
But whining about the bug not having been fixed without even sending
a bug report *anywhere* kind of beats everything I've seen so far.
Am I now supposed to follow alt.support.p30ple.with.sp311ing.pr0blemz?
FWIW, the source distribution of unfsd contains a file called BUGS
which even the attention span challenged have a hard time overlooking.
This file contains fairly detailed instructions on how to submit a
bug report.
Concerning the problem Mariusz has been handwaving about, this is a
serious issue. It's got nothing to do with realpath(), however. The true
cause of the problem is that the code relies on the total length of a
path to not exceed PATH_MAX + NAME_MAX. I'm not sure whether this is a
common Unix problem, but at least on Linux, PATH_MAX merely seems to put
an upper limit on the length of a single path you can hand to a syscall
(size of a page - 1, i.e. 4095). However it still allows you to create
files within that directory as long as you use relative names only...
As to the impact of the problem, it's nasty, but you will need to have
a directory exported read/write to you in order to exploit it (or you're
able to impersonate a host with this kind of access).
Appended you'll find a patch against 2.2beta46 that rectifies this problem.
The full source for 2.2beta47 can be found at
ftp://mathematik.tu-darmstadt.de/pub/linux/people/okir
Another version (2.2.48) that has some additional, non-security related
fixes I have been working on can be found in the dontuse subdirectory.
Olaf>>From okir@monad.swb.de Wed Nov 10 10:54:31 1999
Received: (from okir@localhost)
by monad.swb.de (8.9.3/8.9.3) id KAA01061;
Wed, 10 Nov 1999 10:54:31 +0100
Date: Wed, 10 Nov 1999 10:54:31 +0100
From: Olaf Kirch <okir@monad.swb.de>
To: BUGTRAQ@SECURITYFOCUS.COM
Cc: linux-security@redhat.com
Subject: Re: undocumented bugs - nfsd
Message-ID: <19991110105431.B31766@monad.swb.de>
References: <Pine.LNX.4.20.9911091058140.12964-100000@mail.zigzag.pl>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=3MwIy2ne0vdjdPXF
X-Mailer: Mutt 0.95.6i
In-Reply-To: <Pine.LNX.4.20.9911091058140.12964-100000@mail.zigzag.pl>;
from Mariusz Marcinkiewicz on Tue, Nov 09, 1999 at 11:39:39AM +0100
On Tue, Nov 09, 1999 at 11:39:39AM +0100, Mariusz Marcinkiewicz
wrote:> After reading lcamtuf's posts I decided write this one. Few months ago
one
> of my friends - digit - found bug in linux nfsd daemon. I made example
> sploit about IV 1999. Now in distributions is new nfsd and nowhere was
> information about security weaknes of old version!
Well, one gets used to people posting to bugtraq without bothering to
send any mail whatsoever to the maintainer of a free software package.
But whining about the bug not having been fixed without even sending
a bug report *anywhere* kind of beats everything I've seen so far.
Am I now supposed to follow alt.support.p30ple.with.sp311ing.pr0blemz?
FWIW, the source distribution of unfsd contains a file called BUGS
which even the attention span challenged have a hard time overlooking.
This file contains fairly detailed instructions on how to submit a
bug report.
Concerning the problem Mariusz has been handwaving about, this is a
serious issue. It's got nothing to do with realpath(), however. The true
cause of the problem is that the code relies on the total length of a
path to not exceed PATH_MAX + NAME_MAX. I'm not sure whether this is a
common Unix problem, but at least on Linux, PATH_MAX merely seems to put
an upper limit on the length of a single path you can hand to a syscall
(size of a page - 1, i.e. 4095). However it still allows you to create
files within that directory as long as you use relative names only...
As to the impact of the problem, it's nasty, but you will need to have
a directory exported read/write to you in order to exploit it (or you're
able to impersonate a host with this kind of access).
Appended you'll find a patch against 2.2beta46 that rectifies this problem.
The full source for 2.2beta47 can be found at
ftp://mathematik.tu-darmstadt.de/pub/linux/people/okir
Another version (2.2.48) that has some additional, non-security related
fixes I have been working on can be found in the dontuse subdirectory.
Olaf
-----BEGIN PGP SIGNED MESSAGE-----
79a29fe9f79b2f3241d4915767b8c511 nfs-server-2.2beta47.tar.gz
c2ef6e37064ca7d9e52de7b711a7ebec patch-2.2.47.gz
-----BEGIN PGP SIGNATURE-----
iQCVAwUBOClCC+FnVHXv40etAQGRvwP/czA9uZ3EYthdO01h9E98tOmKgJ+rkJ9q
tBQwrs452a+A3xv6t1/V4rT6Q5BTPnzVkxyAIjiXwhSYbUbBS7C/yCqYfi/fzb2i
6lCYqdBxjxE9hX5PuYR983egHNOnA4dTlSgjhP13bSaNKifF1XwD1IYgGuo1ZoGp
eDNa0+cFGG8=dHTh
-----END PGP SIGNATURE-----
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
