Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:10719
HistoryDec 18, 2005 - 12:00 a.m.

Microsoft IIS Remote DoS .DLL Url exploit

2005-12-1800:00:00
vulners.com
15

Microsoft IIS Remote DoS .DLL Url exploit

Advisory Name
Microsoft IIS Remote Denial of Service (DoS) .DLL Url exploit

Release Date
16. December 2005

Vulnerable
Microsoft® Internet Information Server® V5.1

Not vulnerable
Microsoft® Internet Information Server® V5.0
Microsoft® Internet Information Server® V6.0

Severity
High

Discovered by
Inge Henriksen ([email protected]) http://ingehenriksen.blogspot.com/

Vendor Status
Notified 28. January 2005. No fix will be released until Microsoft® Windows® XP Service Pack 3 (Rumored due late 2006).

Description
I have found that by doing a malformed anonymous HTTP request one can remotely crash the IIS service
process, inetinfo.exe, using just a simple tool like a web browser. The vulnerablity is only present
in folders with Execute Permissions set to Scripts & Executables, examples of vulnerable virtual
folders would be "/_vti_bin" and the like.

Suggested solution
Block all incoming URL's containing "~0", "~1", "~2", "~3", "~4", "~5", "~6", "~7", "~8", or "~9"
(Ignore quotes).

Proof of Concept
By sending the same malformed request four times using just a web browser, an attacker can crash a IIS 5.1 web server service. The attacked virtual directory Execute Permissions must be set to "Scripts & Executables", like "_vti_bin" and "_sharepoint" etc have.

Type the following URL into a browser and refresh 4 times:
http://www.example.xom/_vti_bin/.dll/*\~0

The * can be any of these ASCII characters:
%01-%1f, %3f, ", *, :, <, >

The last \ can also be a /

The last number can be any number from 0 to 9

Geek Technical Description :o)
The reason for the four time "rule" for the process to crash is because of an internal counter inside
the inetinfo.exe process. If you have crashed the process then take a note of the address and restart IIS,
then fire up a debugger and put a breakpoint at the same address. Try the exploit once and when the
process breaks you can have a look at the ECX register, add 0x2C to the value in ECX and have a look at
that address, this is the counter, when the counter hits 0 the IIS process crashes. Its decremented by 1
each time our exploit is executed. With a little investigating I found that the attempted jump to address
0x0 that causes the crash is caused by ntdll.dll returning a value not interpretated correct by IIS. In
other words this is not a buffer/stack overflow exploit and will it therefore not enable anyone to execute
code on the webserver, but then again I'm not sure on this issue and someone might prove me wrong.