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