A Month of PHP Bugs was launched March 1. If you missed last week’s editorial about this initiative, you can read it on the WindowsIT Pro web site at the URL below. Be sure to also read the related news item “5 Vulnerabilities Kick Off Month of PHP Bugs,” which you can link to from the Security News and Features section below.
http://www.windowsitpro.com/Article/ArticleID/95328
So far, Stefan Esser has posted several interesting vulnerabilities on his Month of PHP Bugs site, some of which you can avoid by specific practices. If you use PHP on your server, then you need to examine its configuration to make sure you’re not overly exposing aspects of the engine, which could in turn expose your entire system and possibly other parts of your network.
If your Web system is closed (i.e., you don’t allow others to upload or create any files), your potential security risks are more limited than if it’s open. Either way, you need to take precautions to ensure that certain functions aren’t usable unless you intend for them to be used.
One example is that PHP can allow the use of the exec and shell_exec functions, which essentially let you run OS commands and retrieve the output. I’ve used the shell-exec function to good advantage. I had an account with a Web hosting company, which had a server that would frequently slow to a crawl, making nearly all access impossible. I grew tired of the support staff’s vague explanations and decided to investigate the problem myself.
With the help of the shell_exec function (and a few others), I could use PHP to look at a lot of the server’s operational characteristics. I discovered the bottleneck, contacted support, and alluded to the problem. I figure the support team members scratched their heads for a couple months wondering how I knew what was happening before they finally wised up and disabled the shell_exec function.
In another example, I signed up for a blog at a popular site, which will remain unnamed here. I wanted specific blog functionality that wasn’t available, so I went to work on a way around the limitations. I discovered that this site too allowed dangerous functions to operate. With a little work, I could navigate nearly the entire server disk subsystem at will, read configuration files, discover path information, and then manipulate my blog to gain the functionality I wanted by using the information I had gathered to enable my custom scripts to run. Eventually, the site staff figured out what was happening and disabled many dangerous functions.
In addition to exec and shell-exec, some dangerous PHP functions are suexec, passthru, proc_open, proc_close, proc_get-status, proc_nice, proc_terminate, system, popen, pclose, dl, ini_set, virtual, set_time_limit, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, and escapeshellarg. Go to this URL for other potentially dangerous functions:
http://www.phpbuilder.com/manual/features.safe-mode.functions.php
You can disable functions by adding (or editing) a line in your php.ini file like this:
disable_functions = “shell_exec, suexec, passthru”
More help for configuring PHP can be found at these URLs:
Ayman Hourieh’s Blog
http://aymanh.com/checklist-for-securing-php-configuration
WEB-DOT-DEV–PHP Configuration
http://www.webdotdev.com/nvd/server-side/php/php-configuration.html
PHP Manual
http://us2.php.net/manual/en/security.php
PHP Security Consortium’s PhpSecInfo
http://phpsec.org/projects/phpsecinfo/
Finally, a good resource with lots of other links (including books) is available at the PHP Security Consortium’s Web site:
http://phpsec.org/library/
Secure PHP Configuration by Mark Joseph Edwards, News Editor, mark at ntsecurity / net