Re: SECURITY ALERT! [Re: How do you execute shell scripts in Mosaic]

Stephen D Crocker <crocker@tis.com>
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Date: Tue, 7 Jun 1994 13:03:36 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406071100.AA25438@tis.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: crocker@tis.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Stephen D Crocker <crocker@tis.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: SECURITY ALERT! [Re: How do you execute shell scripts in Mosaic] 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

> > Are you asking about how to execute a script on the client side that
> > comes in from an arbitrary hypertext link?  If so, there's a potential
> > security issue.  There's essentially no limit on what damage the
> > script can do.
> 
> Yep - what I am trying to do is execute a script that compares the
> script that you have asked to be executed with a set of scripts stored
> in a directory that only I have write access to - if the script to be
> executed is the same as one in my directory then the script gets
> executed, otherwise the user get a message/window displaying the 
> first page of the script and gets asked if they really want to execute
> the script (the default being NO).

If you're really talking about testing for an *exact* match with a set
of scripts you've already vetted, compute a crypto checksum, e.g. the
MD5 hash of the incoming script and compare it against the checksum of
the pre-vetted script.

Asking the user if he is sure he wants to exexute a script puts the
user in an awkward position.  He usually doesn't have enough context
or enough knowledge to be able to sort out the issues properly.  If
you're serious about the strategy of permitting execution of
pre-vetted scripts, then you might want to extend that strategy to
handle new scripts.  Whenever a new script is presented, bring it over
and put it in a temporary place.  Then inform the user that the script
needs to be vetted.  The user can then be directed to review the
script and sign off on it before it's executable.  Don't force the
user to make the decision inline and without any support tools.  Less
convenient?  You bet.  Security always is.

A much simpler strategy is to create a controlled environment via
chroot and execute the script in that environment.  A wide range of
useful scripts will work ok.  Some safe and useful scripts will not
work because they'll need access to things outside the controlled
environment.  It's a trade off, and I don't know how often there would
be a problem.


Steve