On Wed, 11 Feb 2009 security.432@xxxxxxxx wrote:
DISCLAIMER: THIS SECURITY ADVISORY IS PROVIDED AS-IS, AND WITHOUT ANY
GUARANTEE OF ANY KIND THAT THE INFORMATION IS ACCURATE, OR THAT THE
WORKAROUND, SOLUTIONS, OR PATCHES PROVIDED WILL PROTECT SYSTEMS, OR THAT
THEY WILL NOT CREATE NEW PROBLEMS. THE AUTHOR ACCEPTS NO LIABILITY OF
ANY FORM FOR THE INFORMATION CONTAINED WITHIN OR THE CONSEQUENCES OF ITS
USE OR MISUSE.
Synopsis:
Most current installations of PHP set up to run via FastCGI with suexec
are vulnerable to a local exploit, where anyone with the ability to run
code as the user the webserver runs as can gain access as any user with
an account set up to run PHP. It is anticipated that this issue will
especially affect shared web hosts who use FastCGI + suexec thinking it
will give them additional security.
Conditions for exploitation:
[..]
=> 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.
[..]
Vendor notification:
security@xxxxxxx has been informed of this issue. Antony Dovegal replied to say:
"It's been agreed that we won't implement any more security hacks in
PHP itself since such things should be done by the OS, so no more magic
INI settings."
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.
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.
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. 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.
Martijn
