Microsoft Security Bulletin MS01-029

Technical description:

This bulletin discusses two security vulnerabilities that are related to each other only by the fact that they affect Windows Media Player. We packaged them in a single patch for customers using Windows Media Player 6.4 to make it more convenient for customers to apply. For customers using Windows Media Player 7, both security vulnerabilities are addressed by upgrading to Windows Media Player 7.1.

The two vulnerabilities are:

• A buffer overrun in the functionality used to process Active Stream Redirector (.ASX) files. This vulnerability is a variant of the buffer overrun vulnerability identified in Microsoft Security Bulletin (MS00-090). Windows Media Player supports the use of .ASX files to enable users to play streaming media that resides on intranet or Internet sites and allows the use of playlists. However, the code that parses .ASX files has an unchecked buffer, and this could potentially enable a malicious user to run code of her choice on the machine of another user. The attacker could either send an affected file to another user and entice him to run or preview it, or she 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 himself could take.
• A vulnerability affecting how Windows Media Player handles Internet shortcuts. Windows Media Player has a flaw that causes it to save Internet shortcuts to the user's Temporary Files folder with a fixed known filename. This results in a security vulnerability because it's possible for HTML code to be stored in such a shortcut and launched via a web page or HTML e-mail, in which case the code would run in the Local Computer Zone rather than the Internet Zone. An attacker could exploit this vulnerability to read - but not add, delete or modify - files on another user's computer.

In addition, this patch provides a solution to a potential privacy vulnerability that was recently identified. This issue could be exploited by a malicious set of web sites to distinguish a user. While this issue would not by itself enable a web site to identify the user, it could enable the correlation of user information to potentially build a composite description of the user. .Users can protect themselves by installing the above patch or upgrading to Windows Media Player 7.1, then changing the appropriate settings in their player as outlined below to prevent sets of websites from potentially profiling using Windows Media Player.

• In Windows Media Player 6.4, the privacy setting is selected via a new option, which can be reached by going to the menu item View / Options then selecting the player tab and de-selecting "Allow Internet sites to uniquely identify your player".
• In Windows Media Player 7.1, the privacy setting is toggled via the existing option under the tools menu, on the player tab and deselect the option "Allow Internet sites to uniquely identify your player".

Although we typically do not discuss privacy issues in security bulletins, the privacy issue in this case is eliminated by applying the patch and then selecting the new user settings as described above. We have provided this information because the best way to make the privacy update available to customers was by including it in this patch, and because we wanted to provide users who installed the patch with information about how to use the new privacy settings.

Mitigating factors:

Buffer overrun vulnerability:

• The attacker would need the ability to entice the user into either visiting a web site she controlled, or opening an HTML e-mail she had prepared.
• The attacker would need to know the specific operating system that the user was running in order to tailor the attack code properly; if the attacker made an incorrect guess about the user's operating system platform, the attack would crash the user's application, but not run code of the attacker's choice.

Internet shortcut vulnerability:

• On Windows NT 4.0 and Windows 2000 systems, the location of the Temporary Files folder varies from user to user. In order to exploit the vulnerability on these systems, the attacker would need to know the exact location of the Temporary Files folder on the specific system she wished to attack.
• The attacker would need to know the exact name of each file she wished to read.
• The attacker could only view file types that can be opened in a browser window. These include.txt, .jpg, .gif, or .htm , but not file types such as .exe, .doc, and .xls.
• There is no capability to add, delete or changes files via this vulnerability.

Vulnerability identifier:

• Buffer overrun vulnerability: CAN-2001-0242
• Internet shortcut vulnerability: CAN-2001-0243

Tested Versions:

Microsoft tested Windows Media Player 6.4 and 7 to assess whether they are affected by these vulnerabilities. Windows Media Player 7.1 and Windows Media Player for Windows XP (formerly known as Windows Media Player 8) are not affected by these vulnerabilities. Previous versions are no longer supported and may or may not be affected by these vulnerabilities.

What issues does this bulletin address?
This bulletin addresses three issues affecting Windows Media Player 6.4 and Windows Media Player 7:

• A security vulnerability that could enable an attacker to run code of her choice on another user's system.
• A security vulnerability that could enable an attacker to read, but not add, delete or change, files on another user's system.
• A privacy issue that could enable a malicious set of web sites to uniquely identify visitors through profiling.

Why are you discussing a privacy issue in a security bulletin?
We typically only discuss security vulnerabilities in security bulletins. However, in this case, the patch for the security issue also happens to eliminate the privacy issue when the player settings are also changed by the user as described above, and we want to ensure that customers know of this fact, and understand what the privacy update does.

What's the scope of the first security vulnerability?
This is a buffer overrun vulnerability. It could enable an attacker to run a program of her choice on the machine of another user, provided that she was able to entice the user into visiting a web site she controlled or opening an HTML e-mail she had prepared. The program would be capable of taking any action on the user's machine that the user himself was capable of taking, including adding, creating or deleting files, communicating with web sites, or reformatting the hard drive.

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, an attacker could cause code of her 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 an attacker 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 his own machine.

• If the victim had only limited privileges on the machine, the attacker'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 attacker'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 principle 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 an attacker might seek to exploit this vulnerability:

• She could send an HTML mail that, when opened, would execute the malicious .ASX file.
• She could host an .ASX file on a web site and cause it to be launched automatically whenever someone visited the site. She would then need to wait for a victim to visit her 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 would not be able to launch .ASX files automatically. Instead, the attacker would need to entice the user into clicking a link in order to launch such a file.

You said previously that the attacker would need to overrun the buffer with carefully-chosen data in order to run code of her choice. What would happen if she 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.

How does the patch eliminate this vulnerability?
The patch eliminates the vulnerability by ensuring that the code checks the length of all inputs before storing them in buffers.

What's the scope of the second security vulnerability?
This security vulnerability could enable an attacker to read certain types of files from the computer of a user who visited her web site. The vulnerability would not allow her to add, change or delete files, nor would it allow her to usurp any administrative control over the machine.
There are some significant mitigating factors associated with this vulnerability:

• To exploit this vulnerability, the attacker would need the ability to persuade a user to visit a particular web page or open an HTML e-mail she had created.
• The attacker would need to know the exact file name and location of every file she wanted to read via this vulnerability.
• On a Windows NT 4.0 or Windows 2000 system, the attacker would need to know the exact location of the Temporary Files folder, which is unique for every user.

What causes the vulnerability?
The vulnerability results because Windows Media Player stores Internet shortcuts in the user's Temporary Files folder with a fixed known filename. This could give an attacker an opportunity to create a file containing HTML on the user's system and open it in the Local Computer Zone rather than the Internet Zone.

What's an Internet shortcut?
A shortcut is a link to something that's accessible from your computer - a file, a program, a folder, a disk drive, etc. One of the advantages of shortcuts is that they can be handled exactly like the objects they point to, so they can be dragged and dropped onto the desktop, into menus, or into folders. Shortcuts also can be created to point to web pages. When this is the case, the shortcut is referred to as an Internet shortcut. The vulnerability at issue here involves how Internet shortcuts are created by Windows Media Player.

What's wrong with the way Windows Media Player creates Internet shortcuts?
By design, Internet shortcuts should be created within the IE cache. However, due to an implementation flaw, Windows Media Player actually creates them with a fixed known filename in the user's Temporary Files folder.

What's the IE cache?
The cache is a special set of folders controlled by the Internet Explorer security architecture. When web content - that is, a web page or an HTML e-mail - needs to create a file on the user's system, it should, by design, be required to store it in the cache. Because only the security architecture knows how to retrieve a cached file, this ensures that any web content that wants to access the file will have to work through the security architecture to do so, and the security architecture will therefore always be in a position to control what the file can do.

How does the cache work?
When web content needs to store a file, it generates a Globally Unique Identifier (GUID), assigns it to the file, and then asks the security architecture to put the file into the cache for it. The security architecture generates a random name for the file - one that only it knows - and records the correspondence between the GUID and the random name in an internal table. When the web content needs to use the file, it requests it via the GUID, and the security architecture retrieves the file and opens it after taking appropriate security measures.

How does the cache help protect the user?
The cache protects the user by changing which Security Zone the file is opened in. Normally, when IE opens a file that resides on the local system, it does so in a special zone called the Local Computer Zone. However, if the file came from the cache, it's opened in the Internet Zone instead and is given far fewer privileges. This reflects the fact that the file was placed there by a web page or HTML e-mail rather than the user.

What would this vulnerability enable an attacker to do?
Internet shortcuts can contain HTML code, and if this is the case, the HTML code will be processed by IE when the shortcut is opened. By creating an Internet shortcut outside of the cache and including HTML code in it, an attacker would gain the ability to run the HTML code in the Local Computer Zone rather than in the Internet Zone. This would give the HTML code additional privileges.

What kind of privileges would the code gain?
HTML code running in the Local Computer Zone has considerably more privileges than code running in the Internet Zone. Most important for our purposes, though, it can open certain types of files on the user's computer. This wouldn't give the HTML code the ability to add, delete or modify them, but it could send the contents of the file back to the attacker's web site.

What types of files could the HTML code open?
It could open any file type that can be opened within a browser window. These include .txt, .jpg, .gif, or .htm files. File types like .exe, .doc, .xls and others could not be opened in a browser window and therefore could not be read via this vulnerability. The attacker would need to know the exact name and location of each file she wanted to read via this vulnerability.

What would the attacker need to do in order to place an Internet shortcut on a user's system?
The attacker would need to persuade the user to open web content she had prepared. Practically speaking, this means that she would need to be able to entice the user into either visiting her web site or opening an HTML e-mail she had created.

Once the Internet shortcut had been placed on the user's machine, how might the attacker open it?
The attacker could open the file via the same web page or HTML mail that created it. It wouldn't be necessary for the user to click on the shortcut.

Are there any impediments to exploiting the vulnerability?
Yes. In order for the attacker's web page or HTML e-mail to open the Internet shortcut, she would need to have coded the exact location of the shortcut on the user's computer. This turns out to be a significant mitigating factor.
On Windows 95, 98 and Me systems, the location of the Temporary Files folder is well known and does not vary from user to user. However, on Windows NT 4.0 and Windows 2000 systems, each user has a unique Temporary Files folder that resides within their own user profile. As a result, the location of the file would vary from machine to machine, and from user to user. Unless the attacker knew (or could guess) the exact location of the Temporary Files folder, she wouldn't be able to exploit this vulnerability against Windows NT 4.0 or Windows 2000 users.

You said above that this could only be used to read files, but I saw a demonstration that ran a program on my machine! How was this possible?
It's true that HTML code running in the Local Computer Zone could use an ActiveX control to launch a program residing on the user's computer. However, there is no capability to pass any parameters to such a program. So, for instance, an attacker could run the Format program, but couldn't specify any parameters, such as which disk to format.

How does the patch eliminate the vulnerability?
The patch eliminates this vulnerability by ensuring that Windows Media Player stores Internet shortcuts with a random file name in the Temporary Files folder.

What's the potential privacy issue?
The privacy issue could provide a malicious web site operator with a means of differentiating between users who visited her web site, independent of using cookies. There is a possibility that usage could be tracked across multiple web sites if the web sites were coordinated and capturing certain data, which might enable the development of a composite profile of the user and his activities. This would give her a means of distinguishing between visitors to the site, and determining when a person subsequently returned to the site, even if the user had disabled the use of cookies for performing the same task.
This would not provide a way for an individual web site operator to learn the user's identity or email address. However, it could be possible for two or more web sites to correlate information in order to build a profile of the user.

What causes the privacy issue?
A malicious web site could access a unique identification number associated with Windows Media Player usage and potentially uniquely identify and differentiate one person from another. Users can protect themselves by installing the above patch or upgrading to Windows Media Player 7.1, then changing the appropriate settings in their player as outlined below to prevent sets of websites from potentially profiling using Windows Media Player.

• In Windows Media Player 6.4, the privacy setting is selected via a new option, which can be reached by going to the menu item View / Options then selecting the layer tab and de-selecting "Allow Internet sites to uniquely identify your player".
• In Windows Media Player 7.1, the privacy setting is toggled via the existing option under the tools menu, on the player tab and deselect the option "Allow Internet sites to uniquely identify your player".

Why is this a privacy issue?
This is only a privacy issue if a web site operator chose to use this approach without notifying site visitors. It could potentially enable a web site to differentiate one user from others, without using cookies, thereby circumventing browser cookie control settings.

Would this enable the web site to determine the user's name or email address?
Not by itself. The identification number is unique from user to user, but it's not correlated with any of the user's personal information.

Is there any way that this information could be used to learn a person's identity?
It would not be easy but, there is a possibility that usage could be tracked across multiple web sites if the web sites were coordinated and capturing certain data, which might enable the development of a composite profile of the user and his activities.

How does the patch eliminate this issue?
The patch provides the user with the ability to make the Windows Media Player identification number change each time it's requested. Users can protect themselves by installing the above patch or upgrading to Windows Media Player 7.1, then changing the appropriate settings in their player as outlined below to prevent sets of websites from potentially profiling using Windows Media Player.

• In Windows Media Player 6.4, the privacy setting is selected via a new option, which can be reached by going to the menu item View / Options then selecting the layer tab and de-selecting "Allow Internet sites to uniquely identify your player".
• In Windows Media Player 7.1, the privacy setting is toggled via the existing option under the tools menu, on the player tab and deselect the option "Allow Internet sites to uniquely identify your player".

Will security bulletins regularly provide patches for privacy issues?
No. Security bulletins are intended to be focused on security issues, and we do not envision changing that scope. We discussed this issue in a security bulletin only because the fix for it was already included in a security patch.

Download locations for this patch

• Windows Media Player 6.4:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=B24B2D33-ADE5-4F43-AC4A-0980F1F37FF0&displaylang=en

• Windows Media Player 7:

  Upgrade to Windows Media Player 7.1