Re: Arbitrary Command Execution on Distributor SQL Server 2000 machines (#NISR22002002A)

From: Cesar (cesarc56at_private)
Date: Thu Aug 22 2002 - 15:54:29 PDT

  • Next message: Rich Lafferty: "Re: [luca.ercoliat_private: DoS against mysqld]"

    This was alredy published by me one month ago:
    
    http://online.securityfocus.com/archive/82/284385
    
    and the patch that fix it is:
    
    http://www.microsoft.com/technet/security/bulletin/MS02-038.asp
    
    All stored procedures vulnerables appears in
    SecurityHotfix.sql file that is in the above mentioned
    patch.
    
    Cesar.
    
    --- David Litchfield <davidat_private> wrote:
    > NGSSoftware Insight Security Research Advisory
    > 
    > Name: Arbitrary Command Execution on SQL Server 2000
    > Systems: Microsoft SQL Server 2000 SP 2
    > Severity: High Risk for Distributor servers
    > Category: Arbitrary Command Execution
    > Vendor URL: http://www.microsoft.com/
    > Author: David Litchfield (davidat_private)
    > Advisory URL:
    >
    http://www.ngssoftware.com/advisories/mssql-sp_MScopyscriptfile.txt
    > Date: 22nd August 2002
    > Advisory number: #NISR22002002A
    > 
    > Description
    > ***********
    > A stored procedure on an SQL Server is a series of
    > SQL queries that can be
    > written once and run many times. One of the internal
    > Microsoft stored
    > procedures on SQL Server 2000 that the 'public' role
    > has permissions to
    > execute fails to validate user input before passing
    > it to xp_cmdshell. The
    > xp_cmdshell extended stored procedure runs an
    > operating system command and
    > it is possible for a low privileged and malicious
    > user to insert and run
    > their own arbitrary commands.
    > 
    > Details
    > *******
    > If a Microsoft SQL Server is configured as a
    > distributor, so it can
    > replicate data between servers, a low privileged and
    > malicious user may
    > execute the 'sp_MScopyscript' stored procedure and
    > insert arbitrary commands
    > which will be run in the security context of the SQL
    > Server account. If the
    > SQL Server is running as LocalSytem then this attack
    > will invariably fail.
    > The reasons behind this is due to the fact that,
    > before the user supplied
    > commands are executed, the server must create a
    > directory over a network
    > share on the distributor. As the Local System
    > account has no pivileges on
    > the network, the stored procedure will fail at this
    > point. If the server is
    > running in the context of a domain user then the
    > "make directory" command
    > should work provided replication has been setup
    > properly. Once this command
    > has executed the stored procedure then inserts the
    > user supplied @scriptfile
    > parameter into a command: from the text of
    > sp_MScopyscript
    > 
    > select @cmd = N'copy "' + @scriptfile + N'" "' +
    > @directory + N'"'
    > exec @retcode = master..xp_cmdshell @cmd, NO_OUTPUT
    > 
    > By supplying a malformed @scriptfile parameter an
    > attacker can run arbitrary
    > commands:
    > 
    > use master
    > declare @cmd nvarchar(4000)
    > exec sp_MScopyscriptfile N'c:\autoexec.bat"
    > c:\cp.txt&echo hello >
    > c:\ccc.bbb & echo "hello',@cmd OUTPUT
    > print @cmd
    > 
    > 
    > The above query will copy the autoexec.bat file to
    > cp.txt but also echo
    > hello to a file called ccc.bbb.
    > 
    > If the server is running with Administrator
    > privileges an attacker will be
    > able to insert pretty much any command. For example
    > the could create a
    > Windows NT user and add it to the administrators
    > group.
    > 
    > 
    > Fix Information
    > ***************
    > The last cumulative patch provided by Microsoft (
    > see
    >
    http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
    > bulletin/MS02-043.asp ) appears to address this
    > problem. If you have not
    > applied this patch yet NGSSoftware recommend you do
    > so as soon as possible.
    > For those who have to wait to apply the patch due to
    > testing periods etc
    > NGSSoftware recommend that you at least prevent the
    > 'public' role from
    > running this stored procedure. You can do this by
    > running the following
    > query from Query Analyzer:
    > 
    > 
    > REVOKE EXECUTE ON [dbo].[sp_MScopyscriptfile] FROM
    > [public] CASCADE
    > 
    > 
    > 
    > 
    > 
    > 
    > 
    > 
    > 
    
    
    __________________________________________________
    Do You Yahoo!?
    HotJobs - Search Thousands of New Jobs
    http://www.hotjobs.com
    



    This archive was generated by hypermail 2b30 : Fri Aug 23 2002 - 11:52:36 PDT