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/
