Microsoft Security Bulletin MS02-066

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 the user’s Internet Explorer to fail.
• 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 File Failure(CAN-2002-1185):

What’s the scope of the first vulnerability?

This is a buffer overrun vulnerability could cause Internet Explorer to fail as a result of viewing a malformed PNG image file. Internet Explorer could be successfully restarted after the failure.

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 temporarily. Internet Explorer could successfully be restarted by the user after this failure.

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 would result in its failure, and the user would need to restart it in order to resume normal operation.

Buffer overruns often allow an attacker to gain control over a system. Is this the case with this vulnerability?

This can be the case with some, but not all buffer overruns. In this case, Microsoft has investigated the buffer overrun and has not been identified any method of exploiting it to allow an attacker to run arbitrary code and therefore gain control of the system.

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.

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 everytime 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 susequently 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 paramters 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 aregistry 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.

Installation platforms:

• The IE 5.01 patch can be applied to Windows 2000 Systems with Service Pack 3 running IE 5.01
• The IE 5.5 patch can be installed on systems running Service Pack 2.
• The IE 6.0 patch can be installed on system running IE 6.0 Gold or IE 6.0 Service Pack 1.

Inclusion in future service packs:

• The fixes for the issues affecting Internet Explorer 6.0 will be included in Internet Explorer 6.0 Service Pack 2.
• The fixes for the issues affecting Internet Explorer 5.01 Service Pack 2 and Service Pack 3 will be included in Windows 2000 Service Pack 4.

Reboot needed: Yes

Patch can be uninstalled: No

Superseded patches: This patch supersedes the one provided in Microsoft Security Bulletin MS02-047, which is itself a cumulative patch.

Verifying patch installation:

• To verify that the patch has been installed on the machine, open IE, select Help, then select About Internet Explorer and confirm that Q328970 is listed in the Update Versions field.
• To verify the individual files, use the patch manifest provided in Knowledge Base article Q328970.

Caveats:
None

Localization:
Localized versions of this patch are available at the locations discussed in "Patch Availability".

Obtaining other security patches:
Patches for other security issues are available from the following locations:

• Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
• Patches for consumer platforms are available from the WindowsUpdate web site