Microsoft Security Bulletin MS02-066

Technical description:

Microsoft originally issued this bulletin on November 20, 2002 with a severity rating of Important. Based on additional information made available to Microsoft after that date, Microsoft has reassessed the severity and increased the severity rating to "Critical". This increased severity rating is based on additional information about the exploitability of an unpatched system. The patch released with the original bulletin is effective in correcting the vulnerability.

It should be noted that the patch associated with this bulletin has already been superceded by the patch discussed in Microsoft Security Bulletin MS02-068, which is also rated as Critical. The patch for MS02-068, not only contains the fixes for the security vulnerabilities discussed in this bulletin but also includes the fix for an additional security vulnerability. As a result Microsoft strongly recommends that customers deploy the more current MS02-068 patch.

This is a cumulative patch that includes the functionality of all previously released patches for IE 5.01, 5.5 and 6.0. In addition, it eliminates the following six newly discovered vulnerabilities:

• A buffer overrun vulnerability that occurs because Internet Explorer does not correctly check the parameters of a PNG graphics file when it is opened. It could be possible for an attacker to use this vulnerability to run arbitrary code on a user's system. A number of other Microsoft products - notably, most Microsoft Office products and Microsoft Index Server - rely on Internet Explorer to render PNG files, and exploiting the vulnerability against such an application could cause a buffer overrun in that application as well. Because of this, Microsoft recommends that customers install this patch regardless of whether they are using Internet Explorer as their primary web browser.
• An information disclosure vulnerability related to the way that Internet Explorer handles encoded characters in a URL. This vulnerability could allow an attacker to craft a URL containing some encoded characters that would redirect a user to a second web site. If a user followed the URL, the attacker would be able to piggy-back the user's access to the second website. This could allow the attacker to access any information the user shared with the second web site.
• A vulnerability that occurs because under certain circumstances Internet Explorer does not correctly check the component that the OBJECT tag calls. This could allow an attacker to obtain the name of the Temporary Internet Files folder on the user's local machine. The vulnerability would not allow an attacker to read or modify any files on the user's local system, since the Temporary Internet Files folder resides in the Internet security zone. Knowledge of the name of the Temporary Internet Files folder could allow an attacker to identify the username of the logged-on user and read other information in the Temporary Internet Files folder such as cookies.
• Three vulnerabilities that although having differing root causes, have the same net effects. All three vulnerabilities result because of incomplete security checks being carried out when using particular programming techniques in web pages, and would have the effect of allowing one website to access information in another domain, including the user's local system. In the worst case, this could enable the web site operator to load malicious code onto a user's system. In addition, this could also enable an attacker to invoke an executable that was already present on the local system. However, a registry key setting discussed in Microsoft Knowledge Base Article 810687 disables shortcuts in HTML help, which significantly reduces the scope of these vulnerabilities.

In addition, the patch sets the Kill Bit on a legacy DirectX ActiveX control which has been retired but which has a security vulnerability. This has been done to ensure that the vulnerable control cannot be reintroduced onto users' systems and ensures that users who already have the control on their system are protected. This is discussed further in Microsoft Knowledge Base Article 810202.

The patch also makes a further refinement to cross domain verification check that was first introduced in Internet Explorer 6 Service Pack 1. This is discussed further in the Frequently Asked Questions below.

Mitigating factors:

With the exception of the Malformed PNG Image File Buffer Overrun, there are common mitigating factors across all of the vulnerabilities:

• The attacker would have to host a web site that contained a web page used to exploit the particular vulnerability.
• The attacker would have no way to force users to visit the site. Instead, the attacker would need to lure them there, typically by getting them to click on a link that would take them to the attacker's site.
• By default, Outlook Express 6.0 and Outlook 2002 open HTML mails in the Restricted Sites Zone. In addition, Outlook 98 and 2000 open HTML mails in the Restricted Sites Zone if the Outlook Email Security Update has been installed. Customers who use any of these products would be at no risk from an e-mail borne attack that attempted to exploit these vulnerabilities.

In addition to there are a number of individual mitigating factors:

Malformed PNG Image File Failure

• This vulnerability is not present in Internet Explorer 6 Service Pack 1.

Encoded Characters Information Disclosure

• The vulnerability would not enable an attacker to read, modify or execute any files on the local system.

Temporary Internet Files folder Name Reading

