Microsoft Security Bulletin MS02-032

Why was this bulletin updated?

On June 26, 2002, Microsoft released the original version of this bulletin, which described the patch it provided as being cumulative. We subsequently discovered that a file had been inadvertently omitted from the patch. While the omission had no effect on the effectiveness of the patch against the new vulnerabilities discussed below, it did mean that the patch was not cumulative. Specifically, the original patch did not include all of the fixes discussed in Microsoft Security Bulletin MS01-056. We have repackaged the patch to include the file and are re-releasing it to ensure that it truly is cumulative.

Do I need to apply the new version of the patch?

If you applied the patch delivered in Microsoft Security Bulletin MS01-056 and the one that was distributed with the original version of this bulletin, you're fully protected against all known vulnerabilities in Windows Media Player and don't need to take any action. Otherwise, we recommend that you apply the new version of the patch provided below.

I'm not sure whether I applied the patch from Security Bulletin MS01-056. What should I do?

If you're not sure whether you applied the patch from Security Bulletin MS01-056, the safest course of action is to apply the new version of the patch provided below.

Would installing the original version of the patch make my system vulnerable to the issues discussed in Security Bulletin MS01-056?

No. If your system was already protected against the vulnerabilities, installing the patch wouldn't change that.

Did the patch delivered by the original version of this bulletin eliminate all the new vulnerabilities?

Yes. The original patch was fully effective against all of the new vulnerabilities discussed in this bulletin.

What vulnerabilities are eliminated by this patch?

This is a cumulative patch that includes all previously released fixes for Windows Media Player 6.4, 7.1, and Windows Media Player for Windows XP.

In addition, this patch eliminates three new vulnerabilities one of which has been rated as critical severity, one of moderate severity, and one of low severity.

• An information disclosure vulnerability relating to how Windows Media Player handles licensing processing with secure media files that could enable an attacker to run a program on the user's system. This issue has been rated as critical severity.
• A privilege elevation vulnerability that could enable an attacker who can physically logon locally to a Windows 2000 machine and run a program to obtain the same rights as the operating system meaning the attacker could potentially add, change or delete data or security settings.. This issue has been rated as moderate severity.
• A local script execution vulnerability that could allow an attacker's script to run as if the user had chosen to run it. This particular vulnerability has notable mitigating factors and is rated as low severity.

Finally, it introduces a configuration change, and a new, optional security configuration feature.

Cache Patch Disclosure via Windows Media Player: (CVE-CAN-2002-0372)

WhatÆs the scope of the first vulnerability?

This is an information disclosure vulnerability that could enable an attacker to run code on the system of a user. The code would then be able to take any actions on the system that the user was capable of such as adding, changing or deleting data, communicating with web sites, or changing the configuration of the system.

The attacker's code would run with the same privileges as the user: any restrictions on the user's ability to change the system would apply to the attacker's code. For example, if the user were prevented from deleting files on the hard drive, the attacker's code would similarly be prevented. Conversely, if a user were using an account with high privileges such as an administrator's account, the attacker's code would also run the same high privileges.

What causes the vulnerability?

The vulnerability results because of a flaw in how Windows Media Player handles certain types of licenses for secure media files when the media file is stored in the IE cache. Specifically, when a type of secure Windows Media file is opened, the media player erroneously returns information to the server that discloses the location of the IE cache as it processes the request to the site for the licensing information.

What is the IE Cache?

The cache is a set of system folders that are controlled by IE and is used for temporary storage when a web page or an HTML email needs to create a file on the user's local system. If a web page or HTML email needs to store information in the cache, it passes the information that it needs to store in the cache to IE for handling. IE then stores the information and retrieves it for the web page or HTML email as needed.

For example, when files are offered for download from web sites, they are actually downloaded first into the cache, at which point the user is presented with the "File Download" dialogue box. If the user chooses to cancel the download, the file is removed from the cache and the download halted. If the user chooses to open the file directly, the file remains in the cache, and is opened from there. If the user chooses to save the file in another location, the file is moved from the cache to the location specified by the user.

Under IE's security model, information in the cache should only be accessed by IE on behalf of web pages or HTML email. By design, they should not be able to access content in the cache directly.

How does IE secure information in the cache?

One way that information in the cache is protected against direct access is through obfuscation of the location of the cache on the file system. By using an obfuscation function and creating folders with dynamic names, the cache is stored in a non-predictable location. The result of this is that only IE should know the full location of anything stored in the cache, thus making it impossible for web pages or HTML email to attempt to access information in the cache, because they do not know where on the file system that information is stored.

What's wrong with how Windows Media Player and how it handles cache information?

There is a flaw in how the Windows Media Player handles a license request for a secure media file in certain situations. When Windows Media Player requests a license for a media file and that media file is located in the IE cache, Windows Media erroneously returns the obfuscated name being used by IE for caching to the server specified as the license server for that particular media file.

Does the Windows Media Player flaw affect all kinds of secure media files?

No. The flaw only occurs in how the Windows Media Player handles certain type of secure media files that use WM DRM version 1.0. Windows Media Player does not handle later versions of WM DRM in the same manner and therefore no vulnerability is exposed.

What could this vulnerability enable an attacker to do?

This vulnerability could enable an attacker to learn the location of the IE cache on the local file system. If the attacker were able to cause an executable program to be stored in the cache, the location information obtained by this vulnerability could then be used to access content in the cache directly and bypass IE's cache security mechanisms. This in turn could be used by an attacker to call an executable file stored in the cache directly, causing it to execute.

How could an attacker exploit this vulnerability?

An attacker could seek to exploit this vulnerability by making a user open a specially formed Windows Media file from within the IE cache. An attacker could seek to do this in one of two ways: they could host the file for download on a site under their control or they could send the file as part of an HTML email.

In both cases, once the media file had been played, the information regarding the IE cache location could be returned to the attacker's sites, at which point they could attempt to invoke an executable present in the cache.

How could an attacker seek to exploit this vulnerability through a web site?

An attacker could seek to exploit this vulnerability by posting their media file on a web site under their control, and then enticing the user to visit that site. As soon as the page hosting the media file had loaded in the browser and the media file opened from within the IE cache, the attempt to exploit the vulnerability would be carried out.

How could an attacker seek to exploit this through HTML email?

An attacker could seek to exploit this vulnerability by sending the media file as an attachment through HTML email. When the media file was opened from within the IE cache, the vulnerability would be exploited.

Would the attached media file play automatically or would the user have to choose to open it?

It will depend on the user's specific configuration whether the media file would play automatically or not.

If customers who are reading HTML email in the Restricted Sites zone have applied MS02-023, which disables frames in the Restricted Sites zone, attempts to have the media file play automatically would fail. In this case, users would have to choose to play the media file by double-clicking on the attached file. Outlook 98 and 2000 (after installing the Outlook Email Security Update), Outlook 2002, and Outlook Express 6 all read mail in the Restricted Sites zone by default.

However, if customers have not applied MS02-023, then it is possible for an HTML email to attempt to play the media file automatically. In this case, the attempt to exploit the vulnerability would occur as soon as the message were rendered: either through opening the message or through the preview pane.

If I've saved an attacker's file locally, does the vulnerability occur?

No. Due to the particulars of this flaw, the attacker's file must be present within the IE cache for the vulnerability to occur. This means that if you have download a media file and saved it locally before running it, the vulnerability does not occur.

What does the patch do?

The patch eliminates the vulnerability by ensuring that Windows Media Player does not return information regarding the location of the cache in IE when playing secure media files.

Privilege Elevation through Windows Media Device Manager Service: (CAN-2002-0373)

WhatÆs the scope of the second vulnerability?

This is a privilege elevation vulnerability. A malicious user who is able to both interactively log on to at the console and run a program on the system could seek to exploit this vulnerability and gain the same rights on the system as the operating system itself. This could enable the attacker to add, change, or delete any file on the system. In addition, the attacker could change the security settings or add accounts to the system.

