In this issue

A change was proposed recently to allow the ServerTokens directive to change the product name returned in the Server header, for example using ServerTokens Set IIS/5.0. Some server administrators request such a feature in the belief that it will improve security, under the assumption that attackers will not try Apache exploits if the server is running IIS. In reality, a determined attacker will easily be able to determine what software the server is running without relying on the Server header, so this feature has no real security benefit. As usual, there was strong opposition to the change: determined server administrators can still change the Server string at compile-time without needing a configuration option.

In the last month, two reports have been sent to the bugtraq mailing list by Steve Grubb concerning methods of hijacking Apache servers using PHP or mod_perl. The reports are made under the assumption that these two modules can be safely used to execute scripts written by untrusted authors, and include examples of how such scripts can take over the processing of incoming HTTP or SSL requests.

PHP (when used as an Apache module) and mod_perl are similar in that they both process, interpret, and execute scripts from within an Apache httpd child process. This means that the privileges available to an httpd child process are also available to the script interpreters: this includes, naturally, the ability to accept new requests from clients. Since all child processes run with the same user ID, it is also possible to use signals to terminate or stop one child process from within another.

Unlike languages like Java, the interpreters for languages such as PHP and Perl were not designed to provide a carefully restricted "sandbox" in which code is executed. Perl code is essentially unlimited in the facilities available, as most C library functions and resources are readily usable. PHP code is somewhat restricted in capability, although issues in the interpreter and myriad extension modules have been repeatedly shown to allow scripts to escape the "sandbox" in recent times.

The conclusion is that the scripts used with any current in-process scripting modules with Apache must be trusted with the privileges of the httpd child process in which they execute. For execution of less-trusted scripts, different solutions must be used such as CGI under suexec - sacrificing performance for security.

James Maguire asks "Who patches Open Source?". With closed source vendors it's easy to know who to turn to if you have a problem with the software you have purchased, but in turn you are also locked into getting your fixes from that same vendor. This article takes a look at the difference with Open Source software and in particular the Apache web server which is shipped by a large number of vendors. Due to the transparency of open source, a Linux user can turn to their distribution vendor to fix an issue, or to the Apache Software Foundation, or to one of a number of third parties that provide paid-for support.

If you've ever wondered which Apache developer took his dog for a walk last night, or quite where in the world it is snowing today, then you'll be riveted to the brand new Apache blog aggregator, Planet Apache. Joking aside, the site aims to give an insight into the lives of the Apache members, and more importantly gives Apache developers the chance to learn about their peers. With hundreds of Apache committers, many who have never met, this site will play an important part in helping to build the Apache community.

Emiliano Abramzon and colleagues look to see if Apache is a good example of an Internet Generation Company in their academic paper: "Apache.org: The Ultimate Internet Generation Organization" (PDF, 1Mb). They conclude that Apache has a significant competitive advantage to software competition from the entire openness and transparency.

In this section we highlight some of the articles on the web that are of interest to Apache users.

Nick Kew takes Apache Week readers through an extensive look at reverse proxying in his article "Running a Reverse Proxy with Apache". He includes details of his mod_proxy_html module which can solve the common problems associated with running reverse proxies by methods such as rewriting links.

Apache essentials are covered in "Apache Basics" at unixreview.com.