Re: Re: Local vulnerability in suexec + FastCGI + PHP configurations

[security.432 () amxl com]

> Martijn Vernooij (tinus win tue nl) wrote
> On Wed, 11 Feb 2009 security.432 (at) amxl (dot) com [email concealed] wrote:
> > => The attacker must be able to run code as the same user that the
> > webserver runs as. This is unlikely to be a problem for many local
> > attackers, because there are a multitude of possible attack vectors,
> > such as SSI, non-suexec CGI scripts, non-suexec PHP (if mod_php is also
> > installed), and likely numerous other options.
>
> Once the attacker can run code as the same user > the webserver runs as, he
> can make the webserver do whatever he wants. He > can just 'debug' the
> webserver process and change any setting, inject code, whatever. You can
> php.ini whatever you want, and the attacker can > just make the webserver
> read his own php.ini, or change the webserver memory after the fact, to
> make it think it read something else than you wrote.

This is not true, at least on most platforms, because webservers typically start as root and use setuid to change their 
access level down to that of the webserver user after binding to the port. Most platforms do not allow users with the 
level of access as the webserver user to make ptrace syscalls against a process which used setuid to change to the 
webserver user.

> > As such, it appears that the PHP developers do not intend to add any
> > technical measures against this vulnerability. It should be noted that
> > while this is a vulnerability in a way of installing PHP, it appears
> > that there is no way to securely set up a suexec + FastCGI + PHP
> > installation using an unpatched version of PHP and so it is hoped that
> > the PHP developers will reconsider in time.
> And they are right. Unix security, and therefore application security,
> cannot protect you from you, and if the attacker can run processes as you,
> as far as Unix is concerned, he is you. If you want to prevent attackers
> from making processes you run do things you don't want, don't let them run
> processes on your user id.

This is exactly what the patch I included does; it prevents users from running PHP scripts as the user ID.

> The only thing that could be done, would be to  make the process running as
> another user id, that is the php instance  running from suexec, completely
> distrust any input it gets from the webserver. > That way, what the attacker
> can do is limited to what php lets him do.

This is exactly what PHP should provide the tools for the user to do (and what my patch achieves). The webserver should 
not be able to instruct the suexec wrapped PHP binary to run any arbitrary PHP script, only PHP scripts which were 
installed by the user in the correct location (in a similar way to how suexec will only execute binaries installed 
correctly, rather than just running any arbitrary process).

> In most cases that wouldn't do a lot of good for you though, since the
> webserver, and therefore the attacker, can see and change anything going
> into and coming out of the 'trusted' php instance, as it is going through
> that webserver he controls. So once you use your administrator login to
> administer your website, the attacker can just steal your login without
> you ever knowing, and do whatever you could do. 

This would require root access on most systems, not access as the webserver user, because the webserver is started as 
root and uses suexec to change uid.

> Or he could make you see
> whatever he wants you to see. With most php applications that is enough to
> completely own the website.
>
> The fact remains that suexec is a bad idea that is very hard if not
> impossible to do right. Doing suexec and simultaneously allowing code to
> run as the webserver user id is not helping.

It is hard to get programs running as suexec right, but at the same time, if done correctly, it provides a higher level 
of security in shared webhosting environments.

I believe it is possible to safely allow users to run as the user of the webserver and also run CGIs through suexec, as 
long as those programs perform adequate security checks. At present, PHP does not perform these checks, and my patch 
adds them in.