In this issue

Major flaws have been found in the popular PHP scripting language commonly used with Apache web servers. These flaws have been found in the way PHP handles multipart/form-data POST requests. Each of these flaws could allow an attacker to execute arbitrary code on the remote system. All versions of PHP from 3.10 to 3.18 as well as 4.0.1 to 4.0.6 are vulnerable.

All users of PHP need to protect themselves immediately in one of the following ways:

• Apply the security patches available from the PHP download page to your current version of PHP, recompile, and restart your server. If you obtained PHP through a distribution of an operating system, check with the distributor to see if they have a packaged fix available. For most cases this will be the fastest and most painless upgrade.

• If you are not using PHP functionality on your site you can disable the PHP modules. Look for the PHP LoadModule directive in your httpd.conf file, comment it out, and restart your server. If you have PHP compiled statically into your server you need to recompile without it.

• If you are using PHP 4.0.3 or greater you can disable the vulnerable PHP upload feature. Edit httpd.conf and add the following line after the LoadModule lines, then restart your server.

  php_admin_value file_uploads off

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0081 to this issue. More information about this vulnerability is available from CERT Advisory CA-2002-05

A buffer overflow has been found in mod_ssl in all versions prior to 2.8.7-1.3.23 (February 23rd 2002). All versions of Apache-SSL prior to 1.3.22+1.4.6 are also vulnerable to this issue.

This overflow can occur in the dbm and shm shared memory session cache. The default configuration of mod_ssl is not vulnerable, and in practice it is unlikely to be a security problem for many sites. To exploit the overflow, the server must be configured to allow client certificates, and an attacker must obtain a carefully crafted client certificate that has been signed by a Certificate Authority which is trusted by the server. Only the dbm and shm (also known as shmht) session caches are vulnerable.

Fixed versions of both mod_ssl and Apache-SSL are now available. Users who use client certificate authentication would be wise to upgrade or if using mod_ssl switch to the superior shared memory session cache, shmcb.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2002-0082 to this issue.

A frequently requested Apache feature popped up again this week when a patch was submitted to allow mod_log_config to handle log file rotation internally. The solutions traditionally used with Apache are to either use piped logs and an external process like rotatelogs, or by automatically restarting the server periodically. An alternative solution is needed to make Apache's support for NetWare complete, since NetWare has no support for pipes. A mod_log_nw module was added to the NetWare port of 1.3.

In an effort to make the httpd project's bug list more manageable there are plans to migrate from the GNATS bug management system to Bugzilla, which is already used at the ASF by the Jakarta project. The GNATS database currently lists 2251 open bugs; the earliest being PR#2072 with the handling of the %T token in custom log format strings filed against a beta release of 1.3. Other bug management systems proposed for evaluation were Scarab and rt.

According to the latest SSL survey data from Netcraft (available by annual subscription), 93% of SSL sites that had valid third party certificates were capable of using strong encryption. This percentage has increased dramatically since the expiration of the RSA patent and the opening of US export controls; In September 2000 only 79% of sites were capable of strong encryption.

In the public Netcraft survey, Apache and Apache-based servers are back up to 59.9% market share after some recent small falls. Meanwhile, vnunet.com report on Smutcraft and find that a whopping 84% of porn sites are kept up by Apache.

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

We are back with four more mod_perl articles by Stas Bekman. Been dreaming of providing mod_perl services but don't know where to begin? Then "Finding a mod_perl provider or becoming one" is for you as it talks about the nuances of providing mod_perl services and presents a few ISPs that successfully do that.

Next we have the "Improving a mod_perl Driven Site's Performance" series. "Part I: Choosing Operating System and Hardware" delves into the characteristics and features of the OS and machine required to support a mod_perl enabled Apache web server. Brace yourself for a discussion on clustering, "fail-over", load balancing, NIC, RAM, RAID, "hot-swappable" systems, CPU, RDBMS, memory leaks, connectivity, bandwidth, and last but not least cost.

Now that your hardware and software are up and running, it's time to optimise the performance. Before you can do that, you'll need a measurement tool so "Part II: Benchmarking Applications" performs some number crunching and examines a few utilities: using the Benchmark.pm and Time::HiRes module to write your own tool, ApacheBench (ab), httperf, http_load, Apache::Timeit module, and a modified crashme suite originally written by Michael Schilli.

After a much deserved coffee break, you should be all geared up for more tools and more number crunching in "Part III: Code Profiling and Memory Measurement Techniques" which will help you identify which segments of code need to be optimised. The examples use the Devel::DProf, Apache::DProf, Apache::VMonitor, and GTop modules. Thirsty for more? We're afraid you'll have to wait until next week!

"Using SOAP with Tomcat" shows you how to use the Remote Procedure Call (RPC) method to invoke SOAP services. It guides you through the various steps by first listing all the required components, and then deploying a SOAP Web application to Tomcat before implementing a sample SOAP application - a simple integer calculator, which comprises a SOAP service for handling the calculator functions, and a client to access the service.

Mark Weaver got to know the Apache MaxClients directive the hard way. By pouring his heart out in this article, he hopes that we may learn from his mistakes. It all boils down to RAM and bandwidth so his advice is to set your MaxClients directive to a realistic number according to the amount of resources available in your system or be prepared to face the consequences of Apache swapping memory vehemently. An entertaining piece written in a humorous manner, yet manages to drive home the point.

Evolt.org is proud to present "Stopping Spambots II - The Admin Strikes Back", the sequel to "Using Apache to stop bad robots". This time it blocks the "Spiderts" [sic] by using their IP address instead of their User-Agent value so that they can't slip through by masquerading as other commonly used clients. It also automates the task of parsing the access_log to retrieve IP addresses which access the "honey-pot" directory, and updating the banned list by using a Perl script (source code provided). Don't forget to read its readers' comments too!