• An attacker could not use this vulnerability to read, delete or modify any files on the user's local system other than information contained in the Temporary Internet Files folder.
• An attacker could only exploit this vulnerability by having a user visit a malicious web site and then follow a malformed link on this malicious web site to a second web site that the user trusted.
• This vulnerability is not present in Internet Explorer 6 Service Pack 1.

Frames Cross Site Scripting, Cross Domain Verification via Cached Methods & Improper Cross Domain Security Validation with Frames

• The vulnerabilites could only be used to read files that the user had access to and that were not opened by the user or the operating system.
• If the steps described in Microsoft Knowledge Base Article 810687 have been taken to restrict shortcuts in HTML Help, then the following mitigating factors apply:
  • The vulnerabilities would not provide any way for an attacker to put a program of their choice onto another user's system.
  • An attacker would need to know the name and location of any file on the system to successfully invoke it.
  • The vulnerabilities could only be used to view or invoke local executables. They could not be used to create, delete, or modify arbitrary or malicious files.

Severity Rating:

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.

Vulnerability identifiers:

• Malformed PNG Image File Failure: CAN-2002-1185
• Encoded Characters Information Disclosure: CAN-2002-1186
• Frames Cross Site Scripting: CAN-2002-1187
• Temporary Internet Files folder Name Reading: CAN-2002-1188
• Cross Domain Verification via Cached Methods: CAN-2002-1254
• Improper Cross Domain Security Validation with Frames: CAN-2002-1217

Tested Versions:

Internet Explorer versions 5.01 SP3, 5.5 SP2, 6.0 Gold and 6.0 SP1 were tested for these vulnerabilities. Versions of IE prior to 5.01 Service Pack 3 are no longer eligible for hotfix support. IE 5.01 SP3 is supported only on Windows® 2000. More information on Windows Operating System Components Lifecycles is available from: http://www.microsoft.com/lifecycle/

What vulnerabilities are eliminated by this patch?
This is a cumulative patch that incorporates the functionality of all previously released patches for Internet Explorer. In addition, the patch eliminates six newly reported vulnerabilities:

• A vulnerability that could allow an attacker to cause arbitrary code to run on the user's system.
• A vulnerability that could disclose information store on the local system to an attacker including, potentially, personal information.
• A vulnerability that could allow an attacker to discover information about a user's file system structure, the name of the currently logged-on user and read information contained in the Temporary Internet Files folder, such as cookies.
• Three vulnerabilities that could enable a malicious web site operator to read, but not change, any file on the user's local computer that could be viewed in a browser window. In addition, the vulnerabilities could enable an attacker to invoke an executable already present on the local system.

Does the patch include any other security changes?
Yes. The patch ensures that a legacy component for viewing DirectX files cannot be used. This control, which is not installed by default with Internet Explorer, and is normally only used by developers or support professionals, has been retired and is no longer supported. However it has been found to contain a security vulnerability, and in order to protect customers who have already downloaded this control, the patch prevents the control from running or from being reintroduced onto users' systems by setting the Kill Bit for this component. More details on the killbit for this control are available in Microsoft Knowledge Base Article 810202.
The patch also refines a change made in Internet Explorer 6 Service Pack 1, which prevents web pages in the Internet Security zone from navigating to the local computer zone. This change was introduced to mitigate the effects of potential new cross domain exploits. The change introduced in this patch is a further enhancement of the Internet Explorer 6 Service Pack 1 restrictions.

Malformed PNG Image Buffer Overrun(CAN-2002-1185):

What's the scope of the first vulnerability?
This is a buffer overrun vulnerability which could cause Internet Explorer to execute arbitrary as a result of viewing a malformed PNG image file.

What causes the vulnerability? 
The vulnerability results because of an unchecked buffer in the part of Internet Explorer which checks parameters when opening PNG files.

What is a PNG file? 
A PNG file is a type of graphics file - png stands for Portable Network Graphics. The PNG specification is defined in RFC 2083. PNG files have the .png file extension.

What's wrong with the way Internet Explorer handles PNG files? 
There is a flaw in the way Internet Explorer performs boundary checks when a PNG image file is opened. Internet Explorer does not conduct these checks properly on certain parameters on the PNG file, and it is therefore possible to cause a buffer overrun. The resulting overflow could cause Internet Explorer to fail.

What could this vulnerability enable an attacker to do? 
This vulnerability could enable an attacker to cause Internet Explorer to fail in such a way that it would execute code of the attacker's choice.

