[449] in linux-security and linux-alert archive
Re: telnetd shared lib hole
daemon@ATHENA.MIT.EDU (Jon Lewis)
Mon Nov 6 14:08:59 1995
Date: Mon, 6 Nov 1995 02:11:33 -0500 (EST)
From: Jon Lewis <jlewis@inorganic5.chem.ufl.edu>
To: Aleph One <aleph1@dfw.net>
cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.SUN.3.90.951105235951.27617A-100000@dfw.net>
On Mon, 6 Nov 1995, Aleph One wrote:
> You need to compile login staticly, not telnetd.
>
> > Well...I was silly. Compiling a static in.telnetd solves nothing.
> >
> > I don't quite understand why static telnetd and login binaries still
> > appeared to exhibit the hole.
I think its starting to make sense now. I assume in.telnetd must already
be running when the environment stuff gets passed to it...no? So
specifying a hacked libc won't affect telnetd since it's already running,
right?...and it then passes the bad env vars to login.
> > [Mod: A static in.telnetd won't really fix this; the environment is
> > passed on to /bin/login which also needs to be static. I can't figure
> > out why compiling both programs statically would not fix
I think it was mentioned in bugtraq that static login does fix it, since
it gives more or less the same effect as telnetting in normally and then
saying LD_LIBRARY_PATH=/foo at the shell prompt. I think the trouble is
some people/os's can't do that.
I wrote a hack to crypt that will exploit the hole on both shadowed and
non-shadowed systems...but I'm not posting it...mostly because I used
system() to insert a shell script in crypt (ugly!)...and also because I'm
not sure if it's appropriate to post such a thing.
------------------------------------------------------------------
Jon Lewis | Mime attachments are OK
jlewis@inorganic5.chem.ufl.edu | But please ask before sending
http://inorganic5.chem.ufl.edu | unsolicited huge files.
|
_____Finger jlewis@inorganic5.chem.ufl.edu for PGP public key_____
