- From: Roman Czyborra <czyborra@cs.tu-berlin.de>
- Date: Thu, 13 Apr 1995 09:05:49 +0200
- To: The Proxy Forum <www-proxy@w3.org>
- Cc: www@cs.tu-berlin.de, pannier@cs.tu-berlin.de
The CERN 3.0 httpd does not handle extra large documents very well. Some hacker created an endless document in http://www.artcom.de/cgi/sse/CCC/gifs/warning.gif When our proxy tried to load this horse, it slowly filled up our disk: 95-04-06 Thu 15:22 888303 KB used (89%), 106714 KB free 95-04-06 Thu 15:52 901135 KB used (91%), 93882 KB free 95-04-06 Thu 16:22 912292 KB used (92%), 82725 KB free 95-04-06 Thu 16:52 923960 KB used (93%), 71057 KB free 95-04-06 Thu 17:22 938445 KB used (94%), 56572 KB free 95-04-06 Thu 17:52 953378 KB used (96%), 41639 KB free 95-04-06 Thu 18:22 969322 KB used (97%), 25695 KB free 95-04-06 Thu 18:52 984735 KB used (99%), 10282 KB free 95-04-06 Thu 19:22 993535 KB used (100%), 1482 KB free 95-04-06 Thu 19:52 995019 KB used (100%), 0 KB free 95-04-06 Thu 20:22 995019 KB used (100%), 0 KB free 95-04-06 Thu 20:52 995022 KB used (100%), 0 KB free /home/www/cache/http/www.artcom.de/cgi/sse/CCC/gifs/ contained: total 96948 -rw-r--r-- 1 www 3304 Apr 6 12:50 chaos18d.gif -rw-r--r-- 1 www 49668096 Apr 6 22:16 chaos18g.gif.cache_lock -rw-r--r-- 1 www 49537024 Apr 6 22:16 warning.gif.cache_lock Unlinking those big babies didn't free disk space until I SIGKILLed the respective processes. They were still running even though the connection to the requestor had long been lost. Consequently I've added NoCaching http://www.artcom.de/cgi/* to our configuration http://www.cs.tu-berlin.de/usr/www/etc/x-httpd. Still, the vulnerability remains and ought to be fixed. The CERN Server User Guide doesn't provide the details babysitters are interested in, like why SIGTERM is forwarded to the parent process or what file operations (link, unlink, chmod?) can safely be can be performed manually in the cache directory without interfering with the cache consistency.
Received on Wednesday, 12 April 1995 22:06:10 UTC