|
|
|
|
| |
Many web sites use cookies as a way to store information on a user's local system. Most often, this information is used for customizing and retaining a site's setting for a user across multiple sessions. By design, each site should maintain its own cookies on a user's machine and be able to access only those cookies.
By enticing the user to click on a special URL, web sites can gain unauthorized access to user's cookies and potentially modify the values contained in them. Since some web sites store sensitive information in a user's cookies, it is also possible that personal information could be exposed.
Microsoft is preparing a patch for this issue, but in the meantime, customers can protect their systems by disabling active scripting. (The FAQ provides systematic instructions for doing this). This will protect against both the web-hosted and the mail-borne variants discussed above. When the patch is complete, Microsoft will re-release this bulletin and provide details on obtaining and using it. |
| |
Credit:
The information has been provided by Microsoft Product Security.
|
| |
Affected software:
* Microsoft Internet Explorer 5.5
* Microsoft Internet Explorer 6.0
Mitigating factors:
* A user must first be enticed to a malicious web site or to open an HTML e-mail containing the malformed URL.
* Users who have applied the Outlook Email Security Update are not affected by the HTML mail exploit of this vulnerability.
* Users who have set Outlook Express to use the "Restricted Sites" Zone are not affected by the HTML mail exploit of this vulnerability because the "Restricted Sites" zone sets Active Scripting to disabled. Note that this is the default setting for Outlook Express 6.0. Users of Outlook Express 6.0 should verify that Active Scripting is still disabled in the Restricted Sites Zone.
Patch availability:
Download locations for this patch.
A patch will be posted as soon as it is available.
What is the scope of this vulnerability?
A malicious web site with a malformed URL could read the contents of a user's cookie that might contain personal information. In addition, it is possible to alter the contents of the cookie. This URL could be hosted on a web page or contained in an HTML email.
What causes the vulnerability?
The vulnerability results because of an unsafe handling of cookies across IE zones.
How would an attacker carry out an attack using this vulnerability?
An attacker could attempt to maliciously exploit this vulnerability by hosting a page with a maliciously crafted URL. They could also send 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 construct an HTML email in such a way that it would exploit this vulnerability on opening the mail.
Why does changing my IE settings help protect me against a mail-borne attack?
As we mentioned above, HTML e-mails are just web pages sent via e-mail. Outlook uses the IE security architecture to limit what HTML e-mails can do when opened. By default, Outlook 2002 opens all HTML e-mails in the Restricted Sites Zone.
Is this a permanent change?
No. Microsoft is working to develop a patch that will eliminate the vulnerability. When it is completed, you will be able to install the patch and then return your IE settings to their previous values.
How likely is it that I could be affected by this vulnerability?
It depends on your web browsing and e-mail habits. Customers who exercise care in choosing the sites they visit, and who are careful not to open obvious spam and other untrustworthy e-mails would be at less risk from this vulnerability. However, customers can easily make a configuration change that will provide complete protection.
What is the configuration change that will protect against this vulnerability?
Customers who are concerned about this vulnerability should disable active scripting. All web pages (and HTML e-mails, which are just web pages delivered via e-mail) are categorized into one of several zones, and the settings in each zone dictate what actions can be taken within it. By disabling active scripting in the Internet zone a user can prevent an attacker from exploiting either the web-borne or mail-borne versions of this attack.
How do I disable active scripting in Internet Explorer 5.5 and 6.0?
* 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 Disable under "Active scripting" and "Scripting of Java applets".
* Click OK, and then click OK again.
I am a network administrator. How can I disable active scripting in my enterprise?
* With new deployments of Internet Explorer, an administrator would use the IEAK and disable active scripting before building the package and rolling it out to client machines.
* For currently deployed client use Profile Manager to create an auto-config INS file to make registry changes needed to disable active scripting on the client machines with Internet Explorer already installed.
* For administrators that prefer to use SMS or login scripts, the following are the registry changes that would disable active scripting on the client machine:
* 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 key control a different security zone. The key names are 0-4.
0 = Your computer
1 = Local Intranet
2 = Trusted Sites
3 = Internet
4 = Restricted Sites
There is then a DWORD value under each zone number key that must be modified to disable active-scripting for each zone.
REG_DWORD value is "1400" to be modified.
Setting this value to "3" (from "0") will disable active scripting.
HKCU setting changes take effect immediately. However, the HKLM settings would most likely require a reboot.
|
|
|
|
|
