scx-sa-08.txt

2000-11-05T00:00:00
ID PACKETSTORM:23519
Type packetstorm
Reporter Zoa_Chien
Modified 2000-11-05T00:00:00

Description

                                        
                                            `  
=====================================================================  
Securax-SA-08 Security Advisory  
belgian.networking.security Dutch  
=====================================================================  
Topic: IIS4.0 Denial Of Service (part 1)  
Announced: 2000-11-03  
Updated: 2000-11-03  
Affects: IIS 4.0  
None affected: Apache, IIS 3.0, IIS5.0  
Obsoletes: /  
=====================================================================  
  
THE ENTIRE ADVISORY HAS BEEN BASED UPON TRIAL AND ERROR  
RESULTS. THEREFORE WE CANNOT ENSURE YOU THE INFORMATION BELOW IS  
100% CORRECT. THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT PRIOR  
NOTICE.  
PLEASE, IF YOU HAPPEN TO FIND MORE INFORMATION CONCERNING  
THE BUG DISCUSSED IN THIS ADVISORY, PLEASE SHARE THIS ON BUQTRAQ.  
THANK YOU,  
  
  
First:  
  
In the past, several bugs were found that look very similar to the one discussed here,   
(http://www.securityfocus.com/bid/1101)  
(http://www.securityfocus.com/bid/1642)  
(the ./././././ DoS by USSRlabs)  
  
However, I think this is a new one, (I found servers that were not vulnerable to the above   
bugs, but were vulnerable to this one... ofcourse I could be wrong.. my apologies if this is  
the case.   
  
I. Background  
  
While beta testing a new stress tool, I noticed that "forbidden" unicode representations   
for the ascii "0" character such as %C0%80 and %E0%80%80 were handled as correct  
filenames on IIS4.0 check "http://www.securitywatch.com/%C0%80"  
(Btw: this site is not vulnerable to the DoS! )  
  
Normally that should result in a 404, but instead it returns a 200.  
(Try to use it on a server that does relaying .. fun to see :-)  
  
On IIS5.0 (e.g. www.microsoft.com) this will not return a 404 nor a 200 but a 302, with an  
invalid header, causing browsers to panic..   
  
II. Problem Description  
  
If we create a very long URL with /%C0%80/%C0%80% [...snip...] C0%80 IIS will   
stop functioning until the complete string is interpreted / decoded.  
  
If the string does not return a 404 on IIS4, try to add an existing directory to the string.  
  
It might be possible to use this "feature" in combination with other (future?) exploits.  
(like those +230 %20's with .htw)   
  
  
I think the DoS problem is solved with the latest UNICODE patches... although those  
strings still return a 200 code... and they obviously should not.  
  
Maybe using multiple sockets would allow it to be used on IIS5.0 too. (not tested)  
  
  
III. Impact  
  
This denial of service should not work on well configured IIS servers, but we all know  
these are in a minority.  
  
IV. Solution  
  
Be sure to install all IIS patches ever released, that should be sufficient ?  
Following the Microsoft recommended limitation for urls should also do the trick.  
  
Just set the following registry entry to the maximum-length URL you want to accept:  
Hive   
HKEY_LOCAL_MACHINE \SYSTEM  
Key  
CurrentControlSet\Services\W3SVC\Parameters  
  
Name  
MaxClientRequestBuffer  
  
Value Type  
DWORD  
  
  
  
V. Credits  
  
Zoa_Chien (zoachien@securax.org)   
Segfau|t (for fixxin mi speling eroors)  
  
VI. Source code  
none.  
  
  
  
  
`