Why would other Microsoft products be affected by the vulnerability? 
Several Microsoft products - for instance, Microsoft Office and Index Server - rely on Internet Explorer to render PNG files for them. As a result, they are as affected by the vulnerability as Internet Explorer itself is. As in the case of Internet Explorer, opening a malformed PNG file using one of these products could result in its failure, and therefore could allow the attacker to execute code of their choice.

How could an attacker exploit this vulnerability? 
An attacker could seek to exploit this vulnerability by hosting a deliberately malformed PNG file on a website. If the user visited this web site and viewed a page that had this malformed PNG file present, Internet Explorer could fail and could allow arbitrary code to execute.

I'm running Index Server on my servers - should I apply the fix? 
Yes. If a server is configured to allow users to upload files onto the server, and the server is running Index server, this patch should be applied. A user could deliberately upload a malformed PNG file onto the server, which would cause Index server to fail the next time it indexed the PNG file. This would be a deliberate act by a user since the user would have to download the PNG file - as opposed to viewing it in a web page - and then place it on the server.

What does the patch do? 
The patch addresses the vulnerability by ensuring that the correct boundary checks are performed when a PNG file is opened.

Encoded Characters Information Disclosure(CAN-2002-1186):

What's the scope of the second vulnerability?
This is an information disclosure vulnerability. If a user visited an attacker's website, the attacker could then "spy" on the user's session with a second website that the user visited. This would not however allow an attacker to follow a user to every site that the user visited on the Internet. The vulnerability is subject to a number of constraints:

• The user would have to first visit the attacker's website, and would then have to follow a link containing a malformed URL to a second website.
• The attacker would have no way of forcing the user to click the link that would take them to the attacker's site.
• The attacker could only spy on the user's session with the second website. The attacker could not spy on all subsequent web site visits made by the user. If the user subsequently returned to the second site at a later stage the attacker could not spy on that session either.
• An attacker cannot control what information a user would share with the second website - this would be an opportunity based attack as the attacker would have to rely on the user sharing something of value with the second site.

What causes the vulnerability? 
The vulnerability results because of a flaw in the way Internet Explorer handles URL's. A flaw exists in Internet Explorer because when certain encoded characters are included in a URL the correct security checks are evaded.

What is Character Encoding? 
Character encoding is a system of using numeric values to represent characters. Encoding is typically used to represent characters that are not present in all languages. For example, the new Euro currency symbol (€) can be represented as "20AC" in Unicode. This means that programs can still handle this character as a numerical value, even if the underlying character cannot be displayed by the program. The Unicode standard for encoding, which is one of the most common encoding standards, defines "a consistent way of encoding multilingual text that enables the exchange of text data internationally".
Other forms of encoding can include binary and hexadecimal encoding - RFC 1738 describes the types of encoded characters that are permitted in a URL.

What's wrong with the way Internet Explorer handles URLs that contain encoding? 
Internet Explorer normally conducts the same security checks on URLs regardless of whether they contain encoded characters or not. However there is a flaw in Internet Explorer which means that it does not conduct these checks properly when a URL contains certain encoded characters.

What could this allow an attacker to do? 
This vulnerability could allow an attacker to "spy" on information that a user shared with another website. For example, if a user were to visit the attacker's site- site A, and then the user clicks on a link on site A, that leads to site B, the attacker could then "spy' on the user's session with site B. This would mean that the attacker could see any information that the user shared with the site B, including personal information.

What types of information could be revealed to an attacker? 
It's impossible to say with certainty, but the sorts of information that people typically reveal to web sites includes information that can be used to personally identify them such as name, address, date of birth or credit card information. People can also reveal less important information such as their favorite color, their country of origin or the city they live in.

Could an attacker use this vulnerability to "follow" a user around the Internet? 
No. An exploit of this vulnerability would be limited in that the attacker could only follow the user to a site that is linked from the attacker's site. For example, if the user goes to the attacker's site - site A, and then follows a malformed off Site A to Site B, the attacker can follow the user to site B. But if the user then opens a new web browser page and goes to site C, or follows a link from site B to site C, the attacker could not follow the user to site C.
In addition, if the user were to go directly to site B rather than using a link on the attacker's site to visit site B, the attacker could not "spy" on the user's session with site B.

So an attacker could not "spy" on a user's session with a particular web site every time the user visited that site? 
Yes. An attacker could only spy on a session with web site B if the user clicked on a link on site A that leads to site B. If the user finished a session with web site B but then visited that site directly at some later time, an attacker could not "spy" on this new session.

