Microsoft Security Bulletin MS00-090

Technical description:

The two vulnerabilities discussed below are unrelated to each other except by the fact that they both affect Windows Media Player. We packaged them in a single patch to make it more convenient for customers to apply. The vulnerabilities are:

• The ".ASX Buffer Overrun" vulnerability. Windows Media Player supports the use of Active Stream Redirector (.ASX) files to enable users to play streaming media that resides on intranet or Internet sites. However, the code that parses .ASX files has an unchecked buffer, and this could potentially enable a malicious user to run code of his choice on the machine of another user. The malicious user could either send an affected file to another user and entice her to run or preview it, or he could host such a file on a web site and cause it to launch automatically whenever a user visited the site. The code could take any action on the machine that the legitimate user herself could take.
• The ".WMS Script Execution" vulnerability. Windows Media Player 7 introduced a feature called "skins", that allows customization of the look and feel of Windows Media Player. However, a custom skin (.WMS) file could potentially include script, which would execute if Windows Media Player was run and that skin was selected. A malicious user could either send a customized skin containing script to another user and try to entice her into using it, or he could host such a file on a web site and cause it to launch automatically whenever a user visited the site. Because the code would reside on the user's local machine, it would be able to execute ActiveX controls, including ones not marked "safe for scripting". This would enable the code to take any action that can be accomplished via an ActiveX control.

What's this bulletin about?
Microsoft Security Bulletin MS00-090 announces the availability of a patch that eliminates two vulnerabilities in Microsoft® Windows Media™ Player. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerabilities and what they can do about them.

Why does this bulletin discuss two vulnerabilities?
We've packaged the fix for two vulnerabilities involving Windows Media Player together, in order to minimize the number of patches customers need to apply.

How are the vulnerabilities related to each other?
The only thing these two vulnerabilities have in common is the fact that they both affect Windows Media Player.

What are the vulnerabilities?
There are two vulnerabilities, both discussed in detail below:

• The "ASX Buffer Overrun" vulnerability, which affects both Windows Media Player 6.4 and 7.
• The "WMS Script Execution" vulnerability, which affects only Windows Media Player 7

What's the scope of the "ASX Buffer Overrun" vulnerability?
This is a buffer overrun vulnerability. A malicious user could create a streaming media file containing specially-malformed data that, when played by another user, would cause code of the malicious user's choice to run on the other user's computer. The code could take any action on the computer that the user herself could take, and could be used to compromise data on the victim's computer, misuse software already on it, download additional software and run it, or take additional action.

What causes the vulnerability?
There is an unchecked buffer in a section of Windows Media Player that handles .ASX files. By including a particular type of malformed entry in an .ASX file, a malicious user could cause code of his choice to execute when another user played the file.

What's an .ASX file?
Active Stream Redirector (.ASX) is one of the file types supported by Windows Media Player. .ASX files don't actually contain any streaming media - instead, they provide information telling Windows Media Player where to find a particular media stream on an intranet or Internet site, and how to use it. Detailed information on .ASX files is available from the Microsoft Developers Network.

What's wrong with how Windows Media Player handles .ASX files?
One of the buffers used to read data from an .ASX file doesn't check the length of the data before using it. As a result, it would be possible for a malicious user to deliberately insert data into the file that would overrun the buffer. If the data were carefully chosen, it could have the effect of modifying the executable code in Windows Media Player while it was running.

What could the modified code do?
When Windows Media Player runs, it does so in the security context of the user. This means that if this vulnerability were exploited, the modified Windows Media Player code could do anything on the machine that the user who ran it could do. As a result, the scope of the vulnerability would depend greatly on what privileges the victim had on her own machine.

• If the victim had only limited privileges on the machine, the malicious user's code would be similarly limited. However, in most cases even an unprivileged user could add, delete or change data files, run programs, send data to or receive data from a web site, and so forth - so the malicious user's code could take these actions as well.
• If the victim had administrative privileges, the code could use these as well, and cause greater damage. However, if the least privilege principal has been observed, users will not have been given administrative privileges unless absolutely required.

How could the malicious user exploit this vulnerability?
There are two basic scenarios through which a malicious user might seek to exploit this vulnerability:

• He could send an .ASX file to a potential victim and try to entice her into saving it on her computer. At that point, it would be a matter of persuading her to either preview the file (by single-clicking on it) or opening it (by double-clicking on it). This scenario depends on the user violating normal best practices, and saving, then accessing, a file from an untrusted party.
• He could host an .ASX file on a web site and cause it to be launched automatically whenever someone visited the site. He would then need to either wait for a victim to visit his site, or he could send an HTML mail that, when opened, would open a browser window to the site.

If the malicious user hosted the .ASX file on a web site, would the victim need to click on it in order to be affected by the vulnerability?
Under default conditions, it would be possible for the web site to automatically open the .ASX file whenever someone visited the site. However, the IE Security Zones feature can prevent this - it lets you categorize web sites into different zones, and specify what the sites in each zone can do. If a user had configured IE to prevent sites in the Internet Zone (the zone where all web sites are categorized by default) from invoking ActiveX controls, a web site could would be unable to launch .ASX files automatically. Instead, the operator would need to entice the user into clicking a link in order to launch such a file.

You said previously that the malicious user would need to overrun the buffer with carefully-chosen data in order to run code of his choice. What would happen if he just overran it with random data?
If the buffer were overrun with random data, it would cause Windows Media Player to fail. This wouldn't pose a security problem, and the user could simply restart it and resume normal operation.

What's the scope of the "WMS Script Execution" vulnerability?
This vulnerability could enable a malicious user to run a program of his choice on another user's computer via a feature in Windows Media Player. Such a program could take virtually any action on the user's machine that she herself could take, and could be used to compromise data on the victim's computer, misuse software already on it, download additional software and run it, or take additional action.
The vulnerability only affects Windows Media Player 7. The feature at issue here was not available in previous versions of Windows Media Player.

What causes the vulnerability?
Script programs can be embedded within .WMS files. If such a file was installed and selected within Windows Media Player as the current skin, the script would execute.

What's a .WMS file?
.WMS files are used to provide Windows Media Player skins. Skins are a new feature introduced in Windows Media Player 7, and they enable the user to customize the look and feel of Windows Media Player. Custom skins also can be included as part of .WMZ files (which contain both a custom skin and the art associated with a skin) or .WMD files (which can contain multiple .WMS files). However, the mechanics of the vulnerability would be the same regardless of how the skin was packaged.
Windows Media Player 7 includes a number of default skins that the user can choose from, but it's also possible to develop custom skins that create an entirely new look and feel.

Is this a problem with the default skins that come with Windows Media Player 7?
No. Customers who are using any of the default skins are not at risk from this vulnerability. The problem arises only in conjunction with custom-written skins.

What's the problem with the implementation of the skins feature?
It's possible for a person writing a custom skin to embed a script program in it. If he could then convince another user to download and install the skin -- or could cause it to be downloaded and installed automatically -- the script would execute each time Windows Media Player was run with that skin selected. Because the script would run on the user's local machine, it could execute ActiveX controls, including ones that are not marked as "safe for scripting".

What do you mean by a script?
"Script" is a generic term describing any programming language that is interpreted rather than compiled. Examples of scripting languages include Javascript, VBScript, PerlScript, etc.

Why is it a problem for script to be able to run on my machine?
A script running on a user's machine should, by design, only be able to do so if the user herself runs it. As a result, scripts running on the user's machine (as opposed to scripts running on, say, a web site) can execute any desired ActiveX control regardless of whether it's marked safe for scripting or not.

What do you mean by "safe for scripting"?
When a developer writes an ActiveX control, he must mark it to indicate whether the control is a safe one to allow web sites to use. Marking a control as "safe for scripting" is an assertion by the author that the control is not capable of being misused to take a destructive action. By giving a malicious user the ability to run script on the user's machine, it would enable him to take destructive action via ActiveX controls.

What's the point of having ActiveX controls that are not "safe for scripting"?
The important point to keep in mind is that the "safe for scripting" label only refers to whether a control is safe for a web site to use. There's no telling who is operating a particular web site, and so it makes sense to limit what they can do. You wouldn't, for instance, want every web site you visit to be able to modify data on your computer.
In contrast, if a user chooses to run a program on her local computer, it should be able to do whatever it's programmed to do - because only the user should be able to execute it. A computer on which you can't, for instance, modify your own data isn't much use. As a result, programs on the local machine can always run any ActiveX control, regardless of how it's marked.

