Bugtraq mailing list archives
Re: def-2001-05: Netscape Fasttrack Server Caching DoS
From: Peter W <peterw () TUX ORG>
Date: Mon, 22 Jan 2001 23:38:20 -0500
On Mon, Jan 22, 2001 at 01:30:33PM +0100, Peter Gründl wrote:
Defcom Labs Advisory def-2001-05
Oooh, how fancy! ;-)
----------------------=[Detailed Description]=------------------------ The Fasttrack 4.1 server caches requests for non-existing URLs with valid extensions (eg. .html). The cached ressources are not freed again (at least not after half an hour), so a malicious user could cause the web server to perform very sluggishly, simply by requesting a lot of non-existing html-documents on the web server. ---------------------------=[Workaround]=----------------------------- None known.
I can't test these because iPlanet's download system is too broken, stupid, and annoying for me to grab iWS ft 4.1 to verify, but: Almost certainly effective workaround #1: Disable caching per http://help.netscape.com/kb/corporate/20000313-1.html Probable workaround #2: Most of the NES/iWS built-in functions are cache-safe. That is, using them does not prevent the server from using its cache accelerator. Some functions are conditionally cache-safe, e.g. the "flex-log" function is cache safe with the default configuration, but if certain attributes of requests are logged, then the cache cannot function. 3rd-party functions are assumed to be cache-unsafe unless they explicitly set the rq->directive_is_cacheable flag (see http://developer.netscape.com:80/docs/manuals/enterprise/nsapi/svrplug.htm) so you should be able to write a quick NSAPI module like this: NSAPI_PUBLIC int PW_null(pblock *pb, Session *sn, Request *rq) { /* note we do not touch rq->directive_is_cacheable */ return REQ_NOACTION; } and then use that in obj.conf, e.g. # near the top of obj.conf Init fn="load-modules" shlib="/path/to/PW_null.so" funcs="PW-null" # # inside your Object config Error reason="Not Found" fn="PW-null" # then your regular 404 handler, e.g. Error reason="Not Found" fn="send-error" path="/path/to/errorpage.html" This should make iWS realize that the file not found URLs are not cacheable, without affecting other documents. I also expect that sites using query-handler instead of send-error for their 404 errors won't have the problem Herr Gruendl describes.
-------------------------=[Vendor Response]=-------------------------- This issue was brought to the vendor's attention on the 7th of December, 2000. Vendor replied that the Fasttrack server is not meant for production environments and as that, the issue will not be fixed.
Also worth noting is that there do not seem to be *any* service packs for iWS FastTrack 4.1. Since iWS Enterprise has had at least one huge hole (remote code execution via SSL/TLS implementation bug), I expect that iWS FastTrack is an awfully dangerous app to make available to others. Probably a good idea to limit iWS ft to local access with some sort of on-host firewall or packet filter. I assume you have not found iWS Enterprise Edition to be vulnerable? -Peter http://www.tux.org/~peterw/
Current thread:
- def-2001-05: Netscape Fasttrack Server Caching DoS Peter Gründl (Jan 22)
- Re: def-2001-05: Netscape Fasttrack Server Caching DoS Peter W (Jan 23)