Why is Microsoft re-releasing this bulletin?
The original version of the bulletin advised customers of a workaround procedure that could be used while a patch was under development. We have now completed the patch, and have updated this bulletin to advise customers of its availability as well as to discuss other vulnerabilities that it eliminates.
What vulnerabilities are eliminated by this patch?
This patch, when installed, eliminates all known security vulnerabilities affecting Internet Explorer 5.5 and 6.0. In addition to eliminating all previously discussed vulnerabilities affecting these versions, it also eliminates three new ones.
- Two vulnerabilities involving the handling of cookies.
- A newly discovered variant of a vulnerability discussed in Security Bulletins MS01-051 including a newly discovered variants of the Zone Spoofing vulnerability.
What's the scope of the first two vulnerabilities?
The first two vulnerabilities have essentially the same scope, even though they are two seperate flaws. A malicious web site with a malformed URL could read or potentially alter the contents of a user's cookies, which might contain personal information. In addition, it is possible to alter the contents of the cookie.
In order to exploit the vulnerability, an attacker would either need to entice the user into visiting a particular web page, or send an HTML mail to the user. However, the latter attack would be blocked if the user had installed the Outlook Email Security Update, or was running Outlook 2002, which includes the Update by default.
What causes these vulnerabilities?
The vulnerability results because of a flaw in the way IE identifies the web page the user is visiting, when determining which cookies the site should be able to access.
What are cookies?
A cookie is a small data file that's stored on a user's system by a web site, and which contains information that allows the site to customize its behavior for the user. For instance, a web site that sells shoes might use a cookie to record the fact that when you visit the site, you always buy athletic shoes. This would allow the site to take you directly to the athletic shoe section when you visit it.
What prevents one web site from accessing another site's cookies?
Each cookie on your system indicates what site created it and, by design, IE will only allow that site to access the cookie. The two security vulnerabilities here result because under certain conditions it's possible for a web site to bypass this protection and access cookies that were created by other sites.
What kind of information could someone gain if they accessed the cookies on my system?
It would depend on what information has been stored in the cookies. Most sites don't store personal data within cookies. For instance, in the example above, the web site might have a database that contains information about customers' shoe preferences, and it might only store data in the cookie that tells it which database entry to look up. In such a case, it wouldn't matter whether an attacker could access the cookie, because it wouldn't reveal any information.
On the other hand, if a site did store personal information in the cookie - for instance, in the example above, if the site stored your shoe preference directly in the cookie - an attacker who accessed it could potentially compromise personal information
How could an attacker carry out an attack using either of these vulnerabilities?
An attacker could attempt to exploit this vulnerability by hosting a page with a maliciously crafted URL, or by sending the victim an HTML email with a similarly crafted URL.
In the case where the attacker hosted a web page, would he have any way to compel me to visit the site?
The attacker could not force you to visit his site. Instead, he would need to entice you into performing some action that would cause you to visit the site. There are, however, a variety of actions that could be used to do this, from visiting a web site that would redirect you to the attacker's, to opening an HTML e-mail that referenced the attacker's site.
In the case where the attacker sent me an HTML e-mail, would simply opening the mail allow me to be attacked?
Yes. It is possible for an attacker to craft an HTML email in such a way that it would exploit either of these vulnerabilities on opening the mail. However, it's worth noting that the Outlook Email Security Update, if installed, would prevent this attack from succeeding. (The Update is included as part of Outlook 2002).
I've heard that IE 5.01 is not affected by the original cookie handling vulnerability, is that true?
While IE 5.01 is outside of hotfix support, it has been tested and found to be unaffected by this vulnerability in all versions (gold, SP1, and SP2)
When the original version of the bulletin was released, I disabled Active Scripting. Can I turn it back on now?
Yes. Here's how:
- On the Tools menu, click Internet Options, click the Security tab, and then click Custom Level.
- In the Settings box, scroll down to the Scripting section, and click Enable under "Active scripting" and "Scripting of Java applets".
- Click OK, and then click OK again.
I am a network administrator. How can I re-enable active scripting in my enterprise?
To re-enable Active Scripting on a network-wide scale, you'll need to make a registry change on the client machines. There are two ways to do this: by creating an auto-config INS file using Profile Manager and then applying it, or via SMS or a logon script.
You'll need to change the settings in two registry keys:
- HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones
- HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones
There are five different sub keys under each "Zones" key, each controlling a different security zone. The key names are 0-4.
- 0 = Your computer
- 1 = Local Intranet
- 2 = Trusted Sites
- 3 = Internet
- 4 = Restricted Sites
Under each zone number key, there is a DWORD value that governs Active Scripting within that zone. The name of this key is "1400". Setting the value of this key to "0" enables Active Scripting; setting it to "3" disables it.
HKCU setting changes take effect immediately. However the HKLM settings would most likely require a reboot.
What does the patch do?
The patch eliminates the vulnerabilities by implementing proper domain checking when handling cookies.
What's the scope of the third vulnerability?
The third vulnerability is a new variant of the "Zone Spoofing" discussed in Microsoft Security Bulletin MS01-051. It could allow a web site to take actions that it should not be able to take on visiting users' systems. Specifically, it could allow the web site to trick IE into treating it as though it was located on the user's intranet, thereby gaining the ability to use less-restrictive security settings than are appropriate. A user could be affected by this vulnerability either by surfing to an attacker's web site or opening an HTML mail from an attacker.
If the security settings were left in their defaults, the additional privileges the web site would gain still wouldn't allow it to take any destructive action. The greater danger from this vulnerability would arise in the case where the user had give intranet sites additional latitude.
Are there any differences between this vulnerability and the one discussed in MS01-051?
The new variant is exactly the same as the original one, except for the specific way in which it could be exploited.
