[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
CGI's.)

> 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
onion-layer...)

%%  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 mailing list