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
