Re: Re: Local vulnerability in suexec + FastCGI + PHP configurations
> 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.