Re: CGI security on a shared web server (fwd)

From: Lee E. Brotzman (leb@gmss.com)
Date: 05/29/02 

To: secprog@securityfocus.com
Date: Wed, 29 May 2002 17:28:23 -0400
From: "Lee E. Brotzman" <leb@gmss.com>

On Wed, 29 May 2002 11:04:30 +0200, Steffen Dettmer said:
> I don't see why someone would suEXEC setuid perl scripts.

I don't suEXEC setuid perl scripts. I don't suEXEC *any* scripts. That's what
I've been saying all along.

> SuEXEC
> already does setuid to the owner of that script - and I think it
> may even refuse execution if setuid bits are set. At least SuExec
> makes some tests, check docs.

I've checked the docs, read the source code, and used it for a moderately
extensive project (only about 30 CGI programs with ~5,000 lines of Perl code).
The experience led me to drop using it for the reasons I've already enumerated.
In my experience with suEXEC, the benefit of using the wrapper program did not
outweigh the risk of running all CGI programs with a real userid. Of the 30 or
so CGI programs in the project, only 8 had to have any elevated privilege. The
rest were just fine running as user "web" or whatever the web server UID was.

On Wed, 29 May 2002 11:59:44 EDT, "Jeff Dafoe" said:
>Running end users' CGIs as the same user as the web server is asking for
>problems, IMHO.

Perhaps, if you also have the web pages, or other files/directories, owned by
the same UID as the web server. I think you're better off if there are no files
owned by the UID of the web server, whether that's 'nobody' or some other
special-purpose UID. If your document root and its pages are owned by the web
server UID, then definitely you are better off using suEXEC to shuttle all CGI
programs to other UID/GIDs. As long as the web server doesn't have any
privileges to alter any files on the system, the threat from running CGI
programs with that UID is reduced significantly, though.

As a final word -- thankfully, this is my last follow-up -- all of these
decisions depend on the situation. I resist the notion that suEXEC is some
panacea. I freely acknowledge that there are situations where suEXEC is
helpful. I would hope that others would recognize that there are also reasons
*not* to use it. 

-- 
-- Lee E. Brotzman                    E-mail: leb@gmss.com
-- Allied Technology Group            Phone : 814-861-5028

Relevant Pages

  • Re: Database Security Issues
    ... >> a problem that ISPs and their customers face. ... Using suEXEC or other ... If the web server can read a file then anybody who uses that web ... and open_basedir can help prevent this, as can CGI mechanisms such ...
    (comp.lang.php)
  • RE: CGI security on a shared web server
    ... to run in a mass hosting environment under apache without the use of suexec. ... Running end users' CGIs as the same user as the web server is asking for ... it mitigates a variety of issues posed by running CGIs as the ...
    (SecProg)
  • suexec and Apache 2.0.52 ?
    ... I am using Apache 2 with suexec enabled at my web server. ... but I hope Fedora people also knows the solution. ...
    (Fedora)
  • Re: Another flaw in Apache?
    ... > user already has permission to run cgi scripts without suexec, SSI, etc). ... commands as the web server uid despite the use of suexec is not serious. ...
    (Vuln-Dev)