Apache Vulnerability Announced

Aaron writes "Versions of the Apache HTTP Server up to and including 1.3.24 and 2.0 up to and including 2.0.36 contain a bug in the routines which deal with invalid requests which are encoded using chunked encoding. In some cases it may be possible to cause a child process to terminate and restart, which consumes a non-trivial amount of resources. See the official announcement and stay tuned here for updated versions." This is in response to the rather uninformed and questionable security notice by ISS X-Force, about a bug that has already been mentioned on the public mailing lists for Apache and is fixed in CVS for Apache 2.0. I am also told that their patch doesn't fully solve the problem. I am sure though that by awaking us to the problem they will get a lot of great press just like any of the other companies currently using useless bug announcements as press releases.

Comments

Impact on *nix platforms

[jukal]

From the bulletin:
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.

It seems that thanks to the *nix way of handling processes and their childs, this represents minor threat than on other platforms, in which it is even more easily exploitable as a DOS attack. However, this is not minor news eve for us using *nix breeds.

Re:Apache team not trusted

[fatphil]

From

- len_to_read = (r->remaining > bufsiz) ? bufsiz : r->remaining;

to

+ len_to_read = (r->remaining > (unsigned int)bufsiz) ? bufsiz : r->remaining

is _not_ a fix. It's a total kludge. If a variable can contain a value that exceeds the range of its type, such that it has a different value when cast to unsigned type, the _the variable is of the wrong type_, and _that's_ the problem that needs to be fixed.

This is nothing but lousy Elastoplast.

FP.

ISS Responds

[btellier]

from Bugtraq a few minutes ago:

---
ISS has requested that I forward this response to the list.

----------

This vulnerability was originally detected auditing the Apache 2.0 source
tree. Apache 2.0 uses the same function to determine the chunk size, and
has the same vulnerable signed comparison. It is, however, not vulnerable
(by luck?) due to a signed comparison deep within the buffered reading
routines (within core_input_filter).

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.

Apache on "Win32" is not exploitable due to any "64-bit" addressing issues.
It is easily exploitable due to the nature of structured exception handling
on Windows and the fact that exception handler pointers are stored on the
stack.

If the DoS vulnerability is related to the overflow then the ISS patch will
work to prevent it. The unsigned comparison prevents any stack overflow and
as a result any related DoS issue is prevented. If the DoS issue is
unrelated, then of course the ISS patch will not be of any help.

ISS X-Force
----