Skip to main content

MS08-076: Windows Media Components: Part 1 of 2

Today we released MS08-076, which addresses two flaws in the Windows Media components: Windows Media Player, Windows Media Format Runtime, and Windows Media Services. Viewed separately, the issues are not that severe and the aggregate severity rating is Important at most. However, if the two issues are combined the impact can be quite severe, with the potential for Remote Code Execution. Read on to understand how these issues can be combined by an attacker and how they are related to the SMB Reflection bulletin we released last month. The information should be useful to help prioritize the deployment of this update.

The SPN Vulnerability

The first vulnerability, CVE-2008-3009, relates to the Windows Media components’ use of the NTLM authentication protocol, specifically regarding SPNs (Server Principal Names). Media players which use the Windows Media components (such as Windows Media Player) could be prompted by the server to authenticate before accessing the media. In response, the client will send the current user’s credentials, possibly using NTLM if this is the protocol that is negotiated by the client and server.

If the server is malicious it can use the NTLM credentials it receives to perform a reflection attack against the client. This type of attack is discussed in more detail in last month’s bulletin MS08-068 and the related SVRD blog post. That bulletin updated SMB clients to protect them from attacks. This bulletin does the same thing, but for Windows Media components clients. In order to be protected against NTLM reflection attacks, a client must pass a valid SPN into the InitializeSecurityContext API while performing an authentication. InitializeSecurityContext for NTLM is covered on MSDN here, and SPNs are covered here. While the SPN documentation focuses on Kerberos authentication, NTLM also supports the use of SPNs.

In this case, since the Windows Media Components passed in an incomplete SPN, NTLM reflection protections would not be enabled for this authentication request. An attacker could try to exploit this by targeting SMB on the client machine using the reflected credentials.

It is important to note that the Windows Media components are zone-aware, in the same way Internet Explorer is. This means that when media is retrieved from a server, the code determines whether the server is on the local intranet (and hence in the Intranet zone), or else in the Internet zone. (There are also the Trusted Sites and Restricted Sites zones which can be configured by the user.)

Servers in the Internet zone are inherently un-trusted, and Windows Media components will not send NTLM credentials to these servers without prompting the user. Hence, for the SPN vulnerability to be exploited, the attacker must either be on the local intranet (e.g. the same subnet as the victim), or the attacker must somehow trick the system into performing NTLM authentication with a machine on the Internet. That’s where the second vulnerability comes into play…

The ISATAP Vulnerability

First off, you might be wondering what ISATAP is. As the bulletin says, ISATAP is a technology to enable IPv6 traffic to be sent within an IPv4 network – it’s one of the “transition technologies” that can be used as the network is migrated from an older IPv4-only network to an IPv6 network. Since ISATAP provides IPv6 connectivity, only systems with IPv6 enabled (such as Windows Vista) are affected by this issue.

The ISATAP vulnerability, CVE-2008-3010, is due to the way Windows Media components treat ISATAP addresses when making the zone determination. Instead of treating an ISATAP server address as an Internet zone address, it is treated as classified as being in the Intranet zone. As explained above, this leads to an information disclosure vulnerability, since NTLM authentication data could be sent to un-trusted destinations on the Internet.

It should be noted that a properly-configured edge firewall will block the IP protocol used by ISATAP, and so an attacker on the Internet will not be able to have victims contact their malicious server. (See the “IPv6 Security Considerations and Recommendations” paper on Technet.)

Combined severity

Given the above information, it should be clear how combining these two vulnerabilities could lead to an attacker being able to gain access to the victim’s machine. However, when determining bulletin severity we do not consider combined attacks for different vulnerabilities, hence the overall severity of Important for this bulletin.

Possible attack scenarios

Due to the way ISATAP is blocked on most routers and edge firewalls, an attacker would need to be on the same network as the victim (not on the Internet).

Typically an attack that leverages these two vulnerabilities would be combined with an SMB reflection attack (creating something known as a “cross-protocol reflection attack”). The exact impact depends on the operating system targeted and the permissions of the user account that the Windows Media components client is running under. It is important to note that even with the update for MS08-068 applied, systems are vulnerable to attack under the above scenario, since SMB is not the one generating the NTLM authentication request.

In part two of this blog post, we will discuss additional workaround steps that can be applied on client machines, and also expand on the ISATAP vulnerability applies to Windows Media Servers.

Mark Wodrich, SVRD Blogger

*Postings are provided “AS IS” with no warranties, and confers no rights.*

Related Posts