[17384] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Buffer overflow in iPlanet Web Server 4 server side SHTML

daemon@ATHENA.MIT.EDU (Peter Watkins)
Thu Oct 26 21:52:34 2000

Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l"
Content-Disposition: inline
Message-Id:  <20001026194226.A32552@usa.net>
Date:         Thu, 26 Oct 2000 19:42:26 -0400
Reply-To: Peter Watkins <peterw@USA.NET>
From: Peter Watkins <peterw@USA.NET>
X-To:         Security Research Team <security@RELAYGROUP.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <Pine.LNX.4.10.10010262033370.2882-100000@emx.siamrelay.com>;
              from security@RELAYGROUP.COM on Thu, Oct 26,
              2000 at 08:41:28PM +0700

--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Oct 26, 2000 at 08:41:28PM +0700, Security Research Team wrote:

> Buffer overflow exists in iPlanet Web Server 4.x, which can lead to
> Denial-of-Service or remote execution of code in context of user which iWS
> webserver is running as. 'Parsed HTML' option (server side parsing) must
> be enabled for vulnerability to be exploited.

Please note that (fortunately!) Netscape Enterprise Server 3.6sp3
(offically end-of-lifed but still widely used) does not seem vulnerable.

> Overflow happens in logging function (when iWS tries to report that file
> is not found). If exploitation is successful (or iWS segfaults), nothing
> will remain in the logs.

Note that the watchdog process will restart the Web server, so dumb,
repetitive attacks will only effect a DoS. Intelligent attacks might be
much, much worse. :-(

> FIXES:
>
> Workaround is to disable server side parsing of HTML pages.

Or try compiling the attached NSAPI module and installing as instructed.

The problem is that the iWS programmers (apparently unlike the Netscape
Enterprise Server team before them) didn't grok the bit in the NSAPI
header files that states that there is a max length for error messages
which is, and I quote, "NOT RUN-TIME CHECKED".

What the attached NSAPI module will do, if properly configured, is examine
any request that would be interpreted by iWS as equivalent to .shtml
(which could, and often does, include .html files!). If the URI is too
long, this Service will throw an error and cause NES to skip the remaining
Service blocks, so the buggy parse-html service won't have a chance
to choke on the long URI. Feel free to add in error logging if you like,
no guarantees, etc.

> We are not aware of any vendor fixes for this issue. Vendor has been
> notified on multiple instances (including mass-mailing to every single
> vendor email we could find) about this and other problems during January
> and February (including '?wp tags' - see
> http://www.safermag.com/advisories/0008.shtml). The vendor published a
> workaround for ?wp tags, but we have received no feedback on the SHTML
> problem. On March 23rd we contacted Sun/iPlanet again and on March 24th it
> was suggested to have a conference call / discussion. We never heard from
> them again.

I wish I were surprised by that. And anyone who has an NES/iWS hack,
please give me a shout first so I can take a stab at another band-aid. Not
that I'm standing up for iPlanet (if anything, it should be more
embarassing how quickly outsiders can patch their holes), but I've got
NES/iWS boxes out on the net, and *personally* I'd appreciate advance
notice. Nevertheless, my thanks go to Vanja and The Relay Group for the
disclosure.

-Peter

--
This fall, taxpaying American citizens will elect voting representatives to
the US Congress. Except for those in Washington, DC. http://www.dcvote.org/

--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="PW_max_shtml.c"

#include "base/pblock.h"	/* pblock_findval */
#include "frame/http.h"		/* PROTOCOL_NOT_FOUND */

/*
	PW-max-shtml.so

   Usage:
   At the beginning of obj.conf:
Init fn=load-modules shlib=PW_max_shtml.so funcs="PW-max-shtml" NativeThread=no
   Inside an object in obj.conf (preferably the default object),
   *BEFORE* the parse-html Service!!!:
Service fn=PW-max-shtml maxlen=150 type="magnus-internal/parsed-html"
   maxlen specifies the longest URI that will be allowed through

   This Service throws a 404 for any parsed HTML request whose URI
   is too long, to prevent a fatal error by iWS' parse-html log routine.

 */

NSAPI_PUBLIC int PW_max_shtml(pblock *pb, Session *sn, Request *rq)
{ /* working variables */
    size_t maxUriLength = 150;
    char *requestedURI = pblock_findval("uri", rq->reqpb);

    /* bail out if we've got nothing to work with */
    if (!requestedURI) return REQ_NOACTION;

    if (pblock_findval("maxlen",pb)) {
	maxUriLength = (size_t)atoi(pblock_findval("maxlen",pb));
    }

    /* is the URI long enough to be of interest? */
    if (strlen(requestedURI) > maxUriLength) {
	protocol_status(sn, rq, PROTOCOL_NOT_FOUND, NULL);
	return REQ_ABORTED;
    }
    /* looks OK */
    return REQ_NOACTION;
}

--XsQoSWH+UP9D9v3l--

home help back first fref pref prev next nref lref last post