Bugtraq mailing list archives
Windows NT/95/98/Possible Others Denial of Service Attack. Microsoft ODBC Database connectivity flaw.
From: cgknipe () MWEB CO ZA (Chris Knipe)
Date: Sat, 29 Apr 2000 10:35:30 +0200
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
<HR NOSHADE>
<UL>
<LI>text/asp attachment: default.asp
</UL>
Current thread:
- Windows NT/95/98/Possible Others Denial of Service Attack. Microsoft ODBC Database connectivity flaw. Chris Knipe (Apr 29)