[2335] in bugtraq
Re: Telnet attack on SGI
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Nov 2 19:45:43 1995
Date: Wed, 1 Nov 1995 19:03:08 -0500
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: Sam Hartman <hartmans@MIT.EDU>
X-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: Douglas Siebert's message of Wed, 1 Nov 1995 11:59:48 -0600
>>>>> "Douglas" == Douglas Siebert <dsiebert@icaen.uiowa.edu> writes:
Douglas> I'm curious exactly to see exactly how the various
Douglas> vendors that have this vulnerability choose to fix it in
Douglas> the long term. In the short term, patching telnetd seems
Douglas> to be the solution. But what if the dynamic linker gets
Douglas> a new variable in the future, and the people responsible
Douglas> for that don't let the people responsible for telnetd
Douglas> know? A better fix, IMHO, would be some sort of way to
Douglas> compile some executables without support for altering
Douglas> paths in this way. HP by default does not allow you to
Douglas> modify the searching rules used for finding shared
Douglas> libraries. But with a linker option, you can allow the
Douglas> environment variable SHLIB_PATH to modify the searching
Douglas> rules. Its a bit less flexible than, say, Sun or SGI,
Douglas> but there are no worries about this sort of attack ever
Douglas> being possible unless HP compiled system binaries with
Douglas> this option, which they would of course be crazy to do.
David Borman said he was working on an environment
configuration file that would allow you to restrict some varibles,
encode others so that you could run a short program (or build it into
login) to decode them and add to the environment, and allow other
variables like TERM through un-modified. I would probably apply such
a solution to the Kerberos 5 telnetd when it becomes available; it
sounds like a better approach than limiting user flexibility.
Ideally, there should be a way to pass environment variables
into login in some sort of sane way outside the environment and have
login add them. I believe many sysv logins will allow you to specify
environment variables on the command line. This might be worth
experimenting with--perhaps we could convince the BSD folks to add
this if it had useful security benefits.
Douglas> -- Doug Siebert dsiebert@icaen.uiowa.edu