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.
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.
Assuming the attacker is able to trigger the vulnerability, there are some factors that make reliable exploitation difficult:
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:
Thanks to Fermin J. Serna and Andrew Roths for contributing to this blog post.
- Mark Wodrich, MSRC Engineering