Who should read this bulletin: Customers using Microsoft« Internet Explorer

Microsoft Security Bulletin MS02-066

Cumulative Patch for Internet Explorer (Q328970)

Originally posted: November 20, 2002

Summary

Who should read this bulletin: Customers using Microsoft« Internet Explorer
Impact of vulnerability: Six new vulnerabilities, the most serious of which could enable an attacker to execute commands on a userÆs system.
Maximum Severity Rating: Important
Recommendation: Customers should install the patch at the earliest opportunity.
Affected Software:

Microsoft Internet Explorer 5.01
Microsoft Internet Explorer 5.5
Microsoft Internet Explorer 6.0

End User Bulletin: An end user version of this bulletin is available at: http://www.microsoft.com/security/security_bulletins/ms02-066.asp

Technical details

Technical description:

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. To the best of MicrosoftÆs knowledge, this vulnerability could only be used to cause Internet Explorer to fail. The effect of exploiting the vulnerability against Internet Explorer would be relatively minor û the user would only need to restart the browser to restore normal operation. However, 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 would cause them to fail 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 Failure, 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

Internet Explorer and other affected applications such as Microsoft Office and Microsoft Index Server could be successfully restarted after the failure.
Microsoft has not identified a method by which this buffer overrun can be used to execute code of the attackerÆs choice on the userÆs system.
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:

Internet Explorer 5.01 Internet Explorer 5.5 Internet Explorer 6.0 Gold Internet Explorer 6.0 SP1

Malformed PNG Image File Failure Important Important Important None

Encoded Characters Information Disclosure Moderate Moderate Moderate Moderate

Frames Cross Site Scripting Important Important Important Important

Temporary Internet Files folders Name Reading Low Low Low None

Cross Domain Verification via Cached Methods None Important Important Important

Improper Cross Domain Security Validation with Frames None Important Important None

Aggregate Severity of all issues included in this patch Important Important Important Important

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://microsoft.com/windows/lifecycle/desktop/consumer/components.mspx

Frequently asked questions

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.

Patch availability

Download locations for this patch
http://www.microsoft.com/windows/ie/downloads/critical/q328970/default.asp

Additional information about this patch

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

Other information:

Acknowledgments
Microsoft thanks eEye Digital Security for reporting the malformed PNG issue to us and working with us to protect customers.
Support:

Microsoft Knowledge Base article Q328970 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
Disclaimer:
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.
Revisions:

V1.0 (November 20, 2002): Bulletin Created.
V1.1 (November 25, 2002): Add information about Microsoft Knowledge Base Article 810687