|
Brought to you by:
Suppliers of:
|
|
|
| |
| 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. |
| |
Credit:
The information has been provided by Marc Maiffret.
|
| |
Systems Affected:
* Microsoft Windows NT 4.0 Internet Information Services 4.0
* Microsoft Windows 2000 Internet Information Services 5.0
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 is not 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 look aside lists. The first four-byte address, which in our example is overwritten by "DATA", is an address that is 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. Because we supplied addresses that are not associated with valid look aside 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.
Vendor Status:
Microsoft has released a security bulletin and patch:
http://www.microsoft.com/technet/security/bulletin/MS02-018.asp
|
|
|
|
|
