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
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
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
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
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
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
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
"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"
"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,
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
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!