With all the attention paid to Microsoft problems, those who use other software must be careful to avoid becoming complacent. That was reinforced recently when ISS (Internet Security Systems) reported a problem that its researchers had found in many versions of the popular Apache server. The problem in Apache actually does exist and has the current designation CAN-2002-0392. But The Apache Software Foundation warns that you shouldn’t rely on the ISS patch, which they claim is flawed.

The vulnerability itself can result in a DoS event or allow an attacker to run arbitrary code on the Apache server, depending on the version. Next Generation Security Software also discovered the vulnerability and it had been working behind the scenes with Apache to release a complete patch when ISS went public with the flaw, releasing a patch developed independently of Apache.org.

The official CERT advisory CA-2002-17 lists comments by various vendors about whether their default software as shipped is vulnerable to this Apache threat.

Risk level: Serious but difficult to exploit
This vulnerability can cause different results in different versions, but they range from a denial of service event to complete compromise of the server.

According to Apache.org, Apache software versions 1.2.2 through 1.3.24 and 2.0 through 2.0.36-dev. have a bug in the way the software deals with invalid HTTP 1.1 requests. The vulnerability exists in the default installation settings, so this is a major threat that applies to both the Windows version of Apache and 64-bit (but not 32-bit) UNIX platforms.

In early Apache versions, the vulnerability causes a stack overflow. This simply forces the process to terminate on 32-bit UNIX systems, but it can allow the attacker to run arbitrary code on the server in a 64-bit UNIX environment. This is also the case in a Windows environment. In both instances, the problem lies in Apache code, not the operating system.

On a 2.x system, the problem is detected by the software and the attacker can’t run arbitrary code, but in some circumstances, it could trigger a denial of service event.

Mitigating factors
CERT describes this as “a remotely exploitable vulnerability” involving the way Apache servers handle chunk-encoded data described by  RFC2616 and permitted by HTTP 1.1.

Fix: Upgrade to the latest versions
Apache.org recommends that users of Apache 1.3 upgrade to 1.3.26 and users of Apache 2.0 upgrade to 2.0.39, which address these vulnerabilities. The group says that it was developing this fix when ISS released information about the vulnerability to the public.

This situation is about more than a flaw in a popular piece of open source software. According to the report in The Register, ISS didn’t appear to understand the real nature of the flaw and prematurely released a patch that didn’t really fix the vulnerability.

There’s no requirement, as far as I know, to notify a company of a newly discovered bug before posting it to BugTraq or in a mailing list, but it certainly is a good idea if your ultimate goal is to protect users. This also appears to be the standard operating procedure adopted by many security companies, which at least try to work with the vendor before making a new vulnerability public and that only go public as a last resort if they are ignored by vendors.

Linuxsecurity.com reports that millions of Web sites are now vulnerable because ISS made a public announcement, and it describes the ISS patch as “insufficient.”

Final word
I believe some fault lies with the way ISS handled this situation, particularly in failing to completely analyze the problem and prematurely releasing a patch that most people have agreed is flawed or, at best, fixes only part of the problem.

ISS pointed out that it isn’t required to notify open source software developers and that, in any case, its patch did work to prevent the overflow that would allow arbitrary code to run. It added, “If the DoS issue is unrelated, then of course the ISS patch will not be of any help.”

Nevertheless, it concerns me when I see a security notice where the company releasing it didn’t first try to work with the publisher of the software. I try my best to fully investigate any claims before lending them additional credit by discussing them in this column.

This incident should be a reminder that security companies get something out of finding and announcing vulnerabilities: publicity for their services. I have no problem with that. The profit motive has generally served us well in this business, and companies should get something in return for all the work they do in dissecting code to locate problems that users should know about. But there is such a thing as going too far and, as with Caesar’s wife, these companies must not only remain above suspicion, they should remain above even the appearance of impropriety.

To many people, that means verifying and reverifying the vulnerability and then sharing this information with the developer and at least making an attempt to work with them before releasing the news to the public. Above all, you don’t win many points with administrators by releasing information that could open up systems to hackers when a vendor is already working on a fix. All security experts need to be careful when releasing this sort of information, even if they are technically correct in everything they do. And administrators should always be careful when working with software patches that come from third parties rather than from the original software vendor.