This month Microsoft released an update for Windows to address three vulnerabilities in the SMB Server component. Two of the vulnerabilities are remote denial-of-service (DoS) attacks, while one (CVE-2010-2550) has the potential for remote code execution (RCE). This blog post provides more details on the exploitability of CVE-2010-2550, and outlines why the risk of reliable RCE is low.

As mentioned in the bulletin, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows 2008 R2 systems are not vulnerable to unauthenticated attackers by default. (Only if password-based sharing was disabled would one of these systems be vulnerable.) In the most common scenarios, and on these versions of Windows by default, the attacker would therefore need to be authenticated.

Vulnerability details

In order to exploit CVE-2010-2550, the attacker must have read permission on a SMB share on the target system. This implies that the attacker is authenticated, or that the target allows anonymous access to network shares (this is a default configuration only on Windows XP with later platforms requiring authentication by default)

By sending a specially crafted SMB request to the target, an attacker with read access could cause a kernel pool block to be overrun. This is due to an attacker-provided length being used as the size value in an allocation call. If an attacker specifies a small size value, the system will later write data to this buffer, which will corrupt the adjacent pool block(s). The data used in the overwrite comes from the disk or file system on the target machine.

Exploitability details

Assuming the attacker is able to trigger the vulnerability, there are some factors that make reliable exploitation difficult:

  • Windows 7 and Windows 2008 R2 systems have mitigations in the kernel to prevent pool overrun exploitation which will make the remote attack even more difficult (as discussed here http://blogs.technet.com/b/srd/archive/2009/05/26/safe-unlinking-in-the-kernel-pool.aspx)
  • The data that will be written to the kernel pool block is not attacker-controlled and instead comes from the disk or file system on the target machine. Finding data that contains useful values in the right location for an attacker’s purposes will be difficult in a remote attack scenario. A local attacker has more control and might be able to allocate memory on the system in a way that allows corrupted pointers in the pool to be leveraged for local elevation of privilege (EOP).
  • Failed exploitation attempts will result in a system crash (bugcheck), so the attacker will only get one attempt (per boot) to exploit the vulnerability.

For these reasons we think it will be difficult to build reliable RCE exploits for this vulnerability, and remote DoS attacks are much more likely. A local EOP exploit is possible. The risk of a worm spreading using this vulnerability is very low.

Thanks to the following people for their hard work on this issue:

  • Bruce Dang, MSRC Engineering
  • Dustin Childs, MSRC
  • Kowshik Jaganathan, Hassan Sultan, Vivek Jain , Felix Coifman, Geoffrey Antos , Purujit Saha, Faraz Qadri, Shiraj Kashani and Anindya Das from the Windows Sustained Engineering
  • Shivani Sharma, Ather Haleem, Gary Shang, David Kruse and Greg Kramer from the Windows Core SMB
  • Julien Vanegue, MSEC Pentest

Thanks to Fermin J. Serna and Andrew Roths for contributing to this blog post.

- Mark Wodrich, MSRC Engineering