Microsoft Security Bulletin MS01-015

Technical description:

The IE security architecture provides a caching mechanism that is used to store content that needs to be downloaded and processed on the user's local machine. The purpose of the cache is to obfuscate the physical location of the cached content, in order to ensure that the web page or HTML e-mail will work through the IE security architecture to access the information. This ensures that the uses of the information can be properly restricted.

A vulnerability exists because it is possible for a web page or HTML e-mail to learn the physical location of cached content. Armed with this information, an attacker could cause the cached content to be opened in the Local Computer Zone. This would enable him to launch compiled HTML help (.CHM) files that contain shortcuts to executables, thereby enabling him to run the executables.

In addition to eliminating this vulnerability, the patches provided below eliminate three other vulnerabilities that either pose significantly less risk or could only be exploited in very restricted situations:

• A variant of the "Frame Domain Verification" vulnerability discussed in Microsoft Security Bulletins MS00-033, MS00-055, and MS00-093. The vulnerability could enable a malicious web site operator to open two browser windows, one in the web site's domain and the other on the user's local file system, and to pass information from the latter to the former. This could enable the web site operator to read, but not change, any file on the user's local computer that could be opened in a browser window.
• A vulnerability that is identical in effect to the "Frame Domain Verification" vulnerability, but which actually results from a flaw in Windows Script Host rather than IE. Because it could only be exploited via IE, we have provided the fix here. The fix that was released on March 06, 2001, was subsequently discovered to have a regression error, and a corrected version was released on April 20, 2001.
• A vulnerability that affects how Telnet sessions are invoked via IE. By design, telnet sessions can be launched via IE. However, a vulnerability exists because when doing so, IE will start Telnet using any command-line options the web site specifies. This only becomes a concern when using the version of the Telnet client that installs as part of Services for Unix (SFU) 2.0 on Windows NT® 4.0 or Windows® 2000 machines. The version of the Telnet client in SFU 2.0 provides an option for creating a verbatim transcript of a Telnet session. An attacker could start a session using the logging option, then stream an executable file onto the user's system in a location that would cause it to be executed automatically the next time the user booted the machine. The flaw does not lie in the Telnet client, but in IE, which should not allow Telnet to be started remotely with command-line arguments.

Mitigating factors:

• None of the vulnerabilities could be exploited without some user action - either browsing to the attacker's site or opening a mail from him. Customers who exercise safe browsing habits would be less likely visit untrustworthy sites, and customers who have used the Security Zones feature to restrict what HTML mail can do would be less likely to be affected by this vulnerability.
• The variants of the "frame domain verification" vulnerability discussed above could only be used to view files, and only file types that can be opened in a browser window.
• The vulnerability affecting Telnet invocation is only a concern for customers who are using the Telnet client that ships as part of Services for Unix 2.0. Other versions of Telnet do not include the command-line feature to create log files.

Vulnerability identifiers:

• Cached content identifier vulnerability: CAN-2001-0002
• New variant of "frame domain verification" vulnerability: CAN-2001-0148
• Windows Script Host vulnerability: CAN-2001-0149
• Telnet invocation vulnerability: CAN-2001-0150

Tested Versions:

Microsoft tested Internet Explorer 5.01 and 5.5, and Windows Script Host 5.1 and 5.5, to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

What vulnerabilities are discussed in this bulletin?
There are four vulnerabilities discussed here.

• A vulnerability affecting how cached content is handled in IE.
• A new variant of the previously discussed "Frame Domain Verification" vulnerability
• A vulnerability whose effects are identical to those of the "Frame Domain Verification" vulnerability, but which actually lies in Windows Script Host rather than IE.
• A vulnerability affecting how the Telnet client can be invoked.

You re-issued this bulletin on April 20, 2001. Why? 
We found a regression error in the fix we originally released for the vulnerability affecting Windows Script Host. After correcting the error, we re-issued the bulletin to advise customers of the situation and ask them to upgrade to the new builds. The regression errors did not affect the patches for any of the other issues.

