[unisog] creating secure asp/cgi servers

Albert Lunde Albert-Lunde at northwestern.edu
Tue Jun 4 20:37:35 GMT 2002


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

I'm assuming that CGIs provided by the average user will be
insecure, often in externally obvious ways.

> > 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". 

So far, the generic scripts we have steered people towards are
locally written and reviewed. This isn't _just_ a case of NIH 
syndrome: no one has asked for a third-party script that didn't
turn out to have serious problems. We probably could do more
proactively looking for _good_ 3rd party scripts...

--
    Albert Lunde          Albert-Lunde at northwestern.edu (new address)
                          Albert-Lunde at nwu.edu (old address)



More information about the unisog mailing list