Hello
I have run some testing. Seems to me that this error has been repaired in
MSJET40, but exists in MSJET35. Effectively, if Jet 4 is installed (and it's
used by ODBC) ther's no problem with .IDC files. If one does not have Jet 4
and is using .IDC to open Jet databases (I have not verified this) I belive
this is dangerous situation, described by Matthew Astley.
Because MS Access 97 is using Jet 3.5 (even if Jet 4 is installed), the
problem still can be seen there.
If instead of .IDC (which is considered obsolete) one is using .ASP + ADODB,
and ADODB provider used is "Microsoft.Jet.OLEDB.3.51" (i.e. older than
"4.0") then problem still exists.
It's worthy to notice that SQL implementation used in both Jet 4 and Jet 3.5
is little different. Thus applications (in some situations) cannot be simple
ported from one to another. One thing I found is different handling of
single- and double-qoute character. MS still have not documented differences
(or I had no luck to find it). AFAIK MS Jet 4 comes with Microsoft Data
Access 2.1 (MSDAC21).
Details:
System: WinNT Wrkst 4 US, SP5 , IE5 , IIS 4 (Option Pack), ODBC MS Access
Driver 4.00.3513.00, other (cursor library, administrator etc.) ODBC files
3.510.3711.0
Database: Access 97, Jet 3.51.2026.0 (I have also Jet 4.00.2115.25
installed, but Access 97 uses older version)
Table "guests" as described in Web SQL.
Query "SecurityTest" as bellow:
SELECT FirstName, LastName FROM Guests WHERE LastName =
'|Shell("notepad.exe",1)|';
What happens:
- If I open the query under MS Access, it opens Notepad app and shows the
(empty) resultset. So far mentioned SQL "feature" works.
- If I use MSQRY32.EXE to open the database (), nothing more happen than
showing the resultset (empty one). The same if I run SQRY32 from within MS
Excel ("Get Externala Data")
- I created TEST.IDC file as bellow (and TEST.HTX, of course):
Datasource: Web SQL
Username: sa
Template: details.htx
SQLStatement:
+SELECT FirstName, LastName
+FROM SecurityTest
and opened it through HTTP. The only result is an empty resultset. I checked
list of processes (using TLIST.EXE) and notepad was not run.
- I created TEST2.IDC file as bellow:
Datasource: Web SQL
Username: sa
Template: details.htx
SQLStatement:
+SELECT FirstName, LastName
+FROM Guests
+WHERE LastName <> '|Shell("notepad.exe",1)|'
the same. Notepad did not run.
- I created very simple .ASP
<HTML>
<HEAD>
<%
Param = Request.QueryString("Param")
Data = Request.QueryString("Data")
%>
</HEAD>
<BODY>
<%
Set Conn1 = CreateObject("ADODB.Connection")
'strConn = "Provider=Microsoft.Jet.OLEDB.3.51;Data
Source=c:\temp\test.mdb;Mode=Read"
strConn = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\temp\test.mdb;Mode=Read"
strSQL = "SELECT FirstName , LastName FROM SecurityTest"
Conn1.Open strConn
Set RSet1 = Conn1.Execute(strSQL)
RSet1.Close
Conn1.Close
%>
</BODY>
</HTML>
Notice that there are 2 connection strings, one is used and the other
commented out. Upper connection string ("Provider=Microsoft.Jet.OLEDB.3.51")
is UNSAFE. When I opened .ASP it started NOTEPAD.EXE in the context of WWW
server. If WWW client can type-in any literal into HTML form, pass it to
.ASP application (for exaple to be used in "WHERE" clause) and it remains
non-parsed, then he/she will be able to run ANY code in the context of
LocalSystem. If such a WWW server is also domain controller ... well, I'm
bit scared to think about. Lower connection string
("Provider=Microsoft.Jet.OLEDB.4.0") seems to be safe.
I hope somebody can verify my tests. Most important point is that while .IDC
files are using current ODBC it strongly depends on configuration of the
system. If Jet 4 is installed and is used by ODBC, we are safe. The same
applies to .ASP + ODBC. On the other side is .ASP + ADODB, where Jet engine
can be explicitly selected. If Jet older than 4 is used then we have
dangerous situation. Fortunately in .ASP we can easily parse strings passed
from WWW client (like Vittal Aithal did in JavaScript, but function will be
run on the server side).
Regards.
Bronek Kozicki
--------------------------------------------------
ICQ UID: 25404796 PGP KeyID: 0x4A30FA9A
07EE 10E6 978C 6B33 5208 094E BD61 9067 4A30 FA9A
: -----Original Message-----
: From: Bugtraq List [mailto:BUGTRAQat_private]
: Sent: Tuesday, May 25, 1999 9:00 PM
: To: BUGTRAQat_private
: Subject: Advisory: NT ODBC Remote Compromise
:
:
: --[ Advisory: NT ODBC Remote Compromise
:
: --[ By Matthew Astley [RCPS] http://www.fruitcake.demon.co.uk
: --[ & Rain Forest Puppy [WireTrip] rfpat_private
:
: --[ Brief Summary
:
: MS Jet database engine (which runs Access databases) allows an individual
: to embed VBA in string expressions, which may allow the individual to run
: commandline NT commands. This, combined with the flaw of IIS running ODBC
: commands as system_local allow a remote attacker to have full control of
: the system. Other webservers may be affected. Many MS Jet engines are
: affected, but may not lead to elevated priviledges.
Here's something that does not work for me. ODBC is not using Jet "feature"
run embed VBA expression. It seems to use different database engine.
: --[ Background
:
: ODBC allows a program flexible access to one or more relational databases
: using SQL. If a client fails to quote correctly the meta characters in a
: piece of data used in an SQL query, an attacker may be able to interfere
: with the tables in the database (see MS SQL appension 'feature' in Phrack
: 54, article 8).
That's true, but not connected to the subject. Attacker seems not to use
Jet, while "feature" exists just there. At least on my system.
: However, the Microsoft "Jet" database engine (aka MS Access) provides some
: extensions to SQL which allow the execution of VBA (Visual Basic for
: Applications). This makes holes in meta character quoting code much more
: interesting and dangerous.
That's true.
[cut]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:47:14 PDT