[14744] in bugtraq
Re: Windows NT/95/98/Possible Others Denial of Service Attack.
daemon@ATHENA.MIT.EDU (Jeff Dafoe)
Tue May 2 17:04:29 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <NDBBIOPEKLHMHCDKLPLPMEKPCMAA.jeffd@evcom.net>
Date: Mon, 1 May 2000 09:35:57 -0400
Reply-To: Jeff Dafoe <jeffd@EVCOM.NET>
From: Jeff Dafoe <jeffd@EVCOM.NET>
X-To: Chris Knipe <cgknipe@MWEB.CO.ZA>, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <003101bfb1d1$f91fb830$0100a8c0@internal.sunnyline.co.za>
> The Microsoft ODBC Database connectivity allows for a potential
> flaw in the
> connecting and disconnecting from databases (More related to Microsoft
> ACCESS databses than any other). Connecting to a second database without
> disconnecting the first could possibly render the service useless and will
> end up in the Administrator to reboot the server to regain control of such
> services.
I have encountered this before and really considered it a design flaw more
than a bug. The issue doesn't actually lock the inetinfo process, instead
ASP pages that utilize a ODBC connection will not execute. HTML requests
serviced by the same process will function. When this issue arises, open up
the performance monitor and look at the Active Server Page "Requests Queued"
value. This value, which is normally at zero, will be at a very high value.
What has essentially happened is that no more ODBC connections are available
and each execution of the problematic ASP code is queued, waiting for the
ODBC resource to become available. This resource will never become
available because it has not been closed. This is caused by failure to
close the connection in the ASP code. You run out of ODBC connections.
Jeff Dafoe
System Administrator
Evolution Communications, Inc.
