lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 10 Apr 2003 01:50:37 -0700 (PDT)
From: Serban Murariu <smurariu2@...oo.com>
To: bugtraq@...urityfocus.com
Subject: 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@...rr.com" <mattmurphy@...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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