Microsoft Security Bulletin MS02-048

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.

AQUÍ DICE QUÉ PARCHE BAJARSE EN FUNCIÓN DE LA VERSIÓN DE GÜIDOUS QUE USES: (aún, : -((  )

Installation platforms:

• 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.

   

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\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

   

Windows XP:

• 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\SP2\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\SP2\Q323172\Filelist

Caveats:

• 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.

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