[Prev][Next][Index][Thread]

hackers can provoke cache disasters



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.