This month we are releasing update MS09-050 to address the SMBv2 RCE vulnerability (CVE-2009-3103). Due to the fact that public exploit code exists for this vulnerability, we felt it would be good to summarize the exploit landscape at the time of release, so customers can use this information to prioritize the deployment of the update.
Initial disclosure
The initial public disclosure of this vulnerability on Sept. 7, 2009 included proof-of-concept code which would lead to a denial of service (DoS) due to the targeted system rebooting. Microsoft immediately began working to understand the vulnerability and produce a high-quality update. From an early stage we realized this vulnerability posed a Remote Code Execution (RCE) threat, and we released a security advisory to notify customers of the risk and suggested a work-around (disabling SMB2) which would protect systems from attack until the official update was ready.
Exploit timeline
One week later on Sept. 14, a security company released proof-of-concept code for a local exploit. On Sept. 17, the same company released proof-of-concept code for a remote exploit. The security company provided the local and remote exploit only to a subset of their customers who subscribe to an “early update” package. I will refer to this exploit as the “commercial exploit”.
Microsoft analyzed the commercial exploit code to determine the risk to customers and gauge how likely it would be for other security researchers to achieve a working exploit. Based on this analysis, we determined that the exploit provided was reliable, and that there was low risk of active exploitation (due to the limited release of the exploit). We continued to test the update and work towards releasing it as soon as it reached an acceptable quality level, barring changes in the exploit landscape.
At this time we were also aware that other researchers in the security community were working towards a remote exploit, and that they were planning to include it in freely-available tools. On Sept. 28, the first public exploit code was released. Again, we analyzed the exploit to determine the risk to our customers. We determined that the exploit was not reliable on all systems and would only work on a limited number of configurations reliably.
On Oct. 4, a blog post outlined changes to the public exploit code that would improve its reliability, but did not detail the exact code changes required. The post provided enough technical detail that we knew it would not take long for the public exploit to be updated, and a few days later we saw updated public exploit code posted online. At about the same time, the commercial exploit was also released to the security company’s wider set of customers.
Microsoft analyzed the newest public exploit code and determined that it was not yet reliable. (In fact it seemed to be totally unreliable in our testing.) We expected the gap between the commercial exploit and the public exploit to quickly close as more people gained access to the commercial exploit, and more people worked with the public exploit.
Current situation
There is currently no functioning RCE exploit for 64-bit systems running 64-bit Windows. The current commercial and public exploit tools only work against 32-bit Windows systems, and developing a reliable exploit for 64-bit Windows should be very difficult. However, 64-bit SMB servers are still at risk of DoS attacks using this vulnerability.
A reliable remote exploit is not widely available for 32-bit systems, and the risk of widespread attacks against systems is currently low. However, that could change at any moment. We recommend people deploy this update to their 32-bit SMB servers rapidly, as we anticipate a reliable exploit will be released within the first 30 days after this update is released. (More realistically the exploit will be released in the first week). Updating 64-bit SMB servers can be prioritized primarily based on the risk of DoS attacks.
Credit
I would like to thank the Windows SMB and Windows Serviceability teams for their hard work on this update, Jonathan Ness and Bruce Dang for the SMBv2 workaround and “Fix-It” automation, and Brian Cavenah and Ken Johnson for technical advice and help analyzing the exploits.
- Mark Wodrich