Quoting MadHat <madhatat_private>: > 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
This archive was generated by hypermail 2b30 : Fri Apr 12 2002 - 14:15:54 PDT