Re: Telnet attack on SGI

[hartmans () MIT EDU (Sam Hartman)]

> > > > > "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