SQL Server stored procedure vulnerability heap buffer overrun in SQL Server, MSDE, and SQL Express

You may have seen the sp_replwriterovarbin - New SQL Server Injection-Based Attack Found vulerability about the new public reports of a vulnerability that could allow remote code execution on systems with supported editions of SQL Server 2000, 2005, 2005 Express Edition, 2000 Desktop Engine (MSDE 2000), and Windows Internal Database (WYukon).
The only exceptional SQL Server systems are SQL Server 7.0 Service Pack 4, SQL Server 2005 Service Pack 3, and SQL Server 2008. MSA961040 highlights that this vulnerability is not exposed anonymously. An attacker would need to either authenticate to exploit the vulnerability or take advantage of a SQL injection vulnerability in a Web application that is able to authenticate and by default, MSDE 2000 and SQL Server 2005 Express do not allow remote connections. An authenticated attacker would need to initiate the attack locally to exploit the vulnerability, so it is always better to tighten the permissions on these databases. Review more information from this CVE reference link and the general recommendation from Microsoft Security Advisory that all customers should apply the most recent security updates released by Microsoft to help ensure that their systems are protected from attempted exploitation.
As usual the systems that are enabled Automatic Updates will get this windows update, if not you must refer to Microsoft Security Central site for more information. Here is the workaround referred by MSA961040 link :
chkHide('s'+sID);

Deny permissions on the sp_replwritetovarbin extended stored procedure

Use one of the following procedures:
•To deny access to the stored procedure, connect to SQL Server as a sysadmin using osql.exe or sqlcmd.exe or through SQL Server Management Studio and execute the following T-SQL script:
use masterdeny execute on sp_replwritetovarbin to public
•To deny access to the stored procedure using SQL Server administration:
•For SQL Server 2000:
1.Connect to SQL Server using Enterprise Manager as a sysadmin
2.From the SQL Server Enterprise Manager window, select the desired server
3.Expand the databases
4.Expand Master
5.Click Extended Stored Procedures. A list of stored procedures appears.
6.From the list of stored procedures, right-click sp_replwritetovarbin and select Properties
7.In the Properties window, click Permissions
8.Under Users/Database Roles/Public, find Public, then click the box in the EXEC column. The box turns into a red X.
9.Click OK twice
•For SQL Server 2005:
1.Connect to SQL Server using SQL Server Management Studio as a sysadmin
2.From the Object Explorer window, select the desired server
3.Expand the databases and the system databases
4.Expand Master
5.Expand Programmability
6.Click Extended Stored Procedures. A list of stored procedures appears.
7.From the list of stored procedures, right-click sp_replwritetovarbin and select Properties
8.In the Properties window, click Permissions
9.Click Deny execution beside the desired user IDs and click OK
Impact of Workaround: Disabling the sp_replwritetovarbin extended stored procedure prevents updates to subscription tables by all users. The impact of this workaround only affects customers that use transactional replication with updatable subscriptions. Customers using transactional replication with read-only subscriptions, bi-directional transactional replication, or peer-to-peer transactional replication are not impacted. For more information on transactional replication with updatable subscriptions, see MSDN.
How to undo the workaround

•

Connect to SQL Server as a sysadmin using osql.exe or sqlcmd.exe or through SQL Server Management Studio and execute the following T-SQL script:
use mastergrant execute on sp_replwritetovarbin to public

•

To restore access to the stored procedure via SQL Server administration:
•For SQL Server 2000:
1.Connect to SQL Server using Enterprise Manager as a sysadmin
2.From the SQL Server Enterprise Manager window, select the desired server
3.Expand the databases
4.Expand Master
5.Click Extended Stored Procedures. A list of stored procedures appears.
6.From the list of stored procedures, right-click sp_replwritetovarbin and select Properties
7.In the Properties window, click Permissions
8.Under Users/Database Roles/Public, find Public, then click the box in the EXEC column. The box turns into a green checkmark.
9.Click OK twice

•

For SQL Server 2005:

1.

Connect to SQL Server using SQL Server Management Studio as a sysadmin

2.

From the Object Explorer window, select the desired server

3.

Expand the databases and the system databases

4.

Expand Master

5.

Expand Programmability

6.

Click Extended Stored Procedures. A list of stored procedures appears.

7.

From the list of stored procedures, right-click sp_replwritetovarbin and select Properties

8.

In the Properties window, click Permissions

9.

Click Grant execution beside the desired user IDs and click OK

As referred above these steps will reduce the problem by blocking the known attack vectors, as I have also successfully applied on the affected SQL Server systems at my end. For more information refer to this SQL 2005 Security best practices link and list of webcasts on security best practices:

• Authentication and Authorization
  • Encryption
    • Execution Context
      • SQL Server Security Best Practices