• Article

Security Bulletin

Microsoft Security Bulletin MS02-050 - Important

Certificate Validation Flaw Could Enable Identity Spoofing (Q329115)

Published: September 04, 2002 | Updated: November 11, 2003

Version: 5.0

Originally posted: September 04, 2002

Updated: November 11, 2003

Summary

Who should read this bulletin: Customers using Microsoft® Windows®, Office for Mac, Internet Explorer for Mac, or Outlook Express for Mac.

Impact of vulnerability: Identity spoofing and, in some cases, ability to gain control over a user's system.

Maximum Severity Rating: Important

Recommendation: Customers should install the updated version of the patch immediately, where necessary.

Affected Software:

  • Microsoft Windows 98
  • Microsoft Windows 98 Second Edition
  • Microsoft Windows Me
  • Microsoft Windows NT® 4.0
  • Microsoft Windows NT 4.0, Terminal Server Edition
  • Microsoft Windows 2000
  • Microsoft Windows XP
  • Microsoft Office for Mac
  • Microsoft Internet Explorer for Mac
  • Microsoft Outlook Express for Mac

General Information

Technical details

Technical description:

The original version of this bulletin was released on 05 September 2002.

Microsoft re-issued this security bulletin on November 11, 2003 to advise on the availability of an updated Microsoft Windows 2000 Service Pack 4 (SP4) security patch. This revised security patch corrects a regression that may occur during the installation of Microsoft Internet Explorer 6.0 Service Pack 1 on Windows 2000 SP4. This regression removes the update that is discussed in this bulletin and that is provided as part of Windows 2000 SP4. Customers who are using Windows 2000 SP4 and then installed Internet Explorer 6.0 Service Pack 1 should apply the updated Windows 2000 SP4 security patch to help protect from this vulnerability.

On 09 September 2002, we updated the bulletin to advise customers that a Microsoft-issued digital certificate, used to sign device drivers, did not meet the stricter validation standards established by the patch. As a result, customers who installed the patch could see unexpected error messages when installing new hardware, or in some cases might be unable to install new hardware altogether. On 20 November 2002, we released an updated version of the patch that not only eliminates this problem, but also eliminates a newly discovered variant of the original vulnerability.

The IETF Profile of the X.509 certificate standard defines several optional fields that can be included in a digital certificate. One of these is the Basic Constraints field, which indicates the maximum allowable length of the certificate's chain and whether the certificate is a Certificate Authority or an end-entity certificate. However, the APIs within CryptoAPI that construct and validate certificate chains (CertGetCertificateChain(), CertVerifyCertificateChainPolicy(), and WinVerifyTrust()) do not check the Basic Constraints field. The same flaw, unrelated to CryptoAPI, is also present in several Microsoft products for Macintosh.

The vulnerability identified in the original version of the bulletin could enable an attacker who had a valid end-entity certificate to issue a subordinate certificate that, although bogus, would nevertheless pass validation. Because CryptoAPI is used by a wide range of applications, this could enable a variety of identity spoofing attacks. These are discussed in detail in the FAQ, but could include:

  • Setting up a web site that poses as a different web site, and "proving" its identity by establishing an SSL session as the legitimate web site.
  • Sending emails signed using a digital certificate that purportedly belongs to a different user.
  • Spoofing certificate-based authentication systems to gain entry as a highly privileged user.
  • Digitally signing malware using an Authenticode certificate that claims to have been issued to a company users might trust.

The newly discovered vulnerability announced on 20 November 2002 is closely related to the one discussed in the original version of the bulletin and, like that vulnerability, involves a flaw in the way certificate validation is performed. However, this vulnerability could enable an attacker to gain control over a user's system. Because a fix for this vulnerability was not included in the original version of the patch, Microsoft strongly recommends that customers install the new patch, even if they installed the original version of the patch. Only Microsoft Windows 98, Windows 98 Second Edition, Windows NT 4.0, and Windows NT 4.0, Terminal Server Edition are affected by this variant.

Mitigating factors:

Overall:

  • The user could always manually check a certificate chain, and might notice in the case of a spoofed chain that there was an unfamiliar intermediate CA.
  • Unless the attacker's digital certificate were issued by a CA in the user's trust list, the certificate would generate a warning when validated.
  • The attacker could only spoof certificates of the same type as the one he or she possessed. In the case where the attacker attempted an attack using a high-value certificate such as Authenticode certificates, this would necessitate obtaining a legitimate certificate of the same type - which could require the attacker to prove his or her identity or entitlement to the issuing CA.

Web Site Spoofing:

  • The vulnerability provides no way for the attacker to cause the user to visit the attacker's web site. The attacker would need to redirect the user to a site under the attacker's control using a method such as DNS poisoning. As discussed in the FAQ, this is extremely difficult to carry out in practice.
  • The vulnerability could not be used to extract information from the user's computer. The vulnerability could only be used by an attacker as a means of convincing a user that he or she has reached a trusted site, in the hope of persuading the user to voluntarily provide sensitive data.

Email Signing:

  • The "from" address on the spoofed mail would need to match the one specified in the certificate, giving rise to either of two scenarios if a recipient replied to the mail. In the case where the "from" and "reply-to" fields matched, replies would be sent to victim of the attack rather than the attacker. In the case where the fields didn't match, replies would obviously be addressed to someone other than ostensible sender. Either case could be a tip-off that an attack was underway.

Certificate-based Authentication:

  • In most cases where certificates are used for user authentication, additional information contained within the certificate is necessary to complete the authentication. The type and format of such data typically varies with every installation, and as a result significant insider information would likely be required for a successful attack.

Authenticode Spoofing:

  • To the best of Microsoft's knowledge, such an attack could not be carried out using any commercial CA's Authenticode certificates. These certificates contain policy information that causes the Basic Constraints field to be correctly evaluated, and none allow end-entity certificates to act as CAs.
  • Even if an attack were successfully carried out using an Authenticode certificate that had been issued by a corporate PKI, it wouldn't be possible to avoid warning messages, as trust in Authenticode is brokered on a per-certificate, not per-name, basis.

Severity Rating:

Original Vulnerability New Variant
Windows 98 Important Important
Windows 98 Second Edition Important Important
Windows Me Important None
Windows NT 4.0 Important Important
Windows NT 4.0, Terminal Server Edition Important Important
Windows 2000 Professional Important None
Windows 2000 Server Important None
Windows 2000 Advanced Server Important None
Windows XP Important None
Microsoft Office for Mac Moderate None
Microsoft Internet Explorer for Mac Moderate None
Microsoft Outlook Express for Mac Moderate None

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. The severity for the Windows products is higher because the vulnerability lies within CryptoAPI and therefore affects many applications and functions. The severity for the Mac products is lower since they use certificates only for SSL.

Note: Responding to customer feedback, Microsoft updated its severity rating system November 18, 2002. Security bulletins that originally posted under the old system - before November 18, 2002 - and are later re-released under the new system, will reflect the severity rating assessed under the new revised system Severity Rating criteria.

Vulnerability identifiers:

Tested Versions:

Microsoft tested the following products to assess whether they are affected by this vulnerability.

  • Microsoft Windows 98
  • Microsoft Windows 98 Second Edition
  • Microsoft Windows Me
  • Microsoft Windows NT 4.0
  • Microsoft Windows NT 4.0, Terminal Server Edition
  • Microsoft Windows 2000
  • Microsoft Windows XP
  • Microsoft Office v.X for Mac
  • Microsoft Office 2001 for Mac
  • Microsoft Office 98 for the Macintosh
  • Microsoft Internet Explorer for Mac (for Mac OS 8.1 to 9.x)
  • Microsoft Internet Explorer for Mac (for OS X)
  • Microsoft Outlook Express 5.0.5 for Mac

Previous versions are no longer supported, and may or may not be affected by this vulnerability.

Frequently asked questions

This bulletin has been revised several times since its release. Why?
The bulletin has been revised frequently since its original release. Most of these revisions announced the availability of patches for additional platforms or corrected minor errors. However, several versions were particular significant:

  • The original version of the bulletin, released on 04 September 2002. This version of the bulletin discussed the original vulnerability and the availability of patches.
  • Version 3.0 of the bulletin, released on 09 September 2002. This version discussed a side effect associated with installing hardware devices on systems that had been patched.
  • Version 4.0 of the bulletin, released on 20 November 2002. This version announced an updated version of the patch that not only eliminates the side effect associated with the original patch, but also eliminates an additional vulnerability affecting Windows NT 4.0 and Windows 98 and associated with the way digital certificates are handled.
  • Version 5.0 of the bulletin, released on 11 November 2003. This version announced an updated Microsoft Windows 2000 Service Pack 4 (SP4) security patch. This revised patch corrects a regression that may occur during the installation of Microsoft Internet Explorer 6.0 Service Pack 1 on systems using Windows 2000 Service Pack (SP4). This regression removes the update that is discussed in this bulletin and that is provided as part of Windows 2000 SP4. Customers who use Windows 2000 SP4 and then installed Internet Explorer 6.0 Service Pack 1 should apply the updated Windows 2000 SP4 security patch to help protect from this vulnerability.

What was the side effect associated with the original version of the patch?
By design, the patch institutes more stringent standards for determining the validity of digital certificates. However, shortly after releasing the patch, we discovered that a Microsoft-issued digital certificate doesn't pass the new standards. This certificate is used to certify that hardware devices such as disk drives, networking cards, modems, and so forth have been tested for compatibility with Windows. This posed a problem in scenarios where customers installed new hardware on patched systems. Because the certificate couldn't pass the new standards, Windows would display a dialog incorrectly telling the user that the hardware hadn't been tested for compatibility with Windows. In most - but not all - cases, the user could direct Windows to install the hardware anyway.

What does the November 20, 2002 version of the patch do?
Versions of the patch released on or after November 20, 2002 correct the problem with the Microsoft digital certificate, thereby addressing the side effect. But they do more than that. Microsoft has learned of an additional security vulnerability related to the one discussed below but affecting only Windows NT 4.0 and Windows 98, and has included fix for it in the updated patch.

I installed the original version of the patch. Should I install the version of the patch released on November 20, 2002?
Yes. The fix for the side effect should be enough in its own right to warrant installing the updated version. But for Windows NT 4.0 and Windows 98 users, the discovery of the new security vulnerability makes it doubly important that all customers install the updated patch.

I have not installed Windows 2000 Service Pack 4 and then installed Internet Explorer 6.0 Service Pack 1 do I need to install the updated Windows 2000 Service Pack 4 version of the security patch released on November 11, 2003?
No. The updated version of the patch released on November 11, 2003 only applies to customers who are using Windows 2000 Service Pack 4 and then installed Internet Explorer 6.0 Service Pack 1. Only those customers should apply the updated Windows 2000 Service Pack 4 security patch to help protect themselves from this vulnerability.

The Q number for the updated patch is different from that of the original. Why?
To make it easy for customers to confirm that they're installing the updated version of the patch, we've changed the Q number. The Q number of the original patch was Q328145; that of the new one is Q329115.

What's the scope of the original vulnerability?
This vulnerability could enable an attacker to craft a digital certificate that, although bogus, would nevertheless be accepted as bona fide. Digital certificates are used for a variety of security-related purposes - for instance, users use them to confirm that web sites' identities; to verify who the sender of an email was; whether it's safe to run particular programs, and other purposes - and the ability to forge a seemingly valid certificate could allow a variety of attacks. In many cases, the specific policies followed by the companies that issue digital certificates mitigate the risk posed by the vulnerability. These policies could make it difficult or impossible to successfully exploit the vulnerability, and in some cases could make it easier to determine who carried out a particular attack. Also, it is worth noting that it would always be possible for a user to examine a digital certificate and see telltale signs of an attempt to exploit the vulnerability.

What causes the vulnerability?
The vulnerability occurs because of flaws in the way the affected products evaluate the Basic Constraints field when validating a digital certificate. These flaws could enable an attacker to act as a Certificate Authority and create subordinate certificates with any desired information, which the affected products would accept as valid.

What is a digital certificate?
Digital certificates are a familiar fixture within public-key cryptography. In public-key cryptography, there are two keys: the private key, which must be kept secret, and the public key, which is intended to be shared with the world. In order for the public key to be shared effectively, there needs to be a way to learn whose it is, how it can be used, and to verify that the information is bona fide. Digital certificates provide a way to do this. A digital certificate combines a public key with information about it - who owns it, what purposes it can be used for, when it expires, and so forth. When a user needs a digital certificate, he or she gets it from an organization known as a Certificate Authority (CA). The CA not only creates the certificate, it also digitally signs it, thereby vouching for the information in it and preventing it from being modified without detection.

What are digital certificates used for?
Here's a sampling of some applications that use digital certificates:

  • Web sessions. Web sites frequently use the Secure Sockets Layer protocol, which allows a web site to prove to visitors that it is the one it purports to be, and to provide encryption for the resulting web session.
  • Email. Many email clients support S/MIME, a protocol that uses digital certificates to prove the origination point and authenticity of an email.
  • Code signing. Microsoft platforms support Authenticode, a technology that lets software developers digitally sign their programs in order to prove their authorship and to show that the programs have not been modified.
  • Networking sessions. Many companies use IPSEC to protect network sessions by encrypting them and enabling the participants to know with certainty who they are communicating with.

How is the functionality implemented to support digital certificates?
Applications implement support for digital certificates in either of two ways. Those that run under Windows typically make use of CryptoAPI, a set of functions built into Windows that provide support for encryption, decryption, digital certificate handling, and other tasks. Those that run under other operating systems typically must implement cryptographic functions locally - that is, within the applications themselves.

Does the vulnerability in this case lie in CryptoAPI or in local implementations within particular products?
Both. The CryptoAPI implementation is affected by the vulnerability, and therefore affects all applications - whether written by Microsoft or a third party - that use it. But several Microsoft applications that run on the Macintosh (and therefore provide their own cryptographic implementations) contain the same vulnerability.

What's wrong with how digital certificates are validated in the affected products?
The vulnerability results because the affected products don't check a particular field - known as Basic Constraints - when validating a digital certificate. As we discussed above, one of the purposes of a digital certificate is to allow the CA that issued it to regulate how it can be used. The Basic Constraints field is one way through which this is done. The Basic Constraints field allows the CA to indicate two important pieces of information: whether the certificate is authorized to act as a CA in its own right (and thereby issue additional, subordinate certificates), and how long the resulting chain of certificates can be. The affected products don't check this field and therefore don't apply any of the constraints that it may indicate.

Why does this pose a security vulnerability?
As we discussed above, when a CA issues a digital certificate, it vouches for the authenticity of the certificate and the identity of the owner. The flaw poses a security vulnerability because, in essence, it could allow an attacker who has been issued a digital certificate to successfully claim that the CA has delegated to him the ability to issue additional certificates. The attacker's assertions about the validity of those certificates would carry the same force as if they had been made by the CA itself.

What would this vulnerability enable an attacker to do?
The vulnerability could enable an attacker to create bogus a digital certificate that would nevertheless pass validation. Depending on the usage, this could enable a variety of attacks, such as:

  • Creating a web site that could successfully pose as a different web site, in the hope that visitors would provide sensitive information to it.
  • Sending an email whose digital signature would attest that it was sent by someone other than the actual sender.
  • Posing as another user by providing a bogus digital certificate as authentication.
  • Digitally signing a dangerous program in the guise of a trustworthy user or company, in order to convince a user that it was safe to run it.

It's important to understand that each of these scenarios would be subject to operational barriers of varying degrees. We'll discuss each scenario in detail below, but it's worth listing three obstacles that would be common to all of these scenarios.

  • The attacker's digital certificate would need to be issued by a CA that the user trusted. The attacker's point in exploiting the vulnerability would be to create a bogus certificate that generated no warning messages, but if the CA that issued the attacker's certificate weren't trusted, that fact in itself would generate a warning.
  • The bogus certificate would be limited to the same usage as the attacker's. This means that, in order to create a bogus SSL server certificate, the attacker would need a valid SSL server certificate; in order to create a bogus Authenticode certificate, the attacker would need a valid Authenticode certificate, and so forth. In some cases, obtaining a valid certificate could require that the attacker provide proof of identity that could later be used by law enforcement.
  • The user could always determine the truth. Every Microsoft application that uses digital certificates provides a way to view the certificate. A user who did so might notice that the certificate chain was unusual, in that the issuer of the certificate was an unfamiliar name and didn't appear to be affiliated with the CA.

How might an attacker use the vulnerability to spoof a trusted web site?
The attacker would likely select an e-commerce site that users would be likely to trust, set up a web site that purported to be the legitimate e-commerce site, then create a bogus SSL server certificate bolstering that claim. If a user visited the attacker's site, the certificate would allow it to set up a valid SSL session, "confirming" that it was indeed the legitimate e-commerce site. The user might then choose to provide sensitive information such as credit card numbers to the attacker's site. The chief obstacle this scenario would pose is that the vulnerability provides no way to make the user actually arrive at the attacker's site, let alone in the belief that it is a different site. Doing this would likely require that the attacker be able to modify the Internet infrastructure that the user transited, via a technique such as DNS cache poisoning. However, such techniques are difficult, temporary, and generally require favorable network topology.

How might an attacker use the vulnerability to spoof digitally signed emails?
The attacker would create a bogus email signing certificate that purportedly belonged to a different user, then use it to digitally sign an email. The recipient might conclude, based on the signature, that the mail was valid. The primary problem with this scenario is that, in order for the signature to be validated, the "from" address on the email would need to match the one cited on the certificate. That is, an attacker who wanted to sign mail as Bob would need to create a certificate with Bob's email address on it, and use Bob's address as the "from" address on the email. In most cases, replying to the mail would cause it to be delivered to Bob - not the attacker - and Bob would know that someone was spoofing his signature. The attacker could manipulate the mail fields so that replies wouldn't be sent to Bob, but that in itself would be a tipoff that something was afoot. In either case, it would be relatively simple for the recipient to provide Bob with a copy of the attacker's bogus certificate, which Bob could then have revoked or turn over to law enforcement.

How might an attacker use the vulnerability to spoof certificate-based authentication?
This scenario would apply to fairly atypical cases, such as one in which mutually authenticating SSL sessions are used to broker access to network resources. To carry out an attack against such a system, the attacker would generate a bogus certificate in the name of another user - presumably, an administrator or other privileged user - then use the certificate to authenticate as that user, thereby gaining the other user's privileges. There are two chief obstacles to this attack. First, scenarios like this one typically are found within corporate networks where public key infrastructures have been deployed. In such a case, the attacker couldn't simply buy a certificate from a commercial CA. Instead, he or she would need to obtain one from the company's local CA, which likely would require the attacker to already be a legitimate network user. Second, systems such as these typically arbitrate user privileges using data stored by the CA within the certificate. Determining the right data, and the right format, could require significant insider knowledge.

How might an attacker user the vulnerability to spoof an Authenticode signature?
To describe just one scenario, the attacker might create an ActiveX control that performs some malicious task, then create an Authenticode digital certificate purporting to belong to a widely trusted company. After using the bogus certificate to digitally sign the control, the attacker could host the control on a web site that he or she controlled, and attempt to run it whenever a user visited the site. The problem for the attacker in this scenario is that, to the best of Microsoft's knowledge, no commercial CA's Authenticode certificates could be used in such an attack. The reason is because these CAs include policy information within their certificates, the effect of which is to cause CryptoAPI to re-examine - and correctly process - the Basic Constraints field. In every case, the Basic Constraints information within these certificates disallows using them to issue additional certificates. As a result, this scenario would likely be limited to cases in which a company had deployed a public key infrastructure, issued Authenticode certificates that are not as well-formed as those of the commercial CAs, and had issued one to the attacker. Even if there were a commercial CA that did issue certificates suitable for use in such an attack, the user would still see a warning message. Internet Explorer brokers trust on a certificate-by-certificate basis, not on a name-by-name basis. That is, if two certificates had exactly the same name, and the user agreed to trust the first one, Internet Explorer would still generate a warning when the second certificate was encountered.

I'm running Windows. Do I need to apply a patch for every application I'm running?
No. You just need to apply the patch for the version of Windows you're using. Applying the patch eliminates the vulnerability in CryptoAPI, thereby also making safe any applications that use it.

I'm running several of the Microsoft products for Macintosh that you listed above. Do I need to apply a patch for each one?
Yes. Macintosh doesn't supply a corollary to CryptoAPI, so every application must implement its own cryptography. Consequently, there's a separate patch for each of the Microsoft products for Macintosh listed in the Affected Products listing.

I'm a developer, and one of my products uses CryptoAPI. Do I need to do anything?
No. When the patch is applied to a system, it eliminates the problem in CryptoAPI itself, thereby also eliminating the problem in any applications that rely upon it for cryptographic services.

How does the patch address the vulnerability?
The patch ensures that intermediate certificates are not treated as a certificate authority unless the Basic Constraint extension is present with the value of CA set to TRUE. Additionally, the patch ensures that if a KeyUsage extension is present in a certificate purposed to be a certificate authority, it must contain a value for keyCertSign which defines (or restricts) the usage of the key contained in the certificate.

What's the scope of the new variant of the vulnerability?
This vulnerability could enable an attacker to gain complete control over a user's machine. This would enable the attacker to take any action the legitimate user could take, including running programs, communicating with web sites, reformatting the hard drive, and so forth.

How is this vulnerability related to the original vulnerability?
It's closely related. Both involve flaws in the way digital certificates are validated and used. The chief difference lies in what they could allow an attacker to do, and the fact that the new vulnerability only affects Windows NT 4.0 and Windows 98.

If this is just another vulnerability associated with certificate validation, why are you discussing it specially?
Microsoft learned of the vulnerability shortly after releasing the original version of the patch, and determined that, despite its similarities to the preceding one, it was not eliminated by the original patch. We're discussing it separately to ensure that customers understand the necessity of installing the new version of the patch.

Which of the Microsoft Windows operating system are affected by the newly discovered variant?
The Windows operating systems affected by the newly discovered variant are:

  • Microsoft Windows 98
  • Microsoft Windows 98 Second Edition
  • Microsoft Windows NT 4.0
  • Microsoft Windows NT 4.0, Terminal Server Edition

I'm running one of the products for Mac, should I re-apply the patch?
No. The products for Mac are not affected by the new variant. If you have already applied the patch for a Mac product, you do not need to re-apply.

Are there any differences in the attack scenarios between the original and new variants?
No. The attack scenarios are very similar.

Patch availability

Download locations for this patch

Additional information about this patch

Installation platforms:

  • For the Windows platforms, a supported version of Internet Explorer is required.
  • The patch for Windows 98 can be installed on systems running Windows 98 Gold.
  • The patch for Windows 98 Second Edition can be installed on system running Windows 98 Second Edition Gold.
  • The patch for Windows Millennium can be installed on systems running Windows Millennium Gold.
  • The patch for Windows NT 4.0 can be installed on systems running Windows NT 4.0 Service Pack 6a.
  • The patch for Windows NT 4.0, Terminal Server Edition, can be installed on systems running Windows NT 4.0, Terminal Server Edition Service Pack 6.
  • The patch for Windows 2000 can be installed on systems running Windows 2000 Service Pack 2 or Service Pack 3.
  • The patch for Windows XP can be installed on systems running Windows XP Gold and the forthcoming Windows XP Service Pack 1.
  • The patch for Microsoft Office v.X for Mac can be installed on systems running Mac OS X version 10.1 or later.
  • The patch for Microsoft Office 2001 for Mac can be installed on systems running Mac OS 8.1 or later.
  • The patch for Microsoft Office 98 for the Macintosh can be installed on systems running Mac OS 8.1 or later.
  • The patch for Microsoft Internet Explorer for Mac (for Mac OS 8.1 to 9.x) can be installed on systems running Mac OS 8.1 or later.
  • The patch for Microsoft Internet Explorer for Mac (for Mac OS X) can be installed on systems running Mac OS X version 10.1 or later.

Inclusion in future service packs:

The fix for this issue will be included in Windows 2000 Service Pack 4 and Windows XP Service Pack 2.

Reboot needed:

  • Microsoft Windows 98: Yes
  • Microsoft Windows 98 Second Edition: Yes
  • Microsoft Windows Me: Yes
  • Microsoft Windows NT 4.0: Yes
  • Microsoft Windows NT 4.0, Terminal Server Edition: Yes
  • Microsoft Windows 2000: Yes
  • Microsoft Windows XP: Yes
  • Microsoft Office for Mac: No
  • Microsoft Internet Explorer for Mac: No
  • Microsoft Outlook Express for Mac: No

Patch can be uninstalled:

  • Microsoft Windows 98: No
  • Microsoft Windows 98 Second Edition: No
  • Microsoft Windows Me: No
  • Microsoft Windows NT 4.0: Yes
  • Microsoft Windows NT 4.0, Terminal Server Edition: Yes
  • Microsoft Windows 2000: Yes
  • Microsoft Windows XP: Yes
  • Microsoft Office for Mac: No
  • Microsoft Internet Explorer for Mac: No
  • Microsoft Outlook Express for Mac: No

Superseded patches: None.

Verifying patch installation:

Windows 98, Windows 98 Second Edition, and Windows Me:

  • To verify that the patch has been installed on the machine, use the Qfecheck.exe tool and confirm that the display includes the following information: "Windows XX Q329115 Update" where XX is "98" for Windows 98 or Windows 98 Second Edition, or "Millennium Edition" for Windows Me.
  • To verify the individual files, consult the file manifest in Knowledge Base article Q329115.

Windows NT 4.0:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q329115.

  • To verify the individual files, consult the file manifest in Knowledge Base article Q329115.

Windows NT 4.0, Terminal Server Edition:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Q329115.

  • To verify the individual files, consult the file manifest in Knowledge Base article Q329115.

Windows 2000:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q329115.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q329115\Filelist

Windows XP:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKLM\Software\Microsoft\Updates\Windows XP\SP2\Q329115.

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKLM\Software\Microsoft\Updates\Windows XP\SP2\Q329115\Filelist

Caveats:

Customers who have first installed this security patch and then upgraded their system to Internet Explorer Service Pack 1 will need to reapply the patch either by visiting the download link provided, or obtaining the fix via Windows Update.

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 the UK National Infrastructure Security Co-ordination Centre (NISCC) for reporting the newly discovered variant and working with us to protect customers.

Support:

  • Microsoft Knowledge Base article Q329115 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 (September 04, 2002): Bulletin Created.
  • V2.0 (September 05, 2002): Bulletin updated to include patch availability for Windows 98, Windows 98 Second Edition, and Windows Me.
  • V2.1 (September 05, 2002): Bulletin updated to provide link to single download page for all Windows XP patches.
  • V2.2 (September 05, 2002): Bulletin updated to give correct reference to XP download locations for supported languages.
  • V3.0 (September 09, 2002): Bulletin updated to advise customers of the availability of a Windows 2000 version of the patch, and to include information in the Caveats section.
  • V3.1 (September 18, 2002): Bulletin updated to change Windows Me download link.
  • V3.2 (September 20, 2002): Installation platforms section updated to indicate that a supported version of Internet Explorer is required on Windows platforms.
  • V3.3 (October 17, 2002): Bulletin updated to advise customers of the availability of the Mac patches.
  • V4.0 (November 20, 2002): Bulletin updated to advise of the availability of updated patches that eliminate the caveat discussed in V3.0 of the bulletin as well as a new variant of the vulnerability.
  • V4.1 (February 28, 2003): Bulletin updated to advise that customers who have first installed this security patch and then upgraded their system to Internet Explorer 6.0 Service Pack 1 will need to reapply the patch.
  • V4.2 (July 24, 2003): Updated Mac download links.
  • V5.0 (November 11,2003): Bulletin updated to advise on the availability of a new security patch for customers who installed Windows 2000 Service Pack 4 and then installed Internet Explorer 6.0 Service Pack 1.

Built at 2014-04-18T13:49:36Z-07:00 </https:>