Microsoft Security Bulletin MS02-048
Flaw in Certificate Enrollment Control Could Allow Deletion of Digital Certificates (Q323172)
Originally posted: August 28, 2002
Who should read this bulletin:
Customers using Microsoft® Windows® 98, Windows 98 Second Edition, Windows Millennium, Windows NT® 4.0, Windows 2000, or Windows XP.
Impact of vulnerability:
Denial of service
Maximum Severity Rating:
Customers should install the patch immediately
- Microsoft Windows 98
- Microsoft Windows 98 Second Edition
- Microsoft Windows Millennium
- Microsoft Windows NT 4.0
- Microsoft Windows 2000
- Microsoft Windows XP
All versions of Windows ship with an ActiveX control known as the Certificate Enrollment Control, the purpose of which is to allow web-based certificate enrollments. The control is used to submit PKCS #10 compliant certificate requests, and upon receiving the requested certificate, stores it in the user's local certificate store.
The control contains a flaw that could enable a web page, through an extremely complex process, to invoke the control in a way that would delete certificates on a user's system. An attacker who successfully exploited the vulnerability could corrupt trusted root certificates, EFS encryption certificates, email signing certificates, and any other certificates on the system, thereby preventing the user from using these features.
An attack could be carried out through either of two scenarios. The attacker could create a web page that exploits the vulnerability, and host it on a web site in order to attack users who visited the site. The attacker also could send the page as an HTML mail in order to attack the recipient.
A new version of the control is available that corrects the vulnerability, and can be installed via the patch. A patch is available for all other Windows systems, as discussed in the Patch Availability section below. Internet Explorer 5 or later is a prerequisite to installing the patch. As discussed in the Caveats section, customers who operate web sites that use the Certificate Enrollment Control will need to make minor revisions to their web applications in order to use the new control. Microsoft Knowledge Base article Q323172 details how to do this.
In addition, the patch addresses a similar, but less serious vulnerability discovered in the SmartCard Enrollment control. This control ships with Windows 2000 and Windows XP. A new version of this control is also provided.
- The web site-based attack vector could not be exploited if ActiveX controls were disabled in the Security Zone associated with the attacker's site.
- The mail-based attack vector could not be exploited if the recipient's email client handles HTML mail in the Restricted Sites Zone. Outlook Express 6 and Outlook 2002 open mail in this zone by default. Outlook 98 and 2000 open HTML mail in the Restricted Sites Zone if the Outlook Email Security Update has been installed.
- The vulnerability would not enable certificates on smart cards to be corrupted, even if the smart card were in the system at the time of an attack.
|Internet Servers||Intranet Servers||Client Systems|
|All affected products||Low||Low||Critical|
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 identifier: CAN-2002-0699
Microsoft tested Windows 98, Windows 98 Second Edition, Windows Millennium, Windows NT 4.0, Windows 2000, and Windows XP to assess whether they are affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.
What's the scope of the vulnerability?
This is a denial of service vulnerability. Through this vulnerability, an attacker could potentially delete digital certificates on a user's system, thereby preventing the user from having access to certain functions. (The specific functions would depend on exactly how the system was being used).
The vulnerability could be exploited via either a web site or email. However, it is possible to configure Internet Explorer to defend against the web site-based attack. Likewise, an email-based attack could not be carried out against customers who are using Outlook Express 6 or Outlook 2002 in their default settings, or Outlook 98 or 2000 in conjunction with the Outlook Email Security Update.
What causes the vulnerability?
The vulnerability results because a flaw in the Windows Certificate Enrollment Control could make it possible for an attacker to delete digital certificates in a user's certificate store.
What is a digital certificate?
To answer that question, we first need to discuss cryptography - in particular, public key cryptography. Cryptography is the science of securing information by converting it between its normal, readable state (called plaintext) and one in which the data is obscured (known as ciphertext). In all forms of cryptography, a value known as a key is used in conjunction with a procedure called a cryptoalgorithm to transform plaintext data into ciphertext. In the most familiar type of cryptography, secret-key cryptography, the ciphertext is transformed back into plaintext using the same key.
However, in a second type of cryptography, public key cryptography, a different key is used to transform the ciphertext back into plaintext. One of these keys, known as the private key, must be kept secret. The other key, known as the public key, is intended to be shared with the world. However, there must be a way for the owner of the key to tell the world who the key belongs to. Digital certificates provide a way to do this. A digital certificate is a tamperproof piece of data that packages a public key together with information about it - who owns it, what it can be used for, when it expires, and so forth.
What can a digital certificate be used for?
A digital certificate (or more properly, a key pair, the public key from which is packaged in a digital certificate) can be used in either of two ways. If people use the public key (the one encapsulated in a digital certificate) to encrypt data, only the person who holds the corresponding private key will be able to read it; this enables the data to be kept confidential.
On the other hand, if the owner of the private key uses it to encrypt data, anyone will be able to decrypt it using the corresponding public key. This process doesn't provide confidentiality (since anyone can access the public key and decrypt the message), but it does provide two other capabilities:
- Proof of origin. If the data could be decrypted using the public key, it must have been encrypted using the corresponding private key - and the digital certificate says who owns the private key.
- Authenticity. If someone modified the encrypted data while it was in transit, the recipient wouldn't be able to decrypt it, even using the public key. The fact that the data can be successfully decrypted shows that it wasn't tampered with.
Do I have digital certificates on my Windows system?
Yes. Digital certificates are used extensively in Windows. Some examples of how they're used include:
- Email. Many customers use digital certificates to encrypt emails (to provide confidentiality) or digitally sign them (to prove their authenticity).
- Web site security. Many web sites use Secure Sockets Layer - a technology that depends on digital certificates - to provide security for commercial transactions over the Internet.
- Network security. Many businesses have deployed smart cards and other security technologies that use digital certificates, as a way of improving the security of their computer network.
- File security. The Encrypting File System (EFS) in Windows 2000 and XP enable users to cryptographically secure the files on their computers using digital certificates.
Where do digital certificates come from?
In general, digital certificates originate from any of four sources:
- Purchased from a vendor. The example of such a case is an email certificate. A person who wanted to digitally sign email would need to buy a digital certificate from a certificate vendor. The user would install the private key onto his or her system; the vendor would post the certificate to a public site and provide verification that it was genuine.
- "Baked into" an operating system. Windows includes the "root" certificates from many well-known certificate vendors. This allows Windows to recognize certificates issued by those vendors, thereby simplifying SSL and other uses.
- Obtained from a certificate server. Businesses that have deployed public key infrastructures typically deploy servers to generate and host certificates.
- Generated by an operating system. Windows can generate certificates locally for its own use in certain cases. For instance, the first time you use EFS, Windows generates a certificate and stores it in a way that lets you use it to decrypt files.
What's the Certificate Enrollment Control?
The Certificate Enrollment Control is a software component that allows Windows users to request digital certificates. (In digital certificate parlance, requesting a certificate is referred to as enrolling). The control serves two purposes:
- It creates certificate requests.
- It stores the returned certificate in an area of memory called the certificate store
Here's an example of how the Certificate Enrollment Control might be used. Suppose John needed to purchase a certificate from a commercial vendor. He might visit the vendor's web site and fill out a form with information about himself and the type of certificate he needed. When he submitted the form, the web page would request that the Certificate Enrollment Control (located on John's computer) create a request and send it. The site would then generate a certificate, which it would send to the Certificate Enrollment Control for storage in John's computer.
What's wrong with the Certificate Enrollment Control?
By design, the control should be able to install new certificates, but should never be able to access certificates that are already on the user's system. However, this restriction could be bypassed through an extremely complex process, with the result that one or more of the certificates on the user's system could be deleted.
What would this enable an attacker to do?
An attacker who successfully exploited this vulnerability could delete any or all of the certificates on a user's system, as a way of preventing the user from being able to using them. This would prevent the user from being able to do whatever those certificates were designed to enable. Some examples of what could be done include:
- Deleting an email certificate in order to prevent the user from being able to encrypt or sign email with it anymore.
- Deleting one or more of the "baked-in" certificates, in order to complicate the use of SSL-protected web sites. Each time the user visited such a site, a dialog would be displayed, asking whether the user trusts the web site.
- Deleting an EFS certificate, to prevent the user from encrypting any additional files. (It wouldn't be possible to prevent the user from recovering previously encrypted files, since a different user account is, by default, the EFS Recovery Agent).
Could an attacker use this vulnerability to delete a certificate on a smart card?
Vulnerability could only be used to corrupt digital certificates on the local system.
How might an attacker carry out an attack via the vulnerability?
The attacker would need to build a web page that, when opened, invokes the Certificate Enrollment Control in exactly the right way to identify and delete the certificates. The page could then be hosted on a web site, in order to attack any user who visited the site, or sent as an HTML email, in order to attack any user who received and opened the mail.
What steps could I take to prevent an attack via a web site?
The simplest way to prevent it is to install the patch. However, even without the patch, a web site could only attack someone who visited it - the vulnerability doesn't provide any way for an attacker to force someone to visit the site. Instead, the attacker would need to find a way to coerce or persuade users into visiting it.
For most users, the risk of a web site-based attack is limited. Only a small number of web sites are operated by malicious people and, not surprisingly, these tend to be infrequently visited. The web sites that are most commonly visited tend to be ones operated by people who respect their visitors. Just the same, you can easily configure Internet Explorer to prevent any possibility of an attack.
How would I do this?
Internet Explorer provides a feature called Security Zones, that lets you restrict what web sites can do. In this case, if ActiveX controls have been disabled in the security zone that a web site is located in, the site could not invoke the Certificate Enrollment Control and therefore could not exploit the vulnerability.
To disable ActiveX controls in the Internet Zone (which is the zone where all Internet sites reside by default), use the following procedure:
- In Internet Explorer, on the Tools menu, click Internet Options.
- Click the Security tab, and then select the Internet Zone.
- Under Security level, select Custom Level.
- Under "ActiveX Controls and Plug-ins", locate the entry labeled "Run ActiveX controls and plug-ins" and select "Disable".
- Click OK to exit the Security Settings dialogue
- Click OK to exit the Internet Options dialogue.
What steps could I take to prevent an attack via an HTML mail?
HTML mails are essentially web pages, except that they're sent as mails rather than hosted on web sites. Because of this, Internet Explorer is used to display them, regardless of what email client you use, and the Security Zones mechanism can protect you. Specifically, if the email client you use instructed Internet Explorer to open HTML mail in the Restricted Sites Zone, the vulnerability could not be exploited - because ActiveX controls are disabled by default in that zone. Outlook Express 6.0 and Outlook 2002 both open HTML mail in the Restricted Sites Zone by default. Outlook 98 and 2000 will open HTML mail in the Restricted Sites Zone if you've installed the Outlook Email Security Update.
Does this vulnerability affect enrollment through the Certificates MMC snap-in or auto-enrollment on Windows 2000 or XP systems?
No. The vulnerability only affects enrollment through Internet Explorer over the web.
I operate a certificate authority that relies on the Certificate Enrollment Control for web enrollment. Do I need to change anything on my site to allow it to work with the updated Certificate Enrollment Control you're deploying?
Yes. The patch sets the "Kill Bit" on the original version of the control, and provides a new control. If you operate a web site that uses the control, some modifications will be needed to your site in order for it to support the new control. These are discussed in detail in Microsoft Knowledge Base article Q323172.
How did Microsoft learn of this vulnerability?
Microsoft discovered during an internal security investigation.
What does the patch do?
The patch does two things. First, it delivers a new version of the controls, that includes code changes that eliminate the vulnerabilities. Second, it sets the "Kill Bit" on the original versions of the control, thereby preventing them from being re-introduced onto a user's system.
The Caveats section says that Internet Explorer 5 or later is a requirement for the patch. Why is this?
The new version of the control relies on technology that isn't available in versions of Internet Explorer prior to Version 5. With that said, though, customers using older versions of Internet Explorer may still choose to install the patch, if only to render the original version of the control inoperable.
Download locations for this patch Patches for all Windows platforms will be available from Windows Update on August 29, 2002. For users who want to download the patches immediately, please refer to the following locations:
- 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 Windows XP 64-bit Edition:
- The Windows 98 patch can be installed on any system running Windows 98.
- The Windows 98 Second Edition patch can be installed on any system running Windows 98 Second Edition.
- The Windows Me patch can be installed on any system running Windows Me.
- The Windows NT 4.0 patch can be installed on systems running Windows NT 4.0 Service Pack 6a.
- The Windows NT 4.0 Terminal Server Edition patch can be installed on systems running Windows NT 4.0 Terminal Server Edition Service Pack 6.
- The Windows 2000 patch can be installed on systems running Windows 2000 Service Pack 1, Windows 2000 Service Pack 2 or Windows 2000 Service Pack 3.
- The patch for Windows XP can be installed on systems running Windows XP Gold.
Inclusion in future service packs:
- The fix for this issue is included in Windows XP Service Pack 1
- The fix for this issue will be included in Windows 2000 Service Pack 4.
Reboot needed: Yes
Patch can be uninstalled: Yes
Superseded patches: None.
Verifying patch installation:
Windows 98, Windows 98SE and Window 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: UPD323255 Windows xx Q323172 Update where xx is "98" for Windows 98 or 98SE, or "Me" for Windows Me.
- To verify the individual files, consult the file manifest in Knowledge Base article Q323172.
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\Q323172
- To verify the individual files, consult the file manifest in Knowledge Base article Q323172.
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\Q323172.
- To verify the individual files, consult the file manifest in Knowledge Base article Q323172.
- 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\Q323172
- 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\Q323172\Filelist
- To verify that the patch has been installed, confirm that the following registry key has been created on the machine: HKLM\Software\Microsoft\Updates\Windows XP\SP1\Q323172
- To verify the individual files, use the date/time and version information provided in the following registry key: HKLM\Software\Microsoft\Updates\Windows XP\SP1\Q323172\Filelist
- The patch can be installed on systems running any version of Internet Explorer. However, the control it delivers will only operate under Internet Explorer 5 or later; installing the patch on a version prior to this only has the effect of rendering the vulnerable control inoperable.
- Web sites that use the Certificate Enrollment Control will require minor code changes to operate with the new control. These are discussed in detail in Microsoft Knowledge Base article Q323172.
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:
- Microsoft Knowledge Base article Q323172 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.
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.
- V1.0 (August 28, 2002): Bulletin Created.