Re: Configurable suexec bin

[Alexander GQ Gerasiov <gq...@cs.msu.su>]

Wed, 23 Feb 2011 21:49:50 +0100
Stefan Fritsch <sf...@sfritsch.de> wrote:

Thanks for your reply. That was really the thing I need to hear.

> 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?
Yep, but it's still not very comfortable to create a config file for
every user. And it allows my to specify docroot only.

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

Ok, I see the problem you're trying to avoid. It's not very serious for
my installation (since I trust www-user, and I hope there will be no
arbitrary code execution in httpd itself =)).

I'll look at this closer next time I have some free time and try to
make some solution. Which would be correct at least for common
installations. I don't think that this should be the silver bullet
anyway.

-- 
Best regards,
 Alexander GQ Gerasiov

 Contacts:
 e-mail:    gq@cs.msu.su             Jabber:  gq@jabber.ru
 Homepage:  http://gq.net.ru         ICQ:     7272757
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1