Bugtraq mailing list archives

Previous By Date Next
Previous By Thread Next

Re: Windows NT/95/98/Possible Others Denial of Service Attack. Mi crosoft ODBC Database connectivity flaw.

From: ddoc () MIA CZ (Daniel Docekal)
Date: Mon, 1 May 2000 10:57:58 +0200

It is WELL known that Access may NOT be used for production WWW servers as
it is not thread safe and cause various problems, including crashes of
services. Especially when under heavy load or running for long period of
time.

For this reason, this is not really Denial of Service, it is just
shortcoming of particular file-based database engine - the same is btw true
about FoxPro databases.

Daniel


-----Original Message-----
From: Chris Knipe [mailto:cgknipe () MWEB CO ZA]
Sent: Saturday, April 29, 2000 10:36 AM
To: BUGTRAQ () SECURITYFOCUS COM
Subject: Windows NT/95/98/Possible Others Denial of Service
Attack. Microsoft ODBC Database connectivity flaw.


Goodday Fellow Bugtraqers.

Today I come to you with a possible (And what seems to me to
be quite easy
to reproduce) flaw in Microsoft's ODBC Database connectivity
sources.  The
attack is HTML based and should proove quite interesting on
web sites that
uses DSN or DBQ methods of connecting to SQL or (The easiest
to attack)
Microsoft ACCESS Databases.

Summary:
=======
A method is available to "lock up" the entire IIS Server,
which will render
any installed applications under the Windows NT Option Pack
useless.  All
web based applications (IIS Admin Services, Web Publishing
Services, and
possible others) will lock up and stop responding to any web
requests, or
any control requests to stop or start such services.  The
vulnerability
could potentially allow a malicious web site developer to
perform actions
under the ASP Programming language to render the web server
useless to local
control, or content requests.

Status:
=====
Microsoft has been informed about the suspecious behaviour of
ACCESS and
ODBC Database Connectivity.

Issue:
====
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.

How more wildly database connections are made, how better the
chances of
hitting the hole and attacking the system.  The risk posed by this
vulnerability is significantly restricted by the fact that
the affected
database connection may be configured to "run in a seperate
memory block" or
have special settings on the database that "might" secure
this vulnerability
from accuring.  HOWEVER, in the most common installation and
programming
methods, it is quite possible to still have an effective system.

Sample Code:
==========
Consider the following scenario:

ODBC Connection Source Name:  miscdb
ODBC DataBase Type:  MS Access
ODBC Path:  d:\data\misc.mdb


ASP Programming:
<%
   set connVB = server.createobject("ADODB.Connection")
   connVB.open "DRIVER={Microsoft Access Driver (*.mdb)}; DSN=miscdb"
%>

<html>
<body>
...lots of html removed...

<!-- We Connect to DB1 -->
<%
                set connGlobal =
server.createobject("ADODB.Connection")
                connGlobal.Open "DSN=miscdb;User=sa"

                mSQL = "arb SQL Statement"

                set rsGlobal = connGlobal.execute(mSQL)

                While not rsGlobal.eof

                Response.Write rsGlobal("resultfrommiscdb")

                rsGlobal.movenext

                wend

                'rsGlobal.close
                'set rsGlobal = nothing

                'connGlobal.close
                'set connGlobal = nothing
' Note we do NOT close the connection
%>

<!-- Call the same database by means of DBQ direct file access -->
<%
                set connGlobal =
server.createobject("ADODB.Connection")
                connGlobal.Open "DRIVER={Microsoft Access
Driver (*.mdb)};
DBQ=d:\data\misc.mdb"

                mSQL = "arb SQL Statement"

                set rsGlobal = connGlobal.execute(mSQL)

                While not rsGlobal.eof

                Response.Write rsGlobal("resultfrommiscdb")

                rsGlobal.movenext

                wend

                rsGlobal.close
                set rsGlobal = nothing

                connGlobal.close
                set connGlobal = nothing
' Note we DO close the connection
%>

In some cases, this will stall the IIS process, and CPU usage
will jump to
100% utilization by the inetinfo.exe process.  To current
date, the only
solution to my knowledge is to restart the computer.


Solution:
======
None that I am aware of.  Newest Service Packs, newest ODBC
data sources,
they all seem to be affected.


Special Notes:
==========
The attack is very "unpredictable".  By unpredictable, I mean
that the exact
same code may work perfectly for 15 days, then all of a
sudden, cpu usagage
will jump to 100% and the inetinfo process will be locked.  In recent
attempts to reproduce this attack to try and clarify as to
what exactly is
causing this, I have connected up to 15 different SQL and
Access Databases,
all with success.  The one time I reboot the NT server, and
attempt to load
the pages up again, the process will lock.


Personal Viewpoints:
===============
Microsoft's only means of connecting to databases is through
ODBC or direct
file access (DSN and DBQ).  Whether you use ODBC or direct
file access, the
process used is unstable.  Certainly with this unstability,
having a ODBC
enabled web site will sees to function properly if it crashes
or locks up
with only one user accessing the web site.  What happens when
1,000,000
people access the site on a daily basis?

I would recommend that databases be moved over from Microsoft
ACCESS to
Microsoft's SQL Server, or a similar SQL server on Linux with
support for
ODBC or other forms of connectivity.


Affected Version:
============
ODBC Version: 3.510.3711.0
ODBC Access Driver Version: 3.51.1029.00
OS Version:  Windows NT 4.0 Service Pack 5, IIS 4.0 (i386)
Microsoft Office 97 Professional (MSO97.dll: 8.0.0.3507)


The complete ASP page from the site with affective
inetinfo.exe lockage is
attached.  The single DSN connection revlected in the
relavent ASP source is
a SQL Server, and hardly ever gives problems.  The second database, is
directly connecting (DBQ) to a Microsoft ACCESS database.  NTFS File
permissions is suffiecent for the test reasons, and no
security related
problems are noted in the tests.  The attached ASP file locks
up 90% of the
time.

SQL Table Properties:
Table Name:  History_Today
Table Layout:
   Name:             Type:           Size:
his_month         int               4
his_day             int               4
his_year            int               4
his_desc           varchar      200
his_type           varchar      1

Table Name:  Holidays
Table Layout:
  Name:          Type:            Size:
Month           int                 4
Day                int                 4
Holiday         int                 200

The MS Access database can be made available on request.  Due to the
complexity of the database (Queries, Reports, Forms, Tables)
I am not going
to layout the database in this email.


Kind Regards
Chris Knipe
Previous By Date Next
Previous By Thread Next

Current thread: