exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

ms02-032

ms02-032
Posted Aug 29, 2002
Site microsoft.com

Microsoft Security Bulletin MS02-032 - Cumulative Patch for Windows Media Player. Patch released that fixes the following three vulnerabilities: An information disclosure vulnerability that could provide the means to enable an attacker to run code on the user's system and is 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. A script execution vulnerability related that could run a script of an attacker's choice as if the user had chosen to run it after playing a specially formed media file and then viewing a specially constructed web page. This particular vulnerability has specific timing requirements that makes attempts to exploit vulnerability difficult and is rated as low severity.

tags | web, vulnerability, info disclosure
systems | windows
SHA-256 | 39638826819b7b607de3219c2a2a4938c1e8dd5a91b222b99f8f87cfc62cec4b

ms02-032

Change Mirror Download
    TechNet Home >  Security >  Bulletins

Microsoft Security Bulletin MS02-032
[Print] Print

26 June 2002 Cumulative Patch for Windows Media Player (Q320920)

Originally posted: June 26, 2002
Updated: July 24, 2002 (Version 2.0)

Summary

Who should read this bulletin: Customers using Microsoft® Windows Media™ Player 6.4, 7.1 or Windows
Media Player for Windows XP.

Impact of vulnerability: Three vulnerabilities, first reported on June 26 2002, the most serious of
which could be used to run code of attacker's choice.

Maximum Severity Rating: Critical

Recommendation: Customers running affected products should apply the patch immediately. Customers
who are still running Windows Media Player 7.0 should upgrade to Windows Media Player 7.1 first and
then apply the patch immediately.

Affected Software:

* Microsoft Windows Media Player 6.4
* Microsoft Windows Media Player 7.1
* Microsoft Windows Media Player for Windows XP

Technical details

Technical description:

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.

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.

The patch includes the functionality of all previously released patches for Windows Media Player
6.4, 7.1 and Windows Media Player for Windows XP. In addition, it eliminates the following three
newly discovered vulnerabilities one of which is rated as critical severity, one of which is rated
moderate severity, and the last of which is rated low severity:

* An information disclosure vulnerability that could provide the means to enable an attacker to
run code on the user's system and is 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.
* A script execution vulnerability related that could run a script of an attacker's choice as if
the user had chosen to run it after playing a specially formed media file and then viewing a
specially constructed web page. This particular vulnerability has specific timing requirements
that makes attempts to exploit vulnerability difficult and is rated as low severity.

It also introduces a configuration change relating to file extensions associated with Windows Media
Player. Finally, it introduces a new, optional, security configuration feature for users or
organizations that want to take extra precautions beyond applying IE patch MS02-023 and want to
disable scripting functionality in the Windows Media Player for versions 7.x or higher.

Mitigating factors:

Cache Path Disclosure via Windows Media Player:

* Customers who have applied MS02-023 are protected against attempts to automatically exploit
this issue through HTML email when they read email in the Restricted Sites zone. Outlook 98 and
Outlook 2000 with the Outlook Email Security Update, Outlook 2002 and Outlook Express 6.0 all
read email in the Restricted Sites zone by default.
* The vulnerability does not affect media files opened from the local machine. As a result of
this, users who download and save files locally are not affected by attempts to exploit this
vulnerability.

Privilege Elevation through Windows Media Device Manager Service:

* This issue affects only Windows Media Player 7.1. It does not affect Windows Media Player for
Windows XP nor Windows Media Player 6.4.
* The vulnerability only affects Windows Media Player 7.1 when run on Windows 2000. It does not
impact systems that have no user security model such as Windows 98 or Windows ME systems.
* This issue only affects console sessions; users who logon via terminal sessions cannot exploit
this vulnerability.
* An attacker must be able to load and run a program on the system. Anything that prevents an
attacker from loading or running a program could protect against attempts to exploit this
vulnerability.

Media Playback Script Invocation:

* A successful attack requires a specific series of actions follows in exact order, otherwise the
attack will fail. Specifically:
o A user must play a specially formed media file from an attacker.
o After playing the file, the user must shut down Windows Media Player without playing
another file.
o The user must then view a web page constructed by the attacker.

Severity Rating:

Cache Path Disclosure via Windows Media Player:
Internet Servers Intranet Servers Client Systems

Windows Media Player 6.4 Low Low Critical

Windows Media Player 7.1 Low Low Critical

Windows Media Player for Windows XP Low Low Critical

Privilege Elevation through Windows Media Device Manager Service:
Internet Servers Intranet Servers Client Systems

Windows Media Player 6.4 None None None

Windows Media Player 7.1 on Windows 2000 Low Low Critical

Windows Media Player 7.1 all other platforms None None None

Windows Media Player for Windows XP None None None

Media Playback Script Invocation:
Internet Servers Intranet Servers Client Systems

Windows Media Player 6.4 None None None

Windows Media Player 7.1 Low Low Low

Windows Media Player for Windows XP None None None

Aggregate Severity of all issues included in this patch (including issues addressed in previously
released patches):
Internet Servers Intranet Servers Client Systems

Windows Media Player 6.4 Critical Critical Critical

Windows Media Player 7.1 Critical Critical Critical

Windows Media Player for Windows XP Low Low Critical
The above assessment is based on the types of systems affected by the vulnerability, their typical
deployment patterns, and the effect that exploiting the vulnerability would have on them. The
License Handling cache disclosure vulnerability could be used to run code on the system as the user.
The Privilege Elevation through Windows Media Device Manager Service requires the ability to logon
at the console: terminal sessions are not affected. In addition, the attacker must be able to load
and run a program. The Media Playback Script Invocation vulnerability has specific timing
requirements that make an automated attack difficult to accomplish.

Vulnerability identifier:

* Cache Path Disclosure via Windows Media Player: CAN-2002-0372
* Privilege Elevation through Windows Media Device Manager Service: CAN-2002-0373
* Media Playback Script Invocation: CAN-2002-0615

Tested Versions:
Microsoft tested Windows Media Player 6.4, 7.1 and Windows Media Player for Windows XP to assess
whether they are affected by this vulnerability. Previous versions, including 7.0, are no longer
supported, and may or may not be affected by these vulnerabilities. If they have not done so
already, customers using Windows Media Player 7.0 should install Windows Media Player 7.1 prior to
installing this patch.

Frequently asked questions

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.

Patch availability

Download locations for this patch

* Microsoft Windows Media Player 6.4:
http://download.microsoft.com/download/winmediaplayer/Update/320920/W98NT42KMe/EN-US/wm320920_64.exe
* Microsoft Windows Media Player 7.1:
http://download.microsoft.com/download/winmediaplayer/Update/320920/W982KMe/EN-US/wm320920_71.exe
* Microsoft Windows Media Player for Windows XP:
http://download.microsoft.com/download/winmediaplayer/Update/320920/WXP/EN-US/wm320920_8.exe

Additional information about this patch

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.

Other information:

Acknowledgments

Microsoft thanks the following people for working with us to protect customers:

* jelmer for reporting the Cache Patch Disclosure via Windows Media Player.
* The Research Team of Security Internals (www.securityinternals.com) for reporting Privilege
Elevation through Windows Media Device Manager Service:
* Elias Levy, Chief Technical Officer, SecurityFocus (http://www.securityfocus.com/), for
reporting the Media Playback Script Invocation.

Support:

* Microsoft Knowledge Base article Q320920 discusses this issue and will be available
approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found
on the Microsoft Online Support web site.
* Technical support is available from Microsoft Product Support Services. There is no charge for
support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about
security in Microsoft products.

Disclaimer:
The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any
kind. Microsoft disclaims all warranties, either express or implied, including the warranties of
merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its
suppliers be liable for any damages whatsoever including direct, indirect, incidental,
consequential, loss of business profits or special damages, even if Microsoft Corporation or its
suppliers have been advised of the possibility of such damages. Some states do not allow the
exclusion or limitation of liability for consequential or incidental damages so the foregoing
limitation may not apply.

Revisions:

* V1.0 (June 26, 2002): Bulletin Created.
* V2.0 (July 24, 2002): Bulletin revised to indicate a missing file from MS01-056 has been
included, and a correction to the aggregate severity table has been made.

Contact Us | E-mail this Page | TechNet Newsletter

© 2002 Microsoft Corporation. All rights reserved. Terms of Use Privacy Statement Accessibility
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    0 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close