[unisog] creating secure asp/cgi servers
Christopher A Bongaarts
cab at tc.umn.edu
Tue Jun 4 18:43:16 GMT 2002
As Albert Lunde once put it so eloquently:
> > Speaking from the UNIX point of view, Apache comes with su_exec
> > <http://httpd.apache.org/docs/suexec.html> that is used to run CGI's
> > and SSI's as a particular user (also used for allowing virtual hosts
> > to run as a different user from the main web server).
> > A more general solution is cgiwrap <http://cgiwrap.unixtools.org/>,
> > which is a setuid CGI script that runs other CGI's.
> The general issue with this kind of wrapper is that a significant
> number of security vulnerabilities for Unix involve a local
> user getting more priviledges. Giving a remote user the ability
> to execute arbitrary commands as _any_ user, turns those local
> vulnerabities into remote vulnerabilities.
I'm not sure how this gives a "remote" user the ability to run
"arbitrary" commands. Presumably a "local" user would have to set up
a CGI that the "remote" user could run (neither of the above programs
will run whatever someone happens to put in a URL; they have to be in
a designated space on the user-who-it-runs-as's account).
> The userid your web server runs as may have less priviledges
> than a general user account, (though it may be able to do
> more damage to the web server processes), so running CGIs
> as the user owning the script is more of a trade-off than
> a uniform win.
Running as a user rather than the web-server user does have a
separation advantage. (I.e. if the web-server user runs all CGI's,
then the users can manipulate other user's data files used by the
> My experience has been than the majority of people who know
> enough to write CGI scripts don't pay attention to security
> issues until they are called to their attention. This includes
> IT staff, and certianly students. Scripts off the net
> can be an equal risk, because one can assume the attacker
> may have the source code. A notorious example is formmail
> which has been actively expolited by spammers.
> We don't allow CGI scripting on the web server with personal home pages.
> Our main server allows departments to create scripts, but they
> are only put into production after prior review for security/reliability
> issues. Policy is leaning towards restricting than further;
> in any case we want to steer people towards generic scripts
> when possible.
But as you noted above, "generic" scripts (if off-the-net versions are
used rather than homebrew) are known to attackers and are much more
likely to be "wormable". Turns out "security through obscurity" does
have some value in a distributed DOS/worm-filled world (though it only
protects against the massively distributed attacks and not against a
directed attack against your system specifically, so it's only one
%% Christopher A. Bongaarts %% cab at tc.umn.edu %%
%% Internet Services %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
More information about the unisog