Microsoft Security Bulletin MS00-046 - Critical
Patch Available for 'Cache Bypass' Vulnerability
Published: July 20, 2000
Originally Posted: July 20, 2000
Microsoft has released a patch that eliminates a security vulnerability in Microsoft® Outlook® and Outlook Express. The vulnerability could allow a malicious user to send an HTML mail that, when opened, could read, but not add, change or delete, files on the recipient's computer. If coupled with other vulnerabilities, it could potentially be used in more advanced attacks as well.
The patch eliminates this vulnerability as well as those discussed in Microsoft Security Bulletins MS00-043 and MS00-045. Customers who already have taken the corrective action discussed in either of these bulletins do not need to take any additional action.
- Microsoft Outlook Express 4.x
- Microsoft Outlook Express 5.x
- Microsoft Outlook 98
- Microsoft Outlook 2000
Vulnerability Identifier: CVE-2000-0621
By design, an HTML mail that creates a file on the recipient's computer should only be able to create it in the so-called cache. Files in the cache, when opened, do so in the Internet Zone. However, this vulnerability would allow an HTML mail to bypass the cache mechanism and create a file in a known location on the recipient's disk. If an HTML mail created an HTML file outside the cache, it would run in the Local Computer Zone when opened. This could allow it to open a file on the user's computer and send it a malicious user's web site. The vulnerability also could be used as a way of placing an executable file on the user's machine, which the malicious user would then seek to launch via some other means.
The vulnerability would not enable the malicious user to add, change or delete files on the user's computer. Only files that can be opened in a browser window, such as .txt, .jpg or .htm files, could be read via this vulnerability, and the malicious user would need to know or guess the full path and file name of every file he wished to read.
The vulnerability resides in a component that is shared by Outlook and Outlook Express, and as a result the vulnerability affects both products. A version of the component that is not affected by the vulnerability ships as part of Outlook Express 5.5, and customers who have installed it do not need to take any additional action. Outlook Express 5.5 is available as part of Internet Explorer 5.01 Service Pack 1, and, except when installed on Windows 2000, Internet Explorer 5.5.
Frequently asked questions
What's this bulletin about?
Microsoft Security Bulletin MS00-046 announces the availability of a patch that eliminates a vulnerability in Microsoft® Outlook® and Outlook Express. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.
What's the scope of the vulnerability?
This vulnerability could allow a malicious user to send an email to another user which, if opened, would allow the malicious user to read files on the recipient's computer. The vulnerability would not allow the malicious user to add, change or delete files, nor would it allow him to usurp any administrative control over the machine. The malicious user would need to know the name and location of every file on the user's computer he wanted to read, and could only read file types that can be opened in a browser window. This vulnerability also could assist a malicious user in mounting other, more serious attacks, because it would allow him to place a file in a known location on the disk, which he might then seek to launch. However, the mechanism by which the file could be launched is beyond the scope of this vulnerability.
What causes the vulnerability?
The vulnerability exists because it's possible via several methods (all eliminated by the patch) for an HTML mail to create a file that lies outside the so-called cache.
What's the cache?
The cache is a special set of folders controlled by the Internet Explorer security architecture. (The IE security architecture handles all HTML processing, regardless of whether the HTML was received via the web or via e-mail). When an HTML e-mail needs to create a file on the recipient's disk, 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 the HTML 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 downloading attached files?
No. Attached files don't involve the cache, and don't have anything to do with this vulnerability. File attachments are always saved wherever the user - not the HTML mail or the IE security architecture - decides. The files at issue here are carried inline, within the HTML mail itself. Such files typically are used to provide formatting information, background images, animation, etc, for use in displaying the e-mail's text. Inline data files don't cause a warning dialogue to be displayed when they're saved to disk. An inline file is typically intended to be used only by the specific HTML mail that carried it, 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 an 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 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 forces an HTML mail to work through the cache?
The HTML mail works through the cache because, by design at least, it can't save files any other way. If it needs to use an inline file, it must put it in the cache.
What kind of security measures does the security architecture take when retrieving a file from the cache?
The most important security measure, at least for the purposes of this vulnerability, is that the security architecture ensures that any cached HTML files are opened in the Internet Zone, rather than the Local Computer Zone. It does this even though the files did in fact come from the user's local computer. This is appropriate, because the files aren't necessarily trusted by the user (recall that a warning dialogue isn't displayed when files are cached), and should be treated the same as any other file from the Internet.
Can an HTML e-mail open a file that isn't in the cache?
Yes, but only if it knows the file's name and complete path. By design, only the user can put files onto the disk but outside of the cache - usually this is done as part of a software installation, but in any case it's done deliberately. The files are therefore trusted and, when opened in Internet Explorer, run in the Local Computer Zone.
What's the difference between the Internet Zone and the Local Computer Zone?
The Local Computer Zone allows a web page to have considerably more privileges than the Internet Zone. Most important for our purposes, the Local Computer Zone allows a web page to access files on the user's computer.
How could a malicious user exploit this vulnerability?
If a malicious user sent an HTML e-mail that exploited this vulnerability, the e-mail could create an HTML file on the local computer, outside of the cache. The HTML e-mail could then open the file using Internet Explorer. The result of these operations would be that there would now be a page open in Internet Explorer, running in the Local Computer Zone but under the control of the malicious user's HTML e-mail. Because the Local Computer Zone allows files on the user's hard drive to be accessed, the page would be able to open a file, then send its contents back to the malicious user's web site. It's important to note, however, that even HTML files running in the Local Computer Zone cannot change, add or delete files - they can only view them.
What kind of files could be read via this vulnerability?
Only files that could be opened in a browser window could be read. 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.
Could this vulnerability be exploited by a web site rather than an HTML e-mail?
No. The vulnerability - the ability to bypass the cache mechanism - is specific to Outlook and Outlook Express, and couldn't be exploited through Internet Explorer. However, once an HTML e-mail exploited this vulnerability to write a file outside of the cache, the file could be opened by a web site that knew of the location of the file.
Does this vulnerability pose any other risk?
Yes. The ability to place a file in a known location on the disk could be an important step toward a more dangerous attack. If a malicious user created an HTML mail that exploited this vulnerability to place an executable file on the recipient's machine, and he had a means of invoking the executable file, he would have the ability to run code of his choice on another user's computer. It's worth keeping in mind, though, that this vulnerability only enables the file to be saved, not launched. A malicious user would have to combine an attack that exploited this vulnerability with another attack to actually cause code to run on a recipient's machine.
Why does this vulnerability affect both Outlook and Outlook Express?
Outlook and Outlook Express both rely on the same system component to provide the caching mechanism. Applying the patch corrects the problem in the system component, thereby eliminating the vulnerability in both products.
How can I tell if I'm affected by the vulnerability?
You are not affected by the vulnerability if any of the following are true:
- You have performed a default installation Internet Explorer 5.01 Service Pack 1 on your system.
- You have performed a default installation Internet Explorer 5.5 on your system and your system is not Windows 2000.
- You have installed the patch discussed in either Microsoft Security Bulletin MS00-043 or MS00-045.
If none of the above apply to you, you should install the patch.
What's the significance of performing a default installation of IE5.01 SP1 or IE 5.5?
A default installation of these products installs Outlook Express 5.5, which includes a version of the component that is not affected by the vulnerability.
Why doesn't IE 5.5 eliminate the problem on Windows 2000?
In the specific case where IE 5.5 is installed on Windows 2000, there isn't a provision by which to install Outlook Express 5.5, so the component at issue here isn't updated. Windows 2000 users can eliminate the vulnerability by either installing IE 5.01 SP1 or applying the patch.
What does the patch do?
The patch closes the loopholes that allow an HTML e-mail to save files to a known location on the local disk.
How do I use the patch?
The Knowledge Basearticle contains detailed instructions for applying the patch to your site.
Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.
How can I tell if I installed the patch correctly?
The Knowledge Baseprovides 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 procedure that eliminates the vulnerability.
- Microsoft has provided a security bulletin and this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
- 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 Technical Supportcan provide assistance with this or any other product support issue.
Download locations for this patch The vulnerability can be eliminated by taking any of the following actions:
- Contacting Microsoft Product Support
- Performing a default installation of Internet Explorer 5.01 Service Pack 1.
Performing a default installation of Internet Explorer 5.5 on any system except Windows 2000.
Note: The patch requires IE 5.01 or IE 4.01 SP2 to install. Customers who install this patch on versions other than these may receive a message reading "This update does not need to be installed on this system". This message is incorrect. More information is available in KB article Q247638.
Note: In addition to eliminating the vulnerability at issue here, the patch above also eliminates all vulnerabilities discussed in Microsoft Security Bulletins MS00-043 and MS00-045. Customers who already have taken the corrective action discussed in either of these bulletins do not need to take any additional action.
Additional information about this patch
Installation platforms: Please see the following references for more information related to this issue.
- Microsoft Knowledge Base (KB) article Q247638, http://support.microsoft.com/default.aspx?scid=kb;en-us;247638&sd=tech
Support: This is a fully supported patch. Information on contacting Microsoft Technical Support is available at http://support.microsoft.com/contactussupport/?ws=support.
Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
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.
- July 20, 2000: Bulletin Created.
Built at 2014-04-18T13:49:36Z-07:00