[477] in linux-security and linux-alert archive

home help back first fref pref prev next nref lref last post

Re: telnetd shared lib hole

daemon@ATHENA.MIT.EDU (Alan Cox)
Wed Nov 8 23:36:19 1995

From: iialan@iifeak.swan.ac.uk (Alan Cox)
To: jlewis@inorganic5.chem.ufl.edu (Jon Lewis)
Date: Mon, 6 Nov 1995 11:35:32 +0000 (GMT)
Cc: linux-security@tarsier.cv.nrao.edu
In-Reply-To: <Pine.LNX.3.91.951101155003.12164K-100000@inorganic5.chem.ufl.edu> from "Jon Lewis" at Nov 1, 95 03:53:26 pm

> Call me silly, but since this hole operates by "secretly replacing your
> real libc with Foldgers Crystals libc" and having telnetd use the bogus
> libc, would all this be fixed with no need for careful patching /
> environment cleaning if we simply compiled telnetd and statically linked
> it?  Then it would need no shared libs, and you'd be unable to force it to
> load a hacked libc...no? 
> 
> It may not be an elegant solution...but is it one at all?

No. Its telnetd running login that is the problem. A static login helps
a lot. Some people are working on a telnetd that has a config file of
allowed environment variables to pass.

Alan

home help back first fref pref prev next nref lref last post