This particular vulnerability only affects Windows Media Player 7.1 on Windows 2000 systems. Windows Media Player 6.4 on all platforms, Windows Media Player for Windows XP and Windows Media player 7.1 on Windows 98, ME are not affected by this issue. The vulnerability can be exploited only when a user logons on to a system at the console; terminal sessions are not affected by this vulnerability. Further, the user must introduce a hostile program to the system. Thus, client systems are more likely to be affected by this vulnerability than servers such as SQL or Exchange servers. This is because those systems usually restrict interactive logons to administrators. Finally, on client systems, any limitations on a user's ability to introduce and run code to the system, such as through group policies, software restriction policies, and physically security, would significantly mitigate exposure to this vulnerability.

What causes the vulnerability?

The vulnerability results because of a flaw in how the Windows Media Device Manager Service handles requests to access local storage devices. The service fails to correctly identify requests to invalid local storage devices.

What versions of Windows Media are affected by this particular vulnerability?

This vulnerability only affects Windows Media Player 7.1. Windows Media Player 6.4 and Windows Media Player for Windows XP are not affected by this specific vulnerability.

What platforms are affected by this vulnerability?

Only Windows 2000, when Windows Media Player 7.1 has been installed, is affected by this vulnerability. No other platforms are affected.

What is Windows Media Device Manager?

To allow for easy communication with a variety of media player and media storage devices Windows Media Player introduced the WMDM (Windows Media Device Manager). WMDM works to enable media player support for the transfer of media files from PC's to portable audio players and other media storage devices. Within Windows Media Player, the WMDM provides the support for the "Copy to CD or Device" feature.

What is the WMDM Service?

The WMDM Service is one of the components of WMDM and is only used in Windows 2000. It works to retrieve information regarding portable media devices on behalf of WMDM when the user does not have rights to access that media device hardware directly on a PC using. Because unprivileged users are prohibited from accessing hardware directly, the WMDM Service provides a means for media players to interact with portable media hardware, while allowing the media player to adhere to the rules of least privilege. Once WMDM has the information it needs regarding the hardware device, it then uses that information in its interaction with the portable media device.

How does the WMDM Service work?

When a media player, such as Windows Media Player, wants to copy media between hardware devices, it will connect to use the WMDM framework to carry out that request. If the hardware in question is a portable media device, WMDM will invoke the WMDM service and request that the WMDM Service retrieve information about the portable media device. Once WMDM has the information it needs from the WMDM Service, it can then manipulate the media files between the devices any way that it wants to.

For example, suppose a user has a media file stored on their local PC that they want to copy to a portable media device. The user would go into Windows Media Player and select the files to copy and the destination device, the portable media device. When this happens on Windows 2000, WMDM makes a request of the WMDM Service to obtain information regarding the portable media device. The WMDM Service returns the information that WMDM needs, and WMDM can then manipulate files between the PC and the portable media player.

What's wrong with the WMDM Service?

When the WMDM Service in Windows 2000 makes connections to hardware devices, it does so in the LocalSystem context. This is because this level of access is required to directly access hardware devices.

When the WMDM Service receives a request to connect to an invalid device, it can fail to correctly reject the request, and instead processes it. If that device is of a particular type and the request is successfully processed, the result of this operation is that the attacker has been given access to a local resource in the LocalSystem context. That local resource can then in turn be ordered by the attacker to run any local program.

What could this vulnerability enable an attacker to do?

This vulnerability could be used by an attacker to gain the same rights and privileges on the system as the operating system itself, giving the attacker complete control over the machine. As a result, the attacker could take any action on the system including but not limited to reformatting the hard drive, weakening the security settings, or adding administrators.

How could an attacker exploit this vulnerability?

An attacker could seek to exploit this vulnerability by writing a program that would attempt to call to the WMDM service and ask it to connect to a particularly named invalid resource. The attacker would have to introduce the program and run it through a console session. When the WMDM service executed the command, it would give the calling program access to the local resource in the LocalSystem context. As a result, the calling program could then use that resource to launch other programs on the system. Those programs would then run in the same security context; that is, LocalSystem.

