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