Slashdot Mirror
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.
I don't intend this to be an "I told you so!"
... because IIS had a more serious problem with chunking
Good
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.
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.
Also FatPhil on SoylentNews, id 863
Updated releases of both 1.3 and 2.0 that fix this problem will be released VERY shortly.
> PHP doesn't work on 2.0 yet, so upgrading to 2.0 is not an option for us. Now what?
Meanwhile, if you HAVE to use Apache 2.0, run PHP as CGI and you will avoid the version hassle (ofcourse loosing on performance etc). Anyway, it won't take long now to have PHP4 working good as module with 2.x, as the big guys are saying that the Apache API is now kind of stabile for 2.x series.
I am running Apache 2.0.36 and PHP 4.1.2 at the moment. It's stable enough, and quite easy to install. .php thing in the conf file too. Search on Google if I'm none too specific ;)
Install Apache from source, then configure PHP with --with-apxs2=/path/to/apache2/bin/apxs and install.
Do the x-httpd-application
Get your own free personal location tracker
Oh no! User nobody is wreaking havoc!
/tmp (if it needs a temp folder, it gets it's own.)
nobody doesn't even have a login on my box
Too bad.. on most systems, the 'nobody' account has WAY too much power to run daemons. Running daemon processes as 'nobody' is a security faux-pas. The 'nobody' account should only be used by NFS (NFS maps 'squashed' userIDs to nobody.)
For every daemon running with 'nobody' permissions (or any shared 'daemon' UID), the security risk increases exponentially, as a flaw in one daemon means access to the process data of all of the others.
Each daemon should have it's own UID, with file permissions set accordingly, ie. write access to the pid and log files, and usually nothing else, not even
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
----
Versions of the Apache web 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. This bug can be triggered remotely by sending a carefully crafted invalid request. This functionality is enabled by default.
In most cases the outcome of the invalid request is that the child process dealing with the request will terminate. At the least, this could help a remote attacker launch a denial of service attack as the parent process will eventually have to replace the terminated child process and starting new children uses non-trivial amounts of resources.
We were also notified today by ISS that they had published the same issue which has forced the early release of this advisory. Please note that the patch provided by ISS does not correct this vulnerability.
The Apache Software Foundation are currently working on new releases that fix this issue; please stay tuned here at http://httpd.apache.org/ for updated versions as they become available.
[Link to full advisory follows at http://httpd.apache.org/info/security_bulletin_200 20617.txt ]
OKAY, HERE'S THE OFFICIAL WORD FOR THE NIGHT:
1.3.25 and 2.0.39 have been tagged in CVS. Both versions have the vulnerability fixed. They will be released first thing in the morning.
While this is not a proper fix for the real problem, it will prevent the bug being remotely exploited:
ISS X-Force response (fwd)
For mirrors: http://www.apache.org/dyn/closer.cgi/httpd/
For direct download: http://www.apache.org/dist/httpd/
For the announcement: http://httpd.apache.org/