httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Configurable suexec bin
Date Wed, 23 Feb 2011 20:49:50 GMT
Hi,

the item "Mass vhosting version of suEXEC" has been on the wish list 
in httpd's STATUS file for many years. However it is not easy to do 
without introducing local privilege escalation vulnerabilties.

On Tuesday 22 February 2011, Alexander GQ Gerasiov wrote:
> Some days ago I found that I'm tired of original suexec which is
> shipped with apache.
> I have two issues:
> 
> 1.I'd like to configure it with config file, not with rebuilding,
> because I use modern OS with package system and don't want to
> depend on self-compiled components.

BTW, you have noticed that there is a version of suexec in Debian that 
allows to change the docroot and the run user with a config file?

> 2.I'd like to use apache2+fcgid+suexec+php5. But with original
> suexec I had to put dumb script to every users docroot, which only
> execs /usr/bin/php-cgi. So I just want to allow suexec execute some
> commands out of docroot tree and owned by the users other that one
> we setuid to.

Here is the problem. With the standard suexec, a user has to put a 
script into a special dir and make it executable to allow suexec to 
execute code as that user. That's clearly an opt-in process. Without 
the owner check, suexec will execute code as any user above the limit. 
There is no opt-in decision required by the user. And suexec will pass 
any arguments to the executed program. Therefore, in the special case 
that the allowed program is an interpreter, somebody with access to 
the httpd run user can execute arbitrary code as arbitrary user (above 
the configured user id limit).

For the same reason, it is a very bad idea to allow to configure a 
docroot of "/". Many users will have some scripts in /home/.../bin 
with appropriate permissions that are not designed to be setuid save 
and will allow an attacker to execute arbitrary code as that user.

You could argue that the limitation of only allowing the httpd run 
user to use suexec would reduce this problem. But configurations where 
users can execute arbitrary commands as httpd user are rather common 
(e.g. a simple httpd installation with mod_php and mod_userdir). Also, 
httpd is a network facing deamon and should have as little privilege 
as possible. Your suexec introduces these problems just by being 
installed on a machine, even if it is not used by the httpd 
configuration.

There has been some lengthy discussion about this topic at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499191 . You should 
probably read it.

Cheers,
Stefan



Mime
View raw message