Re: Telnet attack on SGI

[adrian () procyon com (Adrian)]

> Doug Siebert wrote:
>
> | There are two ways I know of to protect against this attack until SGI has a
> | patch ready.  One would be to write a wrapper that removes "dangerous"
> | environment variables.  Obviously, figuring out which ones are dangerous is
> | the trick!  Certainly anything that starts LD_ or _RLD should be
> | removed.  But
> | there may always be others you don't know about.  You'd take your wrapper and
>
>        A wrapper should only pass 'trusted' and needed environment
> variables.  TZ, LANG, TERMCAP and the like.  Its much easier to figure
> out what you need than what you shouldn't trust.

We've already had versions fo telnet for some time that only pass
those variables that were thought to be needed.  If this approach
were adaquate, there would be no need to have added this feature to
telnet to pass all variables.

I think it's important to keep in mind that this is just ONE MORE
PROBLEM that results from allowing unrestricted use of environment
variables to make profound changes in the operation of critical
system utilities.  HP has an option that must be specified at link
time to produce an executable that can modify it's behavior this
way at run time.  This might be going a little to far in my opinion,
but it might be nice if there were an option in executables that
determined if search paths for shared libraries can be altered by
the environment.  I think it should default to allowing it, but
there should be an easy way to see how the options is set when you
only have a binary, and there should also be an easy way to change
that variable without relinking.  This solution would address a
whole series of shared library path vulnerabilities, without taking
any flexability away from the user.

I see two main schools of thought about security policies:  1) make
the user show us why what he wants is required before we think
about letting him have the option.  2) facilitate the process of
finding safe ways for the user to do things that he wants to do.
Of course, life is not always so simple in the real world, but lets
set that concern aside briefly, for the sake of brevity.

Option (2) seems more complicated and more resource intensive
at first glance, but if you try option (1), chances are, your
users will start to view you as a threat to their productivity
and start hiding things from you.  No matter how much simpler
option (1) may seem at first, I've never seen option (1) do
anything but make it difficult for the security administrators
to get a good picture of their network.

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

I doubt it.  There is nothing in TCP that specifically causes
environement variables to be passed from client to server.
newer versions of telnet and telnetd SPECIFICALLY cooperate
to copy the environment across in the initial out of band
options negotiation.  As far as I know, there is no such
mechanism in place for logdaemon, and there is, therefore,
no need to defend against tricky environment variables.

Somebody please flame me if I got this wrong.  8-)

---
L. Adrian Griffis
adrian () procyon com