The PHP development team would like to announce the immediate availability of PHP 5.4.3 and PHP 5.3.13. All users are encouraged to upgrade to PHP 5.4.3 or PHP 5.3.13 The releases complete a fix for a vulnerability in CGI-based setups (CVE-2012-2311). Note: mod_php and php-fpm are not vulnerable to this attack. PHP 5.4.3 fixes a buffer overflow vulnerability in the apache_request_headers() (CVE-2012-2329). The PHP 5.3 series is not vulnerable to this issue.

Users are encouraged to upgrade their applications, especially those using CGI-based setups. You can find the latest source on the downloads page and the Windows binaries on windows.php.net.

PHP 5.3.12/5.4.2 do not fix all variations of the CGI issues described in CVE-2012-1823. It has also come to our attention that some sites use an insecure cgiwrapper script to run PHP. These scripts will use $* instead of "$@" to pass parameters to php-cgi which causes a number of issues. Again, people using mod_php or php-fpm are not affected.

The rewrite rule is there in the post, ready for copy and pasting into your config. Even if you're running the latest PHP 5.3.12 and 5.4.2., be sure to use this rule as a stop-gap measure for now. Another release is planned for tomorrow to fully correct the CGI flaw.

In the first they detail more of what the bug is, how it could be exploited and link to the original advisory for the problem. Also included are more details on the issue, including sample avenues of attack.

In the second post they look at the recent PHP release and note that it does not completely rid the language of the problem. They point out that the Rewrite rule that's included in their post (not the one on PHP.net) should be used to prevent this issue from effecting your installations.

There is a vulnerability in certain CGI-based setups (Apache+mod_php and nginx+php-fpm are not affected) that has gone unnoticed for at least 8 years. Section 7 of the CGI spec states: 'Some systems support a method for supplying a [sic] array of strings to the CGI script. This is only used in the case of an `indexed' query. This is identified by a "GET" or "HEAD" HTTP request with a URL search string not containing any unencoded "=" characters.'

A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this. Straight shebang-style CGI also does not appear to be vulnerable. If you are using Apache mod_cgi to run PHP you may be vulnerable. To see if you are, just add ?-s to the end of any of your URLs. If you see your source code, you are vulnerable. If your site renders normally, you are not.

You can download this latest version from the downloads page for the source releases or windows.php.net for the Windows binaries. You can look at the Changelog if you'd like more details on the update.

Running PHP via CGI and FastCGI means that IIS has to do the Windows equivalent of fork()ing off PHP processes to do the actual PHP bit. If your box has too many PHP processes running, the box will start to swap. Once a webserver starts swapping, you've no chance in hell of keeping up with all the incoming requests, and your websites on that particular webserver become unavailable in a matter of moments.

The problem seems to have been corrected in the most recent IIS release, though and correct directions can be found here. Older versions of the web server are out of luck, unfortunately.

Lots of programmers like PHP for its ability to code and develop web applications fast. Code-debugging is a lot easier than with PERL or C. However, there is one thing a lot of developers are puzzled about, "How to run PHP Scripts with crontab?"

He explains how cron can be used effectively to replace including a backend script into another file (bad practice) and how to get started with PHP and cron. He includes how to find if you're using a CGI or Apache version of PHP and how to locate the binary. He takes this knowledge and shows how to apply it and put a sample script into the cron file. You can check out sites like this or this for more information on cron itself.

With the recent talk on the blogosphere about deployment (and for Django, and lots of other posts too), people are thinking about PHP a bit more analytically. I think people mostly get it wrong.

He points out that PHP, in essence, is a CGI-style execution and, in being so, makes it more flexible. Both sides, web and command line, can work with the language equally well. He also mentions the developer/administrator split he sees in PHP's structure and how the language facilitates it.

The challenge with securing a shared hosting server is how to secure the website from attack both from the outside and from the inside. PHP has built-in features to help, but ultimately it's the wrong place to address the problem.

His guide steps through the entire process - getting the software, configuring Apache (with the PHP/CGI installation) and configuring suexec, both for the default install and then for the shared server settings. There's even a few brief benchmarks showing the speed of execution for scripts with and without the suexec environment.

First of all, if you'd rather use the .htaccess than the php.ini capabilities of a phpsuexec environment, then shame on you. But, we have some customers who are terrified of php.ini and would rather use the .htaccess. So what? Ok, well there is a workaround.

The connecting piece is the htscanner extension - she includes installation instructions and how to include it into your PHP installation (as well as how to set the PHP values in the .htaccess).

What is FastCGI? I could go on for pages about the technical background, and Microsoft already has some great documentation on the subject, however I'll put it in layman's terms for those who aren't Computer Science majors. [...] CGI is a method that a web server can use for tools like PHP, Perl, or any other language that support it. CGI spawns a new process for each request, which can be really slow. FastCGI speeds this up with a very simple solution '" instead of creating a brand new process for each request, it creates a "pool" of processes and reuses them.

She talks about her usage of PHP on Windows platforms in her work, about a move her company made from Apache to IIS and how much the FastCGI functionality helped. She also briefly explains how to get IIS and FastCGI to work together to make the PHP functionality happen.