Bugtraq mailing list archives
Re: Buffer overflow in iPlanet Web Server 4 server side SHTML parsing module
From: Peter Watkins <peterw () USA NET>
Date: Thu, 26 Oct 2000 19:42:26 -0400
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/
Attachment:
PW_max_shtml.c
Description:
Current thread:
- Buffer overflow in iPlanet Web Server 4 server side SHTML parsing module Security Research Team (Oct 27)
- Re: Buffer overflow in iPlanet Web Server 4 server side SHTML parsing module Peter Watkins (Oct 27)