Turning off PHP in a hurry

Posted in: Tech

Hanging out at the Morpeth Mansions on Sat night, enjoying a gin & tonics session, descending deliciously into a quinine-flavored giggly haze, ... whereupon with little warning Rob & DC, a couple of playful computer security experts, instigated a "capture the flag" session with my production server. This involved attempting to get root on my box (i.e. total control) before I patched any holes they might've found...

The easiest target was the free upload service I run. This enables anyone to transfer a file through a couldn't-be-simpler browser interface and then be presented with a URL to that file. For times when you're stuck at a internet cafe or don't have an SFTP client it's fabulously convenient. I provide it as a service to folks I host as well: they can drop files directly into a safe area of their site wherever there's an internet connection. (For administrative information, the webmaster also gets notified over email of the upload.)

The upshot of this is that anyone can put files onto the system. Now, anyone in security is probably suffering major facial contortions at the thought of the implications to server safety of this.

Security balance

Security is all about compromise, a compromise between restriction of access and benefit to users. The most secure system is an unplugged one, but that's not particularly useful except to prop a door open. At the other extreme, a system completely without passwords is easy to use but concomitantly easy to abuse.

The upload service is extremely useful when it's needed. So for that I have to think hard about a way of providing it while minimizing the risk of server damage. What I've done to reduce chances of someone being able to cause mischief:

• the upload script has taint checking on to ensure every piece of data that comes into the script is filtered somehow


• path separators (/, \, :) are stripped from incoming file names (so amongst others ../ abuse isn't possible)


• non-letters and non-periods are replaced with underscores for clear names and additional filename safety


• some extensions are banned (right now, just rar files mostly since this is almost certainly a warez abuse)


• maximum file size upload (with password override)


• CGI execute permissions are switched off (-ExecCGI) so executable files are harmless. Files land up on the server without the execute bit set too. (The upload script itself has an explicit <Location> directive to allow it to be executed)


• and the upload script is not writable by the webserver process.

But... PHP

DC immediately tested to see whether PHP would be executed. What's different about PHP is that neither ExecCGI nor filesystem execute permissions need be on for Apache to go ahead and execute it. And sure enough, a hacked up phpinfo.php file ran. So I needed to turn this off, ASAP.

My first attempt was to remove the PHP handler with RemoveHandler .php. This didn't work, probably due to my misunderstanding exactly the implications of "handlers" and "types" in Apache.

PHP Shell

While I set about my task of disabling PHP, DC had uploaded the devious PhpShell utility. This provides and simulates a shell (using PHP's proc_open() call) through a web interface. Now this piece of software ought to give sysadmins the pause for thought: anyone hosting PHP in a shared server environment is opening up convenient access to at least the filesystem, possibly arbitrary program execution depending on the server's safe_mode setting. I believe the defaults are a permissive "off" for all the various safe modes.

So the race to capture the flag was on: could DC & Rob find a local root exploit before I figured out how to turn PHP off for that site? (Obviously, since I have such excellent PHP sites as Nik's online travelog diary running I couldn't switch PHP off globally.)

Root?

With shell access, the next step is attempting that local root exploit. DC tried the mremap_pte exploit for the do_mremap vulnerablility. Fortunately I'd heard about that and upgraded my kernel to 2.4.25 a while back so wasn't vulnerable. Phew!

How to turn PHP off

By this point (and he was working fast) I'd found a way of turning off PHP: php_flag engine off which works inside a virtual host. After restarting apache PHP was indeed off. Phew again!

The relevant parts of the httpd.conf are:

        <Directory /home/www/paulm/html/paulm.com/tmp>
                Options Indexes +FollowSymLinks -ExecCGI
                DirectoryIndex index.cgi
                php_flag engine off
        </Directory>
        <Location /index.cgi>
                Options +ExecCGI
        </Location>

Further remedies

I'm investigating with users how much safe mode I can switch on. I'd also like a way to automatically delete files after they've been downloaded a set number of times to prevent essentially warez abuse. (It's happened before, and I hope to write that up as it's quite a funny story how I arrived at a solution...)

If anyone would like a copy of the upload script to audit let me know.

Any other safety thoughts?

And finally...

Gin-fuelled penetration testing: fun & educational ;-) Cheers guys!

Posted by Paul Makepeace at August 22, 2004 13:37 | TrackBack