In this issue

This week, new security issues have been announced that affect version 2 of the Apache httpd server.

• Apache 2.0 versions 2.0.35 to 2.0.46 have a bug that can cause a remote Denial of Service. When a client requests that proxy ftp connect to a ftp server with IPv6 address, and the proxy is unable to create an IPv6 socket, an infinite loop occurs.

  This issue was originally discovered by Yoshioka Tsuneo who reported it to the Apache Software Foundation on 25th June 2003. A patch for this issue appears in Apache 2.0.47. The Common Vulnerabilities and Exposures project has assigned the name CAN-2003-0254 to this issue.

• Apache 2.0 versions 2.0.35 through 2.0.46 have a bug in the prefork MPM when handling accept errors. In a server with multiple listening sockets a certain error returned by accept() on a rarely access port can cause a temporary denial of service.

  This issue was originally discovered by Saheed Akhtar who reported it to the Apache Software Foundation on 25th June 2003. A patch for this issue appears in Apache 2.0.47. The Common Vulnerabilities and Exposures project has assigned the name CAN-2003-0253 to this issue.

• A bug in the optional renegotiation code in mod_ssl included with Apache 2 versions 2.0.35 through 2.0.46 can cause cipher suite restrictions to be ignored. This is triggered if optional renegotiation is used (SSLOptions +OptRenegotiate) along with verification of client certificates and a change to the cipher suite over the renegotiation.

  This issue was originally discovered by Ben Laurie and it also affects the mod_ssl module commonly used with Apache 1.3. A patch for this issue appears in Apache 2.0.47. The Common Vulnerabilities and Exposures project has assigned the name CAN-2003-0192 to this issue.

• It is possible to get Apache 2 to get into an infinite loop handling internal redirects and nested subrequests. A patch for this issue appears in Apache 2.0.47 which adds a new LimitInternalRecursion directive.

Apache 2.0.47 was released on 10^th July 2003 and is now the latest version of the Apache 2.0 server. The previous release was 2.0.46, released on the 26^th May 2003. See what was new in Apache 2.0.46.

Apache 2.0.47 is available for download.

This is a security, bug fix and minor upgrade release. Due to security issues, any sites using Apache 2 versions prior to Apache 2.0.47 should upgrade to Apache 2.0.47. Read more about the other security issues that affect Apache 2.0.

• Fix a bug in the handling of accept errors by the prefork MPM when handling accept errors, which could allow a denial of service attack if multiple listeners are configured.

• Fix a bug in the optional renegotiation code in mod_ssl which could cause cipher suite restrictions to be ignored if optional renegotiation is enabled.

• Fix of denial of service attack in mod_proxy's handling of DNS results.

• Prevent the server from crashing when entering infinite loops. The new LimitInternalRecursion directive configures limits of subsequent internal redirects and nested subrequests, after which a request will be aborted.

The following bugs were found in Apache 2.0.46 and have been fixed in Apache 2.0.47:

• Fix a bug in mod_cgid which could cause problems when used with threaded MPMs

• Fix the ExpiresByType directive; handle dynamic content correctly

• Stream rather than batch PROPFIND responses; a significant performance fix as covered previously in Apache Week

• Add support for a "prefer-language" environment variable to mod_negotiation

Reasoning, a provider of automated software inspection services, recently analysed a snapshot of the Apache 2.1 development tree dated January 31, 2003. This resulted in the Apache Defect Report and the Apache Metric Report. You may obtain these two reports from the download section of their website but first you are required to fill in a form before they'll e-mail you the links to the PDF documents.

In their press release, Reasoning state that the development code of the yet-to-be-released Apache 2.1 had a similar defect density when compared to the average defect density of several commercial equivalents. However, these commercial products are not named in their reports. After comparing this recent study with a previous analysis of the TCP/IP protocol stack implementation in Linux kernel version 2.4.19, they conclude that as software applications mature, there is a correlation between code inspection/peer review and the resulting defect density. Here's a list of articles about the inspection including their press release:

• "Reasoning Releases New Inspection Results Shedding Light on Software Code Quality of Open Source Apache Web Server", a press release by Reasoning.
• "Open source code quality endorsed" by Paul Krill at InfoWorld.
• "Code inspection puts Apache on par with commercial Web servers" by Michael S. Mimoso, News Editor of SearchEnterpriseLinux.com.
• "Open Source, Proprietary Code Quality Comparable" by Clint Boulton at internetnews.com.
• "Open and closed source software defects reloaded" by John Leyden at The Register.
• "Opensource Code More Refined Than Closed?" at Slashdot.
• "Study finds early Apache code so-so" by Stephen Shankland at CNET.
• "Reasoning Releases Results of a Software Code Audit of the Apache Web Server" at LWN.net.

A blow-by-blow analysis of the "Apache Defect Report" published by Reasoning (which gained significant press coverage as featured above) was posted by André Malo last week. Reasoning used their automated code inspection tools on a snapshot of the Apache 2.1 unstable tree, and claim to have identified 31 individual "defects" in the code. By continuing André's analysis, the majority of the defects can be classified as occurring in one of three situations, which we'll address in turn:

1. in the handling of an API violation (11 defects)
2. in the handling of malloc failing to allocate memory (11 defects)
3. in the handling of a failure to allocate memory from a pool (5 defects)

It is reasonably standard practice for production C code to make no attempt to gracefully handle API violations; none of these eleven "defects" can really be said to demonstrate incorrect code. One of this set of eleven (defect number 21) even included a comment explaining this pratice in the section of code quoted in the report.

Traditionally, Apache code does not attempt to recover from memory allocation failures; this is one of the problems hidden by the pools interface, which will abort the process if it cannot allocate memory. André noticed that in Apache 2.0 this feature of the pools code was not in fact enabled - one genuine bug, rather than five. Of the eleven places where memory was allocated directly rather than using pools, only two changes would need to check for allocation failure. In total these sixteen "defects" are the result of just three bugs.

Of the remaining four defects given in the report, two occur in the support tools ab and htdigest, and two in server code; these all appear to be valid bugs. That "31 defects" can be reduced to a total of seven bugs illustrates that the results of automated code analysis tools need careful human interpretation to be of practical value. The use of such results as a metric for code quality appears to be questionable at best.