Message-ID: <Pine.LNX.4.62.0902121621010.2665@blib.eesi.tue.nl>
Date: Thu, 12 Feb 2009 16:42:28 +0100 (CET)
From: Martijn Vernooij <tinus@....tue.nl>
To: bugtraq@...urityfocus.com
Subject: Re: Local vulnerability in suexec + FastCGI + PHP configurations

On Wed, 11 Feb 2009 security.432@...l.com 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@....net 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

Powered by blists - more mailing lists