Home page logo
/

bugtraq logo 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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]