What could the script do via ActiveX controls?
The script would be able to take a broad range of actions on the user's computer. ActiveX controls - ones that are not marked "safe for scripting" - are available that could be misused to change data on the machine, to exchange data with web sites, and to take other actions as well. There are hundreds of ActiveX controls on most systems, and the malicious web site operator would be able to use most or all of them.
However, if there were no ActiveX control available to perform a particular action, the malicious user would be unable to perform it. Also, it's important to note that ActiveX controls are always subject to the user's permissions on the machine. If the user were working on a workstation that had been "locked down", the script might be able to do very little. However, if the user was an administrator on the machine, the script would potentially be able to do a great deal of damage.

How could the malicious user exploit this vulnerability?
After creating a custom skin file that contained the desired script, the malicious user could attack another user via either of two scenarios:

• He could send the file to a potential victim and try to entice her into saving it on her computer, installing it into Windows Media Player, selecting it as the current skin, and then running Windows Media Player. This scenario is really no different from any other case in which a user runs untrusted code.
• He could host the file on a web site and cause it to be installed and launched automatically whenever someone visited the site. He would then need to either wait for a victim to visit his site, or he could send an HTML mail that, when opened, would open a browser window to the site.

If the malicious user hosted the custom skin file on a web site, would the victim need to click on it in order to be affected by the vulnerability?
Under default conditions, it would be possible for the web site to automatically start Windows Media Player with a desired skin file whenever someone visited the site. However, the IE Security Zones feature can prevent this - it lets you categorize web sites into different zones, and specify what the sites in each zone can do. If a user had configured IE to prevent sites in the Internet Zone (the zone where all web sites are categorized by default) from invoking ActiveX controls, a web site would be unable to launch WMP automatically. Instead, the operator would need to entice the user into clicking a link in order to launch it.

I'm confused. Previously, you said that this vulnerability would let script run ActiveX controls, yet now you're saying that users can disable ActiveX controls. Why couldn't the user just disable ActiveX controls to prevent the script from using them?
The discussion regarding disabling ActiveX controls via the IE Security Zones applies only to web sites (and HTML email messages). In order to put a skin onto a user's computer automatically, a web site would need to use an ActiveX control. So, if the user had disabled ActiveX controls in IE, a web site couldn't automatically download a new skin and cause it to execute. The malicious user might still try to trick the user into downloading it by other means, but he couldn't do it automatically.
This is entirely different from what the script could do once it was running -- regardless of how it came to run. The script would not be running inside IE, so it wouldn't matter whether ActiveX controls were disabled in IE or not. Once the skin was downloaded and selected within Windows Media Player, it would be able to use ActiveX controls, regardless of what the IE settings were.

Who should use the patch?
Microsoft recommends that customers running Windows Media Player 6.4 or 7 install the patch. The fix for these issues also will be available as part of the next auto-update for Windows Media Player, scheduled for release in December.

What does the patch do?

• The patch eliminates the ".ASX Buffer Overrun" vulnerability by implementing proper bounds checking on all buffers associated with .ASX files.
• The patch eliminates the ".WMS Script Execution" vulnerability by preventing the execution of arbitrary ActiveX Objects in the skin files.

I'm using Windows Media Player 6.4, but I see that the ".WMS Script Execution" vulnerability only affects Windows Media Player 7. Should I apply the patch?
Yes. The patch only installs the correct fixes for the version of Windows Media Player you're running.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin .

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

How can I tell if I installed the patch correctly?
The Knowledge Base article provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?

• Microsoft has developed a patch and procedure that eliminates the vulnerabilities. We are making this patch available now and will also include this in a forthcoming update to the Windows Media Player 7 that can be downloaded in December using the Windows Media Player auto-update feature. We will also make this available via Windows Update in the next few weeks.
• Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerabilities and the procedure to eliminate them.
• Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
• Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Product Support Services can provide assistance with this or any other product support issue.

Download locations for this patch

• Windows Media Player 6.4:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=9B94D3F0-9CF3-4A5F-8215-A221DDD923B0&displaylang=en

• Windows Media Player 7:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=BAF62356-D717-4B8F-97E0-299A7697A083&displaylang=en

Note: The fix for this issue will also be available as part of the next periodic update, scheduled for December 2000.