What's the scope of the vulnerability affecting how cached content is handled?
This vulnerability could enable an attacker to cause code of his choice to execute on the system of a user who either visited the attacker's web site or opened an HTML e-mail from him. The code would be able to do anything that the user herself could do, including adding, deleting or change files, communicating with web sites, or reformatting the hard drive.
The vulnerability could not be exploited without some user action - either browsing to the attacker's site or opening a mail from him. Customers who exercise safe browsing habits would be less likely visit untrustworthy sites. Likewise, customers who have used the Security Zones feature to restrict what HTML mail can do would be less likely to be affected by this vulnerability.

What causes the vulnerability?
The vulnerability results because it's possible under some conditions to learn the location of content that has been placed in the IE cache.

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

When you say "create a file", are you referring to e-mail attachments?
No. E-mail attachments don't involve the cache, and don't have anything to do with this vulnerability. They are always saved wherever the user decides. The files at issue here a referenced by a web page or carried inline within an HTML mail itself. Such files typically are used to provide formatting information, background images, animation, etc, for use in displaying the text of the page or mail.
These files don't cause a warning dialogue to be displayed when they're saved to disk, because they're typically intended to be used only by the specific web page or HTML mail they're associated with, and even then only temporarily. Because such files are, by design, always stored in the cache and constrained by the security architecture, it's considered a safe operation to download them without a warning dialogue.

How does the cache work?
When a web page or HTML mail 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 page or HTML mail 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.

What's wrong with how the cache operates? 
It's possible under certain conditions for the web page or HTML mail to learn the random name that was assigned to a file when it was put in the cache. This would allow it to directly address the file.

Why does it pose a security risk for a web page or HTML mail to be able to directly address data in the cache?
Under the IE security architecture, files are handled differently depending on whether they're directly addressed or accessed via the cache. Files that can be directly addressed are opened in the Local Computer security zone; ones that are accessed through the cache are opened in whatever security zone the web page or HTML mail is in.
The Local Computer Zone imposes far fewer restrictions on content than do the other zones. Of particular importance in this context is what it allows compiled HTML help (.CHM) files to do. As discussed in Microsoft Security Bulletin MS00-037, compiled HTML help files can contain shortcuts that allow programs to be executed. The patch provided in MS00-037 restricts the conditions under which this can be done, so that only .CHM files on the local computer can use shortcuts. This vulnerability would enable an attacker to place .CHM files containing shortcuts into the cache, then directly address, thereby launching them in the Local Computer Zone; this would allow him to run programs in the same manner as discussed in MS00-037.

How likely is it that this vulnerability would pose a danger to me?
The likelihood of being attacked by a web site using this vulnerability depends primarily on your web browsing habits. Most customers visit a small number of familiar, trustworthy web sites that are extremely unlikely to attack their visitors. In addition, many customers use the IE Security Zones to limit what untrusted sites can do. Customers who have disable Active Scripting on untrusted sites would be at no risk from this vulnerability.
The likelihood of being attacked via an HTML e-mail depends on how you've configured your mail client. Outlook and Outlook Express let you specify which IE Security Zone to open HTML mail in. Customers who have configured their mail client to open mail in the Restricted Sites Zone, and who have configured that zone to disable Active Scripting, would not be at risk from this vulnerability.

How does the patch eliminate this vulnerability?
The patch closes the loophole that allowed HTML code on a web page or in a mail to determine the location in the cache where files had been placed. This restores the status quo ante, in which cached content always executes in the security zone associated with the web site or HTML mail.

I tried to install the IE 5.01 SP1 patch for this issue, but the web page I was directed to also discusses Microsoft Security Bulletin MS00-093. Is there a mistake? 
No, the information is correct. That patch eliminates this vulnerability as well as those discussed in MS00-093. Please note, however, that this is only true for the IE 5.01 SP1 version of the patch. The other supported version of IE, IE 5.5 SP1, has separate patches for this issue and for the ones discussed in MS00-093.

