RE: Windows 2000 and NT4 IIS .ASP Remote Buffer Overflow

[damdum <damdum () ghettohackers net>]

Quoting MadHat <madhat () unspecific com>:

> Thanks, but I must have missed where the 100 continue return code was
> the defining factor of vulnerability.

When doing chunked posts, its my understanding you will always get a 100
continue.  So, if this is fixed or fed in wronge, you would still get 100
continue, but no crash.

Initially I used netcat and cut/pasted the request in.  The behavior was when it
didn't cause the exception as when it did. (See below comments on how to
remotely tell if it crashed).

> I can get this to return, but I have no way to verify vulnerability that
> I can see.  The original description released by Marc said that a popup
> appeared and that a message was entered in the Application Event log. 
> Since I can not reproduce either of these symptoms, how do I verify
> vulnerability.  If I send the same data as below to a patched host, it
> still comes back with the 100 continue return code.

If you do not get the pop-up and log entries, you have not caused the overflow.
 Once you have caused this error another request for issstart.asp will give a
500 error.

So, to test, run the perl script, then do GET /isstart.asp HTTP/1.0\r\n\r\n. 
Response should be "HTTP/1.1 500 Server Error".

Note: This is using default IIS as with W2K Adv Serv, so iisstart.asp is using
"medium" security, not sure if this changes with high.

> Oh and on the locked up I mentioned before, I meant that HTTP session
> locked, not IIS itself.  Not something I can count on, since it didn't
> seem to happen every time and did not seem to produce any of the signs
> noted in the advisory.

Using this request you will never "return" from the 100 continue.  So you will
need to reconnect for another request.

I have only tested this on a fresh install of Windows 2000 Advanced Server w/o
any patches.  It is easier to test using a w2k box & telnet, as you will send
the proper \r\n and can just cut/past and hit return.

damdum