shell variables security, and red herrings

shell variables security, and red herrings

Post by chris ulri » Fri, 01 Jan 1999 04:00:00



  In the documentation for postfix, there is the statement:

    Of course, Postfix programs do not trust data received from the
    network, either. In particular, no Postfix program places
    sender-provided data into shell command lines or into environment
    variables. If there is one lesson that people have learned from Web
    site security disasters it is this one: don't let any data from the
    network near a shell.

  I can understand the aversion to putting random stuff into the commandline
of a program, but I'm not sure I understand why it is bad to put random and
possibly hostile information into shell/environment variables.  I can see
some pretty obvious dangers (evaling  the variable or putting anything into
PATH, IFS or other important variables) but I can't see what the danger is
of putting something into a normal environment variable, so long as one treats
the variable with due caution.

  For example, if I run a script like
#!/usr/bin/ksh
while read input
do
echo "$input"
done

  as root from inetd, what am I exposing myself to?  Sure, the badguy can
use memory on my machine, but otherwise?  The above claim seems overly
paranoid and fishy to me.
chris

 
 
 

shell variables security, and red herrings

Post by skaji.. » Fri, 01 Jan 1999 04:00:00


-----BEGIN PGP SIGNED MESSAGE-----


>  In the documentation for postfix, there is the statement:

>    Of course, Postfix programs do not trust data received from the
>    network, either. In particular, no Postfix program places
>    sender-provided data into shell command lines or into environment
>    variables. If there is one lesson that people have learned from Web
>    site security disasters it is this one: don't let any data from the
>    network near a shell.

>  I can understand the aversion to putting random stuff into the commandline
>of a program, but I'm not sure I understand why it is bad to put random and
>possibly hostile information into shell/environment variables.  I can see
>some pretty obvious dangers (evaling  the variable or putting anything into
>PATH, IFS or other important variables) but I can't see what the danger is
>of putting something into a normal environment variable, so long as one treats
>the variable with due caution.

>  For example, if I run a script like
>#!/usr/bin/ksh
>while read input
>do
>echo "$input"
>done

>  as root from inetd, what am I exposing myself to?  Sure, the badguy can
>use memory on my machine, but otherwise?  The above claim seems overly
>paranoid and fishy to me.
>chris

It is one thing to put unchecked strings into local shell variables as the
scope is usually only that of the process in which they are defined. The danger
of command-line interface or _environment_ variables is that the scope is
usually of a more global nature. So, although the initiating process may or may
not check the quality of the variable, this is not true of other processes. A
example is ksh which uses the ENV variable to determine a file which executes
commands that affect the local environment when starting up. A change of the
ENV value to a file that creates a backdoor is conceivable if the user is root.
Unix was designed to be user-friendly, with security secondary. Other more
devious examples are probably possible, but only computational physicist/sys
admin so they would not necessarily occur to me.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNouYsAlu42bd3Du1AQHOaAL+KiKz1c9MMXntibCVvOUt5JsVFZVZ9esF
IXstEdeHA2IKrYTocI3EgQw1xXqMSvpfQAN69Ys7JmeixNzDlIvnaT1SgyY7lOEt
k07T/Tr34S0L6/ACQAytNeTxK0fVriVs
=3WbF
-----END PGP SIGNATURE-----
--
     Scott Kajihara
     "... and may the (net) Force be with you."