=====================================================================
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, 
 (https://www.securityfocus.com/bid/1101)
 (https://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 "https://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.