iis.asp.overflow.txt

`Windows 2000 and NT4 IIS .ASP Remote Buffer Overflow  
  
Release Date:  
00/00/2002  
  
Severity:  
High (Remote code execution)  
IWAM_MACHINE Privilege Level  
  
Systems Affected:  
Microsoft Windows NT 4.0 Internet Information Services 4.0  
Microsoft Windows 2000 Internet Information Services 5.0  
  
Description:  
  
A vulnerability in the ASP (Active Server Pages) ISAPI filter, loaded by  
default on all NT4 and Windows 2000 server systems (running IIS), can be  
exploited to remotely execute code of an attackers choice. The fault lies  
within the decoding and interpretation of form data received by malicious  
clients. By chunk encoding form data we can force IIS to overwrite 4 bytes  
of arbitrary memory with data we supply.  
  
This is a very serious vulnerability and eEye suggests that administrators  
install the Microsoft supplied patch as soon as possible.  
  
The following example will show the vulnerable condition. We will use a  
default .asp page left after install on a Windows 2000 server with the  
latest service packs.  
  
Example:  
  
  
**************Begin Session****************  
POST /iisstart.asp HTTP/1.1  
Accept: */*  
Host: eeye.com  
Content-Type: application/x-www-form-urlencoded  
Transfer-Encoding: chunked  
  
10  
PADPADPADPADPADP  
4  
DATA  
4  
DEST  
0  
[enter]  
[enter]  
**************End Session******************  
  
Technical Description:  
  
The example session above causes the default exception handler to execute  
from within the dllhost child process. When the default exception handler  
executes a window will open with this message:  
  
  
DLLHOST.EXE - Application error  
The instruction at 0x77fcb397 referenced memory at 0x54534544  
  
Notice that 0x54534544 is the hex representation of "TSED", or the value  
"DEST" in little endian format. The DLLHOST.EXE process is trying to copy  
"DATA" to "DEST". Because there isn't writeable memory at 0x54534544, an  
access violation occurs and the structured exception handling (SEH) within  
the NT kernel catches it and kills the child dllhost.exe process.  
  
The crux of this problem lies in the fact that the memory we overwrite with  
our data contains Heap Management header structures, in our case being used  
by AllocateHeap(). Specifically, as we overwrote the header, we control two  
four byte addresses within it. These addresses are associated with the  
population and use of lookaside lists. The first four-byte address, which in  
our example is overwritten by "DATA", is an address that gets copied to the  
second four-byte address specified in header. We have also overwritten the  
second address, this time with "DEST". By overwriting these two addresses,  
we can put four bytes anywhere in memory that the child dllhost.exe has  
privileges to write to. This allows us to overwrite function pointers,  
saved instruction pointers, exception handlers, or anything else that will  
allow us to control the flow of execution into our payload. We have been  
most successful in exploitation by overwriting a structured exception  
handler address on the stack. Due to the fact that we supplied addresses  
that aren't associated with valid lookaside lists, an exception handler will  
be called, and when it does, it will call our modified routine, which points  
directly into payload code.  
  
It should be noted that while this vulnerability exists in the .ASP ISAPI, a  
mechanism is still required to get the malicious request to hit the  
vulnerable functions within the .ASP ISAPI. Although pages with form  
submissions make it easier to demonstrate this vulnerability, there are  
other methods for causing code to execute beyond the form variable  
referencing. In the above example we used a default .asp file that has  
script code within it that deals with .ASP Server Variables. When the .ASP  
ISAPI performs processing on the Server Variables, we are able to cause an  
overflow and execute code. There are .asp files by default in IIS that allow  
processing of Server Variables, which make it possible to demonstrate the  
existence of this vulnerability on default installations.  
  
Like most of the IIS vulnerabilities eEye has discovered in the past,  
firewalls and intrusion detection systems do not protect from this  
vulnerability.  
  
SecureIIS - Application Firewall for Microsoft IIS  
  
It should be noted that clients using SecureIIS 1.2.5 and above are secure  
from this vulnerability. This vulnerability was discovered by the eEye team  
while testing a new version of SecureIIS to help further its protection  
abilities. To learn more visit http://www.eeye.com/SecureIIS  
  
Vendor Status:  
Microsoft has released a security bulletin and patch:  
http://www.microsoft.com/technet/security/bulletin/MS02-018.asp  
  
Credit:  
Discovery: Riley Hassell  
Exploitation Research: Riley Hassell and Ryan Permeh  
  
Greetings:  
To all the people who continue to make the security industry more exciting  
with innovative research. Also to the rest of eEye, who help make all this  
magic possible.  
  
Copyright (c) 1998-2002 eEye Digital Security  
Permission is hereby granted for the redistribution of this alert  
electronically. It is not to be edited in any way without express consent of  
eEye. If you wish to reprint the whole or any part of this alert in any  
other medium excluding electronic medium, please e-mail [email protected] for  
permission.  
  
Disclaimer  
The information within this paper may change without notice. Use of this  
information constitutes acceptance for use in an AS IS condition. There are  
NO warranties with regard to this information. In no event shall the author  
be liable for any damages whatsoever arising out of or in connection with  
the use or spread of this information. Any use of this information is at the  
user's own risk.  
  
Feedback  
Please send suggestions, updates, and comments to:  
  
eEye Digital Security  
http://www.eEye.com  
[email protected]  
  
`