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 <david@ngssoftware.com> 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 (david@ngssoftware.com) > 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