So there are a number of limitations to what an attacker could do?
Yes. There are a number of limitations:

• The attack would need the user to not only visit the attacker's site, but then follow a link off the attacker's site, to a second site -site B.
• Site B would need to be a site that the user would want to visit. The attacker could not force the user to site B.
• If the user were to go directly to site B, the attacker could not "spy" on the user's session.
• The attacker could not take any actions on the system, such as adding, changing, or deleting data or running scripts.
• If the user were to follow the attacker's link the site B, and then visited a third site, the attacker would not be able to follow the user to the third site.
• If the user were to subsequently return directly to site B at a later stage, an attacker could not "spy" on this session.

How might an attacker exploit the vulnerability? 
In order to exploit this vulnerability, an attacker would have to do the following:

• Create a web site -site A - which had a hyperlink containing a malformed URL to a second site - site B. Site B would need to be a site that user would ordinarily choose to go to.
• The attacker would then need to entice the user to visit site A.
• Once the user had visited site A, the attacker would then need to entice the user to follow the link to the site B.
• If the user clicked on the URL to visit site B, the attacker would be able to "spy" on the user's session with site B.

What does the patch do? 
The patch ensures that when new pages are opened using URLs which contain these encoded characters, the correct security checks are carried out.

Temporary Internet Files Folder Name Reading(CAN-2002-1188):

What's the scope of the third vulnerability?
This vulnerability could allow an attacker to identify the path to the Temporary Internet Files folder. This could allow the attacker to discover additional information about the user such as the logged-on username, and information contained in the Temporary Internet Files folder such as cookies.

What causes the vulnerability? 
The vulnerability results because Internet Explorer does not perform the correct security checks in certain situations when the OBJECT tag is used. The result is that the OBJECT tag can be used to read the names of the Temporary Internet Files folder.

What is the Temporary Internet Files folder, and what is it used for? 
The Temporary Internet Files folder is the location on your hard disk where Web pages and files (such as graphics) are cached as you view them. This speeds up the display of pages you frequently visit or have already seen, because Internet Explorer can open them from your hard disk instead of from the Web. Obfuscation plays a vital role in ensuring that this cache is stored in a non-predictable location. By design, if a web site knows the physical location of a web page, then the web site operator could be able to learn more information about the user visiting their site. The cache prevents a web site from learning this information, thereby forcing it to submit to the Internet Explorer security model.

What's wrong with the way Internet Explorer handles the OBJECT tag? 
Normally when the OBJECT tag is used Internet Explorer carries out a number of security checks to confirm that the action requested is permitted. However Internet Explorer does not perform these security checks properly in one situation where the OBJECT tag is used which means that the security checks can be bypassed.

Why would an attacker want to know the location of the Temporary Internet Files folder? 
When you view a web page, by default it is cached in the Temporary Internet Folders file cache, for the reasons described above. Normally only Internet Explorer should know the location of the cache, however if an attacker discovers the path, the attacker can use this to reveal more information about the user.

What's wrong with the way Internet Explorer handles the OBJECT tag? 
Normally when the OBJECT tag is used Internet Explorer carries out a number of security checks to confirm that the action requested is permitted. However Internet Explorer does not perform these security checks properly in one situation where the OBJECT tag is used which means that the security checks can be bypassed.

What could this vulnerability enable an attacker to do? 
This vulnerability could enable an attacker to read the names of the Temporary Internet Files folder. An attacker could use this to reveal information about the logged-on user, such as username and could also read information in the Temporary Internet Files folder such as data in cookies.

How could an attacker exploit this vulnerability? 
An attacker could seek to exploit this vulnerability by creating a web page that used the OBJECT tag in a particular manner. If a user then visited the attacker's site, and viewed this page it would cause a second web page to be opened. The attacker would be able to use a script in the second page containing this particular OBJECT tag to read the name of the Temporary Internet Files folder.

What types of Information could be disclosed to an attacker? 
An attacker could use this vulnerability to reveal the username of the logged-on user. The attacker could also use this vulnerability to read information from any cookies that used predictable name in the Temporary Internet Files folder. However this would be complex for an attacker since cookies usually have unpredictable names and are stored in a number of different locations within the Temporary Internet Files folder. The attacker would have to check each one of these locations separately in order to locate a cookie.

What are Cookies? 
Cookies are data files that are stored on the user's local system. They are free form in structure and content: a web site can choose to store any information they choose in cookies. However, because the information always passes in clear text, it's recognized that sensitive personal information should never be stored in cookies.

What does the patch do? 
The patch prevents this method of using the OBJECT tag to circumvent Internet Explorer's security model by instituting the correct security checks.

Cross Domain Verification via Cached Methods, Frames Cross Site Scripting & Improper Cross Domain Security Validation with Frames (CAN-2002-1254, CAN-2002-1187, CAN-2002-1217):

What's the scope of these vulnerabilities?
These vulnerabilities have essentially the same scope and effects, even though they are three separate flaws. They could allow a malicious web site operator to access information in another internet domain, or the user's local system. In the worst case, the vulnerabilities could allow an attacker to load a malicious executable onto the system or to launch an executable that was already on the user's system.
If the steps described in Microsoft Knowledge Base Article 810687 have been taken to restrict shortcuts in HTML Help, the scope of the vulnerabilities is significantly reduced. The vulnerabilities would not provide a way for an attacker to deliver a program of his choice to the system - the program invoked must exist on the system for the attacker to invoke it, nor could the attacker pass any parameters to an executable program.

What causes the vulnerabilities? 
The vulnerability results because it is possible to bypass Internet Explorer's cross-domain security model when using three different programming functions in web pages.

What is meant by "Internet Explorer's cross-domain security model"? 
One of the principal security functions of a browser is to ensure that browser windows that are under the control of different web sites cannot interfere with each other or access each other's data, while allowing windows from the same site to interact with each other. To differentiate between cooperative and uncooperative browser windows, the concept of a "domain" has been created. A domain is a security boundary - any open windows within the same domain can interact with each other, but windows from different domains cannot. The "cross-domain security model" is the part of the security architecture that keeps windows from different domains from interfering with each other.
The simplest example of a domain is associated with web sites. If you visit www.microsoft.com, and it opens a window to www.microsoft.com/security, the two windows can interact with each because both belong to the same domain, www.microsoft.com. However, if you visited www.microsoft.com, and it opened a window to a different web site, the cross-domain security model would protect the two windows from each other. The concept goes even further. The file system on your local computer, for instance, is also a domain. So, for instance, www.microsoft.com could open a window and show you a file on your hard drive. However, because your local file system is in a different domain from the web site, the cross-domain security model should prevent the web site from reading the file that is being displayed.
The Internet Explorer domain security model can be configured using the Internet Security Zones settings in Internet Explorer.

What are Internet Explorer security zones? 
Internet Explorer Security Zones are a system that divides online content into categories, or zones based on its trustworthiness. Specific web domains can be assigned to a zone, depending on how much trust is placed in the content of each domain. The zone then restricts the capabilities of the web content, based on the zone's settings.
By default, most Internet domains are treated as part of the Internet zone, which has settings that prevent scripts and other active code from accessing resources on the local machine. Conversely, the Local Computer zone is a much less restricted zone which allows content to access and manipulate content on the local system. By default, files stored on the local computer are run in the Local Computer zone.

What's wrong with the way Internet Explorer calculates cross domain security? 
Internet Explorer evaluates security when one web page requests access to resources in another security zone. However there are three flaws in how the security is calculated when three different programming functions are used and as a result an attacker can bypass the security checks. Whilst these flaws are all subtly different, the effects are the same.

What could these vulnerabilities enable an attacker to do? 
An attacker could use these vulnerabilities to create a web page that would allow the attacker to access data across different domains. This could include reading files on the local system that can are not in use by the user or the operating system, provided the attacker knew the full path and file name. It could also include accessing any data that a user chose to share with another web site. An attacker could also invoke executables on the user's local file system or to load a malicious executable on the user's system.

How could an attacker exploit these vulnerabilities? 
An attacker could seek to exploit these vulnerabilities by creating a malicious web page and then enticing the user to visit this page. When the user visited the page the attacker could cause a second browser to open on another web site and the attacker would now have the same access to the second web page that the user had. The attacker could also create a web page that when viewed by the user, would launch an executable file that was already on the user's local system.

Could an attacker use these vulnerabilities to load a program on my machine from their web site or server? 
Yes. However Microsoft has published a Knowledge Base Article, 810687, which describes a registry key setting that restricts shortcuts in HTML Help. Setting this registry key would remove the ability of an attacker to load a malicious executable onto the user's system and would restrict the attacker to invoking an executable that's already present on the user's system.

What does the patch do? 
The patch addresses the vulnerabilities by ensuring that the correct cross domain security checks take place whenever the affected programming functions are used.

Download locations for this patch

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