[14738] in bugtraq
Re: Windows NT/95/98/Possible Others Denial of Service Attack. Mi
daemon@ATHENA.MIT.EDU (Daniel Docekal)
Tue May 2 15:16:35 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <080D5336D882D211B56B0060080F2CD6623F35@beta.mia.cz>
Date: Mon, 1 May 2000 10:57:58 +0200
Reply-To: Daniel Docekal <ddoc@MIA.CZ>
From: Daniel Docekal <ddoc@MIA.CZ>
X-To: Chris Knipe <cgknipe@MWEB.CO.ZA>
To: BUGTRAQ@SECURITYFOCUS.COM
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
>
>
>
>