What do you mean when you say Console Access is required to exploit this vulnerability?

Console logons are logons that are made using the keyboard, mouse and monitor that is actually plugged into the system. It can best be thought of as logging on directly to the physical system using that system's hardware resources.

In contrast to this, Windows 2000 also supports remote, terminal logons, that are made from across a network using the resources of another physical machine in conjunction with a terminal services client.

This particular vulnerability only occurs with console sessions. This means that an attempt to exploit this vulnerability requires that the attacker have direct physical access to the machine, as well as valid logon credentials.

What does the patch do?

The patch eliminates the vulnerability by correcting identifying requests to connect to invalid local storage devices and denying those requests.

Media Playback Script Invocation: (CAN-2002-0615)

WhatÆs the scope of the third vulnerability?

This is a local script execution vulnerability. An attacker who was able to successfully exploit this vulnerability could cause HTML scripts to execute as if they were run locally on the user's system. The scripts could take any action that the user was capable of, including adding, changing or deleting files or changing security settings.

This particular vulnerability is subject to a significant mitigating factor: a successful attack requires a specific series of actions follows in exact order, otherwise the attack will fail. Specifically:

• A user must play a specially formed media file from an attacker.
• After playing the file, the user must shut down Windows Media Player without playing another file.
• The user must then view a web page constructed by the attacker.

Any interruption or deviation of this sequence will cause an attempt to exploit this vulnerability to fail.

What causes the vulnerability?

The vulnerability results because of a flaw in how the Windows Media active playlist information is stored on the local system. Specifically, the playlist is stored in a fixed, known location.

What is the Windows Media Active Playlist?

To provide information regarding the content of a specific media file, Windows Media Player supports the use of playlists. Playslists usually have a .asx extension, and store information regarding media files in XML format. An example of some information that a playlist might store would be title of the work, the artist's name, and where it can be downloaded from.

When Windows Media Player plays a media file, it loads that media file's associated playlist and makes temporary copy in memory as the Active Playlist. When a new media file is played, the new file's playlist is loaded as the Active Playlist and the previous Active Playlist is deleted. When Windows Media Player is exited, one of the last actions it takes is to write the current active playlist out to the local disk, so that it can be reloaded the next time Windows Media Player is run.

What's wrong with how Windows Media stores Active Playlist information?

When it exits, Windows Media Player stores the Active Playlist information in a well known, fixed location on the local file system.

There are other files on the local file system at well-known locations, why does this particular file present a security vulnerability?

The active playlist file is different from other files in well-known locations in that, because it is XML-based, it can accept HTML script as valid input and write that information to the local disk.

This means that an attacker can attempt to use the active playlist's basic functionality to write HTML script to the local system.

This, combined with the fact that this information is written to a well-known location combines in aggregate to provide a means for an attacker to both write a script to the local machine and then invoke it from the local machine.

What could this vulnerability enable an attacker to do?

Because an attacker can use this vulnerability to invoke HTML script from the local disk, it can enable an attacker to run a script in the Local Computer zone. The restrictions that govern scripts in the Local Computer zone are less stringent than those that normally govern scripts, usually the Internet zone. Since the Local Computer zone is intended for scripts run directly by the user, scripts run in the Local Computer zone can take actions similar to those that a user can take directly. For example, a script in the local computer zone could add, change, or delete the same files that a user could.

Conversely, any restrictions on the user's ability to make changes to the local system would also limit that attacker's script. This means that if a user were prevented from changing a file due to permissions on the local file system, the attacker's script would be similarly prevented from making changes.

How could an attacker exploit this vulnerability?

To exploit this vulnerability, an attacker would first have to make the intended target play a specially formatted media file. Then, the attacker would have to make the intended target view a specially formed web page that invoked the active playlist.

Because of the way Windows Media Player handles the active playlist, a successful attack would require that the web page be viewed AFTER the user had both played the media file AND closed the Windows Media program. If those requirements are not met, the attack would fail.

This is because the information is written to the active playlist only when the Windows Media Player is shut down.

