www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Colyer <g...@elysium.demon.co.uk>
Subject general/1268: CGI scripts running as Apache user: security (suexec etc.)
Date Mon, 20 Oct 1997 13:03:56 GMT

>Number:         1268
>Category:       general
>Synopsis:       CGI scripts running as Apache user: security (suexec etc.)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Mon Oct 20 06:10:01 PDT 1997
>Last-Modified:
>Originator:     greg@elysium.demon.co.uk
>Organization:
apache
>Release:        1.2.various
>Environment:
Linux 2.0.various
>Description:
As has already been mentioned in PR#337, a CGI script running as the Apache
user has access to protected parts of the document tree -- both protected
scripts and protected static documents.

This is a generic problem with CGI which cannot be solved without something like
suexec. However, the presence of suexec as-is potentially makes matters worse,
because such a script can then itself run suexec, and obtain further privileges.

suexec checks that it is run by the Apache user. Both problems can be solved by
ensuring that NO SCRIPT IS *EVER* RUN AS THIS USER. Currently, Apache does
not call suexec for scripts within the document tree of the main server. Thus,
a workaround is to have *no* main server -- only a virtual host. But this is
inconvenient when it is desired to request documents via several different DNS
names (e.g. an intranet name and an Internet name), or by address only (e.g.
using HTTP/0.9, which sends only the path part of the URL).
>How-To-Repeat:

>Fix:
Ensure that suexec is *ALWAYS* called (if enabled). Do this by un-overloading
the User/Group directives within httpd.conf. E.g.: could have ServerUser/ServerGroup
directives which specify the Apache user/group; User/Group directives then
meaning the user/group which will run scripts, as they do within <VirtualHost>s.

It would be *really* nice if the contexts of User/Group could be extended to
"directory" as well... Then it would be easy to have (e.g.) a single directory
of specially privileged scripts, without having to add a second layer of
wrapper. In fact, without this functionality, a second layer of wrapper is
dangerous for exactly the same reason as above: if the second wrapper can be run
after suexec has switched to User/Group, then it can be run by any other script
on that virtual host
>Audit-Trail:
>Unformatted:


Mime
View raw message