The following e-mail will be sent on your behalf.

 has sent the following story to you from ElectricNews.net.

The story is available from https://electricnews.net/news.html?code=7877394

Apache flaw brews controversy 
Wednesday, June 19 2002
by The Register


There is controversy brewing over the announcement of a new Apache vulnerability
similar to the chunked encoding flaws in Microsoft IIS. 

On Monday, Internet Security Systems (ISS)
posted the discovery to the BugTraq mailing list, without knowing the full extent
of the flaw and without giving Apache.org time to investigate and develop a patch
or even propose a workaround, writes Thomas C. Greene. To sugar the pill,
ISS had developed its own patch, which Apache later said does not address all the
issues. Another point in the ISS advisory which Apache disputes is a claim that
only installations on Windows are vulnerable.

 

As it happens, Mark Litchfield of Next Generation Security Software HREF="http://www.nextgenss.com">(NGSS) had made the same discovery but
contacted Apache.org and CERT/CC, so Apache did have an advisory in the works,
which ISS's premature discharge compelled the firm to release. 



On Wednesday morning, the Apache Software Foundation released versions 1.3.26 and
2.0.39 for Unices and Windows, addressing several bugs, including those flaws
first noted by ISS. Users will find both the HREF="http://www.apache.org/dist/httpd">source files and the HREF="http://www.apache.org/dist/httpd/binaries">binary files on Apache's
Web site. 





There was HREF="http://apache.slashdot.org/apache/02/06/17/1948249.shtml?tid=172">a
posting at Slashdot suggesting that ISS was using the premature advisory as a
publicity stunt; and while there is undoubtedly a lot to that, we have to
wonder if there is not something even creepier behind it. Here we see ISS
publishing a vulnerability and a lame patch without so much as consulting the
developer of an open-source product, but we've never seen them try to pull a
stunt like that with Microsoft, say. 



According to ISS, the organisation discovered the flaw during an audit of the
Apache source code. Of course, with Microsoft or Sun or Oracle they would have to
play nice to get at bits of material like that. Was there some calculation that
publishing a gaping hole in a very popular piece of software without warning or
an adequate patch could discredit the open-source community's mechanism for
handling vulnerabilities and create the perception that Apache users had better
sign up for a raft of ISS services because open-source developers cannot take
retaliatory steps to discourage the irresponsible release of vulnerability data?




According to Mark Litchfield's brother David, Apache.org's decision to coordinate
with the vendors was the right call because, "most people who use the Win32
Apache version do not have a compiler and so can't take steps to protect
themselves. They're mostly relying on their Apache 'supplier' to produce a
patch." 



And indeed, the ISS patch is geared towards Win32 and does require the user to
build the binaries. Whether Litchfield's assumption that most users are going to
be stumped is correct or not, the point is a fair one which makes the ISS
'solution' appear disingenuous. 



The flaw affects Apache 1.3 to and including 1.3.24, and Apache 2 to and
including 2.0.36-dev, though in different ways. In the best case it can lead to a
denial of service; in the worst, to remote exploitation. 



"In Apache 1.3 the issue causes a stack overflow. Due to the nature of the
overflow on 32-bit Unix platforms this will cause a segmentation violation and
the child will terminate. However on 64-bit platforms the overflow can be
controlled and so for platforms that store return addresses on the stack it is
likely that it is further exploitable. This could allow arbitrary code to be run
on the server as the user the Apache children are set to run as," Apache says. 



In a response also posted to BugTraq, ISS insists that, "this issue is no more
exploitable or unexploitable on a 32-bit platform than on a 64-bit platform. Due
to the signed comparison, the minimum size passed to the memcpy function is
0x80000000 or about 2Gb. Unless Apache has over 2Gb of contiguous stack memory
located after the target buffer in memory, a segmentation fault will be caused.
If you understand how the stack is used, you will understand that this is an
impossibility." 



But this too is wrong, according to Apache.org's Mark Cox. "They missed a long
to int conversion that happens later in the code. This is one of the reasons that
they should have talked to us before releasing their advisory; we could have
told them that their patch was insufficient and helped them understand the
problem better -- that way users of Apache don't have to follow a silly flame war
on BugTraq and can get down to what matters most; making sure they protect
their servers," Cox told us. 



In any case the wind-up is simple: a malformed request can crash or even lead to
the exploitation of your Apache server, depending on the version. 



The Register and its contents are
copyright 2002 Situation Publishing. Reprinted with permission.