Could an attacker mount an attack using HTML email?

Yes. It is possible that an attacker could seek to levy an attack that exploits this vulnerability through email but an automated attack would be difficult if not impossible to accomplish because of the timing requirements discussed above.

I'm using a mail client that reads email in the Restricted Sites zone, am I protected against attempts to exploit this vulnerability through HTML email?

In the case of this particular vulnerability, reading email in the Restricted Sites zone does not protect against attempts to exploit this vulnerability through HTML email. This is because basic HTML functionality, which is permitted in the Restricted Sites zone, is sufficient to invoke the vulnerability.

Is there anything that can mitigate against attempts to exploit this vulnerability by email?

Yes. The "Read as Plan Text" feature in Outlook 2002 SP1 can protect against attempts to exploit this vulnerability by HTML email. This is because this feature disables all HTML functionality.

Could an attacker mount an attack from a malicious web site?

Yes. It is possible that an attacker could seek to exploit this vulnerability by posting their malicious media file and web page on a site under their control.

Again, however, the particulars of this vulnerability as discussed above make an automated attack difficult if not impossible to accomplish because of the timing requirements.

What does the patch do?

The patch eliminates the vulnerability by no longer writing the active playlist to a well-known location on the hard disk and ensuring that information within the active playlist is encoded, to ensure that it cannot be invoked by HTML script.

Windows Media Player configuration change

What's the scope of the configuration change?

This is a change that removes the file extension associated with Windows Media Skins, .wms, from Windows Media Player. Once the patch has been applied, .wms files will no longer automatically open Windows Media player when clicked or received.

Are you eliminating the Windows Media Skin feature?

No. The Windows Media Skin feature is not being eliminated. Rather, we're making a change to how Skins are handled so that they don't open Windows Media Player automatically. Users can still download and open .wms files to apply them.

Why are you making this change? Does this mean there was a vulnerability with Windows Media Skins?

No. There is no vulnerability or flaw in the behavior of Windows Media Skins. The security mechanisms that govern their use continue to be safe.

As part of an ongoing security review, it was decided that the association of .wms files with Windows Media player were not necessary for the basic operation of the feature. Therefore, in accordance with the principle of least privilege, it was decided to remove the association.

New Configuration Option

What's the scope of the optional security configuration feature?

This is a configuration feature that can allow users to disable the processing of HTML scripts contained within Windows Media files.

In itself, the patch makes no change to the handling of scripts within Windows Media files: those scripts will still function normally. However, the patch adds a new feature that users can choose to enable that will allow them to disable the processing of all HTML script contained within media files.

Why are you making this change, does this mean that there's a problem with scripts contained in media files?

No. There is no vulnerability or flaw in script handling feature in Windows Media player. It is safe to continue to use this feature.

Based on customer feedback, we have learned that some customers would like the ability to disable the functionality of this feature. Based on that feedback, we have made a new optional configuration feature that customers can use to disable this feature.

Where can I get more information on this new feature? There is more detailed information available on this new feature, and how to implement it, in Microsoft Knowledge Base article Q320944.

Installation platforms:
The patch can be installed on any operating system running Windows Media Player 6.4 or 7.1.

The patch for Windows Media Player for Windows XP can be installed on Windows XP Gold.

Inclusion in future service packs:
The fixes for these issues will be in Windows XP SP1.

Reboot needed: The patch only requires a reboot if Windows Media Player is running at the time the patch is applied.

Superseded patches: MS01-056.

Verifying patch installation:

• To verify that the patch has been installed on the machine, confirm that the following registry key has been created: HKLM\SOFTWARE\Microsoft\Updates\Windows Media Player\wm320920
• To verify the individual files, use the patch manifest provided in Knowledge Base article Q320920

Caveats:
None

Localization:
Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".

Obtaining other security patches:
Patches for other security issues are available from the following locations:

• Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
• Patches for consumer platforms are available from the WindowsUpdate web site
• All patches available via WindowsUpdate also are available in a redistributable form from the WindowsUpdate Corporate site.