[3422] in WWW Security List Archive
Re: SSIs
daemon@ATHENA.MIT.EDU (Robert S. Muhlestein)
Thu Oct 31 19:26:56 1996
Date: Thu, 31 Oct 1996 11:36:13 -0800 (PST)
From: "Robert S. Muhlestein" <robertm@teleport.com>
To: "Andrew J. Hoag" <ahoag@nas.nasa.gov>
cc: www-security@ns2.rutgers.edu
In-Reply-To: <9610290827.ZM4388@rennsport.nas.nasa.gov>
Errors-To: owner-www-security@ns2.rutgers.edu
On Tue, 29 Oct 1996, Andrew J. Hoag wrote:
> > I was very excited to discover "include virtual" some time ago only to
> > meet with this disappointment. I would love to be wrong on this.
> > Someone please tell me if I am.
>
> This is definitely not a disappointment and I value this option. Allowing users
> to use SSI without worry about them executing programs is one less thing I have
> to monitor and worry about as a security vulnerability.
> Could someone explain to me why exec'ing a cmd (any /bin/sh command) is worse
> than exec'ing a CGI that exec's a cmd (interpreter of your choice)?
CGI scripts are best controled by the web admin in a cgi-bin directory. The
admin controls what goes in and out, what exectuesfrom the web server as a
CGI and what doesn't. The admin should look through the scripts for common
security holes (i.e. forking subshells, metacharacters, tainted variables,
".."" paths, etc) Call me paranoid, but we required source for all
user-submitted CGI scripts for this reason alone. This was also the primary
reason we chose not to install the Front Page extensions (and it tuned out
to be good that we did not).
Andrew, you probably knew all that part. It was mostly for the listeners at
home.
The difference between the "exec cmd" and the "exec cgi" boils down to
control. If you server is configured to only execute cgi scripts from the
cgi-bin directory, the the "exec cgi" SSIs can _only_ point to these
scripts. Activating this option does not allow someone to execute an
arbitrary CGI script someplace else unless you have allowed it (i.e. Handler
.cgi, etc). By the way, unless you really trust your users, I highly
recommend against allowing CGIs to be anywhere. Use cgiwrap instead.
Anyway, I digress...
The "exec cmd" option allows anyone who can publish web pages to
execute any shell command that the server users can execute. This
includes cat /etc/passwd (only really harmful if your not running
shadowed passwords) and any number of "rm" flavors. Even worse, is if
someone from the web can write raw HTML includeing SSIs to a guestbook web
page that is served up as server parsed HTML by the server. Now everyone
can execute arbitrary commands on your machine.
This is bad. Bad enough with a server running as "nobody" with no
permissions, even worse if your server runs with any more permissions.
And God help you if you still haven't learned the cardinal rul of web
admin "NEVER RUN A WEB SERVER AS ROOT". (Again, for the uninitiated of
which there seem to be many.)
The "exec cgi" is much "friendlier" than it's close relative. With it you
can add server-parsed counter, log scripts, and all kinds of great annoying
little widgets without the danger of the cmd. But, most importanly, the web
admin has control. With 4500+ web site authors. This becomes significant.
----------------------------------------------------------------------
Robert S. Muhlestein
Web Technologist
NIKE, Inc.
Work: robert.muhlestein@nike.com
Personal: rmuhle@q7.com
Old: robertm@teleport.com
(Opinions and comments are my own, not NIKE's.)
----------------------------------------------------------------------
