Re: Another Sql Server 7 Buffer Overflow

From: Russ (Russ.Cooper@RC.ON.CA)
Date: 03/07/02 

Date:         Thu, 7 Mar 2002 10:39:02 -0500
From: Russ <Russ.Cooper@RC.ON.CA>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

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

  • Re: Another Sql Server 7 Buffer Overflow
    ... that this buffer overflow does indeed still exist and that what Cesar ... SQL Server is terminating this process. ... MSKB q280380 they provide a list of the extended procedures that used ...
    (NT-Bugtraq)
  • RE: DTS is blocked by XP
    ... When usung XP (extended procedures), the login you use to access the SQL ... server instance will require permissions within to run extended procedures. ... Look for setting permissiones in SQL. ...
    (microsoft.public.sqlserver.dts)
  • Re: Is there any REGEXP library for TSQL?
    ... >> But performance would be awful and the code would be messy. ... > I've never written any extended procedures, ... I'm guessing the main reason is that in SQL 2000, ... SQL 2005 CLR code executes within the same memory space ...
    (comp.databases.ms-sqlserver)