MS09-063 addresses a critical vulnerability (CVE-2009-2512) in the Web Services on Devices (WSD) API. Web Services on Devices allows a computer to discover and access a remote device and its associated services across a network. It supports device discovery, description, control, and eventing.
The WSD API functionality is implemented in the WSDApi.dll module in Windows, and is used by several services and applications. The API is also documented on MSDN for 3rd party developers to use. Therefore, a comprehensive list of services and application that are vulnerable to this issue is hard to define, but here are some examples:
· Print Spooler service
· Function Discovery Resource Publication service
· Function Discovery Provider Host service
· Windows Network Projector
There are mitigating factors that limit the scenarios where the vulnerability can be exploited. We will describe the vulnerability and mitigating factors in more detail in this blog post.
What is the issue?
A long header value within a WSD message can lead to stack corruption within the process hosting WSDApi.dll. This can cause the service or application to crash, or could lead to Remote Code Execution. To be clear, the vulnerability is in the Windows module used to interact with devices that support Web Services on Devices, and does not affect the devices themselves.
What platforms are affected?
Windows Vista and Windows Server 2008 are affected. WSDAPI was introduced in Windows Vista and hence earlier versions of Windows are not vulnerable.
Only systems with the WSD TCP ports active and listening are vulnerable to the most likely attack vector. Whether a system has WSD ports active and listening depends on the system configuration and applications that are installed.
What are the attack vectors?
By default, WSDAPI will listen on TCP ports 5357 and 5358. The Windows Firewall will allow messages in to these ports if the interface firewall profile is anything other than Public. This means under non-Public profiles (e.g. Private or Domain) the vulnerability can be reached by remote, unauthenticated users.
For an attacker to be able to trigger the vulnerability on a target, they need to know the WSD Address value for the target, which is a UUID (Universally Unique Identifier). This value is automatically sent in broadcast UDP messages to port 3702 (WS-Discovery) in an effort to discover devices that support WSD. Being broadcast UDP the message will only be visible to attackers on the same subnet. Attackers on other subnets, or on the Internet, will not be able to launch attacks against distant targets using this approach.
A system could also be exploited by a malicious device which responds to a client computer using WSDAPI. It is possible for the user to manually enter the URL of a device to connect to, in which case the device could respond with a malformed message and trigger the vulnerability. This requires user-interaction and social engineering, however.
Mitigating factors
As explained above, the most common exploit scenario requires that the attacker is on the same subnet as the target system in order for the target’s WSD Address to be discovered.
The default Windows Firewall rules limit inbound WSD messages to sources on the local subnet for Private and Domain profiles. The Public firewall profile blocks WSD messages completely.
If WSD functionality is not needed, the security bulletin provides information on using the Windows Firewall to block the inbound and outbound ports used to trigger this vulnerability.
I’d like to thank Rob Hain and Dan Driscoll from the WSD team, and Kevin Brown from MSRC Engineering for their work on this issue.
- Mark Wodrich, MSRC Engineering
