[3416] in WWW Security List Archive
Re: SSI #exec
daemon@ATHENA.MIT.EDU (Steff Watkins)
Wed Oct 30 21:32:05 1996
Date: Wed, 30 Oct 1996 23:49:14 +0000 (GMT)
From: Steff Watkins <Steff.Watkins@Bristol.ac.uk>
To: www-security@ns2.rutgers.edu
In-Reply-To: <199610291206.HAA23209@ConnActivity.ConnActivity.com>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 29 Oct 1996, Rich Brennan wrote:
> > In apache you don't need to do any hack. Rather than using
> > "exec cgi" or "exec cmd" you can use "include virtual."
>
> In NCSA, "include virtual" doesn't execute CGI scripts, and for Apache, it
> won't execute CGI scripts if IncludesNOEXEC is specified.
>
> See, I'd like to let CGI's execute in server side includes, but I don't want
> users to be able to run any random program. That is why a hack *is* necessary.
> Robert S. Muhlestein's suggestion sounds like it's exactly what I need.
Hello Rich,
while I can see and understand your reasoning (I had the same views
myself a few months back), I am now in a position where I cannot see the
'logic' in that reasoning (that was NOT meant as an insult!)
First, the users cannot run just 'any random' program. Any program called
by a SSI as an #exec MUST be CGI compliant. That is it must, as a bare
minimum, at least return a content-type header as the first line of
output. Otherwise, the #exec call will fail. Very few 'random' programs
actually do that.
Second, unless they are very clever/shifty/well connected, they will not
be able to execute any program that requires input. The program that is
run would have to be output only. They would have to write a wrapper to
be able to handle input from the remote browser. This, I feeel, seriously
reduces the number of programs that can be useful within the #exec call.
Finally, if a user is going to be so dumb (and yes.. I know!.. There are
users that ARE that dumb!) as to allow anyone, anywhere on the Internet
to run a program on their system without any form of prior authorisation,
then why don't they just do one of the following:
- Make a .rhosts file with +* in it
- Remove (set null) the password to their account
- Post their username and password to a newsgorup or mailing list
I am currently trying to get SSIs allowed for use within my local domain.
In an effort to avoid as much flak as possible, I tell ALL users who have
SSI capability (and that is a restricted set at the moment) that they
MUST read and abide by the University's rules on 'Acceptable Usage of
Computing Facilities'.
I think that, in comparison to direct login/rexec/rsh access, cgis and
SSIs are a relatively smaller risk.. still a risk.. but a smaller one.
One way of making this facility available to users without any major
worry would, possibly, be to run the webserver chroot'ed. Then, the only
executables it could access would be the executable that the web admin
deliberately puts into the DocumentRoot. In that way, you could seriously
reduce your potential risk.
Just an opinion,
Steff
