Re: Telnet attack on SGI

[hartmans () MIT EDU (Sam Hartman)]

The following message is a courtesy copy of an article
that has been posted as well.

> > > > > "Adam" == Adam Shostack <adam () bwh harvard edu> writes:
In article <199511021900.OAA03205 () cushing bwh harvard edu> Adam Shostack <adam () bwh harvard edu> writes:


    Adam> Doug Siebert wrote: | There are two ways I know of to
    Adam> protect against this attack until SGI has a | patch ready.
    Adam> One would be to write a wrapper that removes "dangerous" |
    Adam> environment variables.  Obviously, figuring out which ones
    Adam> are dangerous is | the trick!  Certainly anything that
    Adam> starts LD_ or _RLD should be | removed.  But | there may
    Adam> always be others you don't know about.  You'd take your
    Adam> wrapper and

    Adam>         A wrapper should only pass 'trusted' and needed
    Adam> environment variables.  TZ, LANG, TERMCAP and the like.  Its
    Adam> much easier to figure out what you need than what you
    Adam> shouldn't trust.

        I fundamentally disagree.  This denys the user the ability to
add useful funcationality by using environment variables in shell
scripts, etc.  Basically, login needs to have a well-defined, documented interface, including all deppendencies--even 
dependencies on dynamic loading and the libc.  Programs that login trust need to coordinate with this interface and 
make sure they do not violate it.

        It might also be useful for a mechanism to be added so that
telnetd can tell login about "untrusted" environment variables, which
login adds to the environment *after* the setuid call.  Then, all
environment variables passed by options could be considered untrusted.
However, in order to maintain flexibility on the part of the system
administrator, environment variables like LD_LIBRARY_PATH inherited
from telnetd by inetd should be passed to login unmodified.

    Adam>         Logdaemon is supposedly not affected by this; I
    Adam> suspect that that's because it already empties its
    Adam> environment.  Good defensive code that.

        But uneffective against this attack.  A program doesn't get a chance to empty its environment before ld.so 
examines it and loads the defective library.

    Adam> Adam

    Adam> -- "It is seldom that liberty of any kind is lost all at
    Adam> once."  -Hume