Re: def-2001-05: Netscape Fasttrack Server Caching DoS

[Peter W <peterw () TUX ORG>]

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/