What's the scope of the new variant of the "Frame Domain Verification" vulnerability?
The scope is exactly the same as for the original variant, discussed in Microsoft Security Bulletin MS00-033. It could allow a malicious web site operator to view files on the computer of visiting user. The malicious web site operator would need to know the name and location of the file on the user's computer, and could only view files that can be opened in a browser window.

Where can I get more information on the "Frame Domain Verification" vulnerability? 
Microsoft Security Bulletins MS00-033, MS00-055, and MS00-093 discuss the vulnerability in detail.

Are there any differences between the new variant and the previous variants?
The new variant has exactly the same cause, effect, and remediation as the previously reported ones. However, there are two differences:

• When reported publicly, this vulnerability was discussed in the context of Windows Media Player. Although it is possible to exploit this vulnerability via Windows Media Player, the flaw actually lies within IE.
• Unlike the previous variants, the new one only affects IE 5.5 and IE 5.5 Service Pack 1. No other versions of IE are affected.

Does this patch eliminate the original variants as well as the new one? 
Yes. It eliminates all known variants, as well as eliminating the vulnerability discussed above involving the IE cache mechanism. It does not, however, eliminate the two vulnerabilities discussed below -- separate patches are needed for these.

What's the scope of the vulnerability that involves Windows Script Host?
The scope of this vulnerability is exactly the same as that of the new variant of the "Frame Domain Verification" vulnerability discussed above. It could allow a malicious web site operator to view files on the computer of visiting user. The malicious web site operator would need to know the name and location of the file on the user's computer, and could only view files that can be opened in a browser window.
The sole difference between this vulnerability and the "Frame Domain Verification" vulnerability is the location of the flaw that causes each. The "Frame Domain Verification" vulnerability is caused by a flaw in IE. In contrast, the "Cross-Domain File Reading" vulnerability is caused by a flaw in Windows Script Host (WSH).

If the vulnerability lies in WSH, why are you providing the fix in a bulletin that discusses IE vulnerabilities?
Although the underlying flaw is in WSH, the vulnerability would be most likely to be exploited by a web site, via IE. Because of this fact, and the similarity between this issue and the "Frame Domain Verification" vulnerability, we concluded that it made sense to deliver the fix as part of an IE bulletin.

What's wrong with WSH?
Under certain conditions, WSH doesn't properly check the domain when certain requests are made of it. In the vast majority of cases, these requests would be made by web sites, via IE. The end result is that it could be possible for a malicious user's web site to open a window on the user's local file system and be able to read the data there. As in the "Frame Domain Verification" vulnerability discussed above, this vulnerability could only be exploited if the user visited an untrustworthy web site or opened an HTML mail from a malicious user.

How can I tell whether I'm using an affected version of Windows Script Host?
You'll need to know the version number of WSH you're using. Follow these steps to determine it:

1. From the Start menu, select Search, then For Files or Folders
2. Search for either Jscript.dll or VBscript.dll. (It doesn't matter which you search for).
3. When the search results are displayed, right-click on the file, then select Properties. (Note: if the search finds more than one copy of the file, select the one located in C:\windows\system if you are running Windows 95, 98 or Me, or select the one located in C:\WINNT\system32 if you are running Windows NT or Windows 2000).
4. Select the Version tab and note the version number displayed there.

The version number should have the form "x.x.x.xxxx", where the x's represent any digit. Once you have the version number, here's how to determine whether you need a patch:

• If the first two digits are 5.1, and the last four digits are less than 6330, you need to upgrade to the latest version of WSH 5.1.
• If the first two digits are 5.5, and the last four digits are less than 6330, you need to upgrade to the latest version of WSH 5.5.
• If the first two digits are less than 5.1, it doesn't matter what the last four digits are -- you need to upgrade to the latest version of WSH. You can upgrade to either WSH 5.1 or WSH 5.5.
• If none of the above apply to you, you do not have a version of WSH that's affected by the vulnerability.

Why do I need to upgrade my version of WSH? Why can't I just install a patch? 
The entire Windows Script Host is no larger than many patches, so there's little penalty in installing an entirely new build. There are, however, two significant benefits from providing the fix via a new build of the Host:

• The new builds correct a number of bugs that aren't security-related, in addition to eliminating the vulnerability.
• Customers who want to move from WSH 5.1 to WSH 5.5 can do so simply by installing the latest build of WSH 5.5

So, if I'm running Windows Script Host 5.1, I can install the fix for Windows Script Host 5.5? 
Yes. Because we're providing the fix via new builds, customers using WSH 5.1 can, if they wish, install the new build of WSH 5.5 and upgrade the version of WSH on their machines.

If I upgrade my version of WSH, will it also eliminate the new variant of the "Frame Domain Verification" vulnerability?
No. Despite the similarities between the Windows Script Host vulnerability and the new variant of the "Frame Domain Verification" vulnerability, the underlying problems are completely separate. To protect against both, you need to ensure that you're running an upgraded version of WSH and have installed the patch for the new variant of the "Frame Domain Verification" vulnerability.

What's the scope of the Telnet invocation vulnerability?
This vulnerability could enable an attacker to write files onto the system of a user who either visited the attacker's web site, or who opened a specially-formatted HTML mail the attacker sent. The attacker could use the vulnerability to carry out a variety of attacks, the most serious of which would enable him to place a program onto the user's system, which could then be made to run automatically each time the user logged on.
The vulnerability could only be exploited if a particular version of the Telnet utility were installed on the system. This version is only available as part of a separate add-on package that can only be installed on Windows NT 4.0 and Windows 2000 systems. It does not ship by default as part of any platform.

What causes the vulnerability?
The version of Telnet that ships with Services for Unix 2.0 includes an option to create a transcript of the Telnet session. Because Telnet can be automatically started via a web page or HTML mail, an attacker could potentially use this option to write a file of his choice onto the user's system.

What's Telnet? 
Telnet is a standard TCP/IP protocol that allows a client to establish a command-line session on a remote server. Through such a session, the client can run programs or issue commands on the remote machine. A Telnet client is provided as part of every Windows platform.

What's wrong with the Telnet client?
There isn't anything wrong with the client. However, a logging feature introduced in the version of the Telnet client that ships with Services for Unix 2.0 could be misused via a flaw in IE.

What is Services for Unix 2.0? 
Services for Unix 2.0 is an add-on package that provides a set of interoperability components that make it easy for customers to integrate Windows NT 4.0 and Windows 2000 into their existing Unix environments. For the purposes of this vulnerability, two points about Services for Unix 2.0 are important: installing it is the only way to get the version of Telnet involved in this vulnerability, and it can only be installed on Windows NT 4.0 and Windows 2000 systems.

What's the logging function?
The logging function allows the user to create a verbatim transcript of a Telnet session. All information exchanged during the session is recorded into a file of the user's choice. The option can be selected as a command-line argument when starting the Telnet client.

What danger does the logging function pose?
Under most conditions, it doesn't pose any danger. In a typical Telnet session, the person on the client machine would start the Telnet client and connect to a Telnet server of her choice. She would select which options would be used and would control what occurs during the session. In short, she would be in control of the session.
The vulnerability results because it's possible for a web page or an HTML mail to request a Telnet session via IE. If this happened, the Telnet client would be started on the user's machine, using any command-line options that were specified by the web page or HTML mail. If the attacker specified the logging option and then streamed data to the client, all of that data would be recorded in the log file.

What would this enable the attacker to do?
Under the IE security architecture, files are handled differently depending on whether they're directly addressed or accessed via the cache. Files that can be directly addressed are opened in the Local Computer security zone; ones that are accessed through the cache are opened in whatever security zone the web page or HTML mail is in.
The Local Computer Zone imposes far fewer restrictions on content than do the other zones. Of particular importance in this context is what it allows compiled HTML help (.CHM) files to do. As discussed in Microsoft Security Bulletin MS00-037, compiled HTML help files can contain shortcuts that allow programs to be executed. The patch provided in MS00-037 restricts the conditions under which this can be done, so that only .CHM files on the local computer can use shortcuts. This vulnerability would enable an attacker to place .CHM files containing shortcuts into the cache, then directly address, thereby launching them in the Local Computer Zone; this would allow him to run programs in the same manner as discussed in MS00-037.

Why does IE allow web pages and HTML mails to start Telnet sessions?
IE supports a variety of TCP/IP protocols, all of which can be specified in URLs. For instance, consider a familiar URL like http://www.microsoft.com. In this URL, the "http:" specifies that the resource, www.microsoft.com, should be viewed using the Hypertext Transfer Protocol (HTTP). When IE processes an URL like this, it executes the application associated with HTTP, namely, the browser.
Likewise, it's also legitimate to have an URL that specifies a resource that should be viewed using Telnet, or any of a variety of other TCP/IP protocols. In theory, this should be a safe operation, since the resource is a server rather than a client. The user is the client in the session, and the client should always control the session. In this case, however, the availability of the logging feature clearly makes it unsafe to allow the session.

How does the patch eliminate this vulnerability?
The patch eliminates the vulnerability by preventing command-line options from being passed to the Telnet client via URLs. This prevents an attacker from being able to specify the logging option.

Does the patch for this issue also eliminate the other vulnerabilities discussed above? 
No. It only eliminates this particular vulnerability. Patches are available that will eliminate the other vulnerabilities discussed above.

Why not get rid of the ability to Telnet altogether? 
Many customers need the ability to visit resources of various types from the browser. However, customers who do not want this ability can disable it. Telnet is an example of an Asynchronous Pluggable Protocol (APP). It's possible to edit the registry to remove any APPs that aren't desired.

If I never installed Services for Unix 2.0, could I be affected by this vulnerability?
No. The only way to have the affected version of the Telnet client is to install Services for Unix 2.0.

I'm not sure whether I installed Services for Unix 2.0 . Is there a way to tell? 
One way would be to check the version of the Telnet client that's on your machine. The affected version of telnet.exe is version 5.2000.0328.1, built on Dec. 7 1999.

Download locations for this patch

• Cached content identification vulnerability and new variant of "frame domain verification" vulnerability:
  • IE 5.01 SP1:

    http://www.microsoft.com/windows/ie/downloads/critical/q279328/default.mspx

  • IE 5.5 SP1:

    http://www.microsoft.com/windows/ie/downloads/critical/q286045/default.mspx

    Note: Microsoft recommends that all customers install this patch. The patch for IE 5.01 SP1 also eliminates the vulnerabilities discussed in Microsoft Security Bulletin MS00-093; the patch for IE 5.5 SP1 only eliminates the vulnerabilities discussed here.

    Note: The patch for IE 5.5 SP1 has been superseded by the patch released for MS01-027

• Windows Script Host vulnerability:

  Upgrade to current builds as per the below links.

  • Windows Script 5.1: Contact Microsoft Product Support
  • Windows Script 5.5 for Windows 98, Windows Millennium Edition and NT 4.0
  • Windows Script 5.5 for Windows 2000

    Note: Microsoft recommends that all customers running an affected version of Windows Script Host install one of the upgrades above. (The FAQ identifies the affected versions). Customers using Windows Script Host 5.1 or earlier can upgrade to Windows Script Host 5.5 if they would like.

• Telnet invocation vulnerability:
  • IE 5.01 SP1 and IE 5.5 SP1:

    http://www.microsoft.com/windows/ie/downloads/critical/q286043/default.mspx

    Note: Microsoft recommends that customers who have installed Services for Unix 2.0 install this patch.