Microsoft Security Bulletin MS01-017

Technical description:

In mid-March 2001, VeriSign, Inc., advised Microsoft that on January 29 and 30, 2001, it issued two VeriSign Class 3 code-signing digital certificates to an individual who fraudulently claimed to be a Microsoft employee. The common name assigned to both certificates is "Microsoft Corporation". The ability to sign executable content using keys that purport to belong to Microsoft would clearly be advantageous to an attacker who wished to convince users to allow the content to run.

The certificates could be used to sign programs, ActiveX controls, Office macros, and other executable content. Of these, signed ActiveX controls and Office macros would pose the greatest risk, because the attack scenarios involving them would be the most straightforward. Both ActiveX controls and Word documents can be delivered via either web pages or HTML mails. ActiveX controls can be automatically invoked via script, and Word documents can be automatically opened via script unless the user has applied the Office Document Open Confirmation Tool.

Even though the certificates say they are owned by Microsoft, they are not bona fide Microsoft certificates, and content signed by them would not be trusted by default. Trust is defined on a certificate-by-certificate basis, rather than on the basis of the common name. As a result, a warning dialogue would be displayed before any of the signed content could be executed, even if the user had previously agreed to trust other certificates with the common name "Microsoft Corporation". The danger, of course, is that even a security-conscious user might agree to let the content execute, and might agree to always trust the bogus certificates.

VeriSign has revoked the certificates, and they are listed in VeriSign's current Certificate Revocation List (CRL). However, because VeriSign's code-signing certificates do not specify a CRL Distribution Point (CDP), it is not possible for any browser's CRL-checking mechanism to locate and use the VeriSign CRL. Microsoft has developed an update that rectifies this problem. The update package includes a CRL containing the two certificates, and an installable revocation handler that consults the CRL on the local machine, rather than attempting to use the CDP mechanism.

Customers should take notice of the caveats listed below in the section titled "Additional information about this patch", and in particular should note that the update will need to be re-installed when upgrading to any currently-available version of Windows or Internet Explorer. Versions of Windows beginning with Windows XP Gold and Windows 2000 Service Pack 2, and versions of Internet Explorer beginning with IE 6 will not require the update to be re-installed.

Customers who do not wish to install the update should take the following steps to protect themselves in the event that they encounter hostile code signed by one of the certificates:

• Visually inspect the certificates cited in all warning dialogues. The two certificates at issue here were issued on 29 and 30 January 2001, respectively. No bona fide Microsoft certificates were issued on these dates. The FAQ and Knowledge Base article Q293817 provide complete details regarding both certificates.
• Install the Outlook Email Security Update to prevent mail-borne programs from being launched, even via signed components, and install the Office Document Open Confirmation Tool to force web pages to request permission before opening Office documents.

Mitigating factors:

• The certificates are not trusted by default. As a result, neither code nor ActiveX controls could be made to run without displaying a warning dialogue. By viewing the certificate in such dialogues, users can easily recognize the certificates.
• The certificates are not the bona fide Microsoft code-signing certificates. Content signed by those keys can be distinguished from bona fide Microsoft content.

Vulnerability identifier: None. This issue is not the result of a flaw in a Microsoft product; it results because of an error made by a third party.

Tested Versions:

Microsoft tested the following products to assess whether they are affected by this vulnerability. We have waived normal support guidelines to provide remediation for all operating systems that are still in widespread use, regardless of whether they are normally supported or not.

• Microsoft Windows 95
• Microsoft Windows 98
• Microsoft Windows Me
• Microsoft Windows NT 4.0
• Microsoft Windows 2000

Is this a security vulnerability?
This issue does not meet the strict definition of a security vulnerability, because there is no flaw in any of the affected Microsoft products. The problem results solely because of an error made by a third party. However, it clearly poses a grave risk to customers, and we have issued this bulletin to provide information about the issue and the actions customers should immediately take.

What's the scope of the problem?
VeriSign, Inc., a major certificate authority, has informed Microsoft that in January 2001 it erroneously issued two digital certificates to an individual who fraudulently claimed to be a Microsoft employee. These certificates could be used to digitally sign programs (including ActiveX controls and Word macros) using the name "Microsoft Corporation".
Programs signed using these certificates would not be able to run automatically or bypass any normal security restrictions. However, the warning dialogue that appears before such programs could run would claim that they had been digitally signed by Microsoft. Clearly, this would be a significant aid in persuading a user to run the program.

What is a digital certificate?
To answer that question, we first need to discuss cryptography, particularly 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.
In public key cryptography, one of the 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, of which the public key 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.

Using public-key cryptography in this manner to prove the origin and authenticity of data is known as digital signing.

But what ensures that the private key really belongs to the person listed in the digital certificate?
Digital certificates are generated and digitally signed by organizations known as certificate authorities. It's the job of a certificate authority to verify the identity of the person requesting a digital certificate before issuing one to them.

What's wrong with the certificates in this case?
A certificate authority, VeriSign, erroneously issued two digital certificates to a person who claimed to be a Microsoft employee. The certificates say that the owner of the certificate is Microsoft, when in fact this is not the case.

So, these aren't bona fide Microsoft certificates?
That's correct. None of Microsoft's certificates have been compromised. These are new certificates that VeriSign erroneously issued, and which incorrectly say that Microsoft owns them.

If Microsoft doesn't own these certificates, who does?
The identity of the person who purchased the certificates isn't known at present. However, both VeriSign and Microsoft are working closely with law enforcement authorities to find the person, as it appears that several laws may have been broken during the purchase of these certificates.

If Microsoft didn't issue these certificates, why is it involved in fixing the problem?
Microsoft is involved in this issue because it's Microsoft's name on the certificates that VeriSign issued, and it's Microsoft's customers who stand to be harmed by them. Microsoft has a long-standing commitment to protecting its customers' security, and is taking the steps discussed here as part of that commitment.

What could these two certificates be used to do?
These certificates are of a type that can be used to digitally sign programs, including ActiveX controls and Office macros. Many software developers, including Microsoft, digitally sign the programs they create in order to assure customers that the programs are legitimate and have not been modified.

Could the certificates be used for any other purpose?
No. All digital certificates carry a marking that restricts what they can be used for. These particular certificates can only be used to digitally sign programs. They cannot be used to encrypt data, sign e-mails, log onto Windows 2000 systems, or do anything else besides signing programs.

How might an attacker use these certificates?
The attacker's overall goal would very probably be to convince other users to run an unsafe program, by using the digital signature to convince them that it is actually bona fide Microsoft software and therefore safe to run. There are a variety of scenarios the attacker might use to accomplish this, but if the attacker's goal was distribute malicious code widely, a few scenarios would likely be especially attractive.
The attacker probably would choose to use an attack scenario designed to deliver the program to a large number of users, such as hosting the signed program on a web site or sending an HTML e-mail that would retrieve it from a web site. It's also likely that he would choose to package the program as either an ActiveX control or an Office document containing a signed macro, because doing so would allow him to initiate running the program automatically, as soon as a user either visited the web page or opened the HTML mail.

Did you say that the attacker could make the signed program run automatically?
No. There's a fine distinction between initiating the running of a program and actually running it, and it's worth spending a few moments discussing the difference.
From the attacker's perspective, the problem with simply sending a signed program as an attachment to a mail, or hosting it as a file on a web site, is that he would need to persuade the user to select the program and deliberately choose to run it. This isn't impossible to accomplish - witness the success of the I Love You virus, for instance, which did exactly this - but the attacker would want a method that minimizes the number of steps the user must take to run the program.
Web pages and HTML e-mails can automatically initiate ActiveX controls, and can automatically open Word documents (unless the user has previously installed the Office Document Open Confirmation Tool). However, in either case a warning dialogue similar to the one below would be displayed before the program actually began running. The dialogue would ask the user whether it's OK for the program to run. The danger, of course, is that the dialogue would say that the program was digitally signed by Microsoft, and even a security-conscious user might agree to let it run.

Suppose I had previously said to always trust content signed by Microsoft. Would I still see a warning dialogue?
Even if you have previously said to always trust Microsoft-signed programs, you would still see a warning dialogue at least one time. This is because trust is assigned on a per-certificate basis, not on a per-name basis. That is, you can specify that you trust a particular certificate because the name on it is Microsoft, but there isn't any way to say that you want to trust all certificates that say Microsoft on them.
The upshot is this: even though the two bogus certificates say they are Microsoft certificates, they are not trusted by default. You are guaranteed to see the warning dialogue the first time you encounter a program signed using either of these certificates, and will continue to see it unless you select "Always trust content from Microsoft Corporation" in response to the warning dialogue.

What is Microsoft doing to help with this problem?
Although this issue doesn't result from a flaw in any Microsoft product, we have nevertheless developed an update that will help customers ensure that content signed by the two certificates is recognized as being invalid.

Why are you referring to this as an update? Isn't it a patch? 
No. A patch corrects a flaw in a piece of software. In this case, though, there isn't a flaw in any Microsoft product.

If there's no flaw in Microsoft software, why are you releasing new software?
There's a standard procedure that should allow VeriSign to prevent these certificates from being accepted if they're used. Microsoft products support that procedure, but a defect in construction of VeriSign code-signing certificates prevents it from being effective in this case.
Every certificate issuer periodically generates a Certificate Revocation List (CRL), which lists all the certificates that should be considered invalid. Every certificate should provide a piece of data called the CRL Distribution Point (CDP) - this data indicates the location from which the CRL can be obtained. The problem is that VeriSign code-signing certificates don't provide CDP information. As a result, even though VeriSign has added these two certificates to its current CRL, it's not possible for systems to automatically download and check it. Our update compensates for this omission in the VeriSign certificates.

What does the update do?
The update does the following:

• Installs a CRL onto the local machine. The CRL lists the two bogus certificates as having been revoked.
• Adds new functionality via a piece of software called an installable revocation handler that causes the system to check the CRL on the machine if the CDP data is missing or invalid.
• Turns on CRL checking in IE for software publisher's certificates.

What versions of Windows can the update be installed on?
Because of the risk this issue poses, Microsoft has taken the unusual step of producing an update for every Windows operating system produced since 1995, regardless of whether it's normally supported or not. The section titled "More Information about this Patch" provides specific version and service pack information.

What's the effect of installing the update?
After installing the update, if you encounter a program signed using either certificate, you won't see the warning dialogue anymore that asks whether you want to let the program run. Instead, you'll see a dialogue telling you that the certificate has been revoked and that the program cannot be trusted. For instance, on either Windows Me or Windows 2000, you'd see a dialogue like the one below. The dialogues on other versions of Windows are similar.

Would it still be possible for me to run the program?
The default choice is to prevent the program from running. It's possible to override this choice, but we strongly recommend against it. The fact that a certificate has been revoked by its issuer speaks volumes about its untrustworthiness.

Suppose I had previously encountered a program signed using one of these certificates and said that I wanted to trust it. If I subsequently encountered a program signed with the same certificate, would the update help me?
A certificate's revocation status takes precedence over its trust status. This means that even if you've previously said you trust one of the certificates, the update would display a message telling that it was untrustworthy if you subsequently encountered something signed using it.
However, this is not the cure-all it might initially seem to be. Remember that the opportunity to trust a certificate comes as part of the warning dialogue that's displayed when a signed program is initiated by a web site or HTML e-mail. Although it's not a requirement to let the program run when you select the "Always trust" box, it's extremely unlikely that someone would choose to trust the certificate but not allow the program to run.
Thus, if you've agreed to trust either of the two certificates, it's very likely that you allowed a program signed using the certificate to run on your system. It hardly matters that the update would alert you if you tried to subsequently run a program signed using the same certificate, because your system could have been completely compromised by the first program.

I don't want to install the update. Are there other steps I can take to protect my system?
The best way to protect your system is to install the update, but there are still things you can do to help protect your system:

• If you see a dialogue asking whether to trust content signed by Microsoft, visually inspect the certificate and verify that it isn't one of the bogus ones.
• Ensure that you have installed the Outlook E-mail Security Update and the Office Document Open Confirmation Tool.

How can I visually inspect the certificates?
As we discussed above, you'll always see a warning dialogue anytime a web site or e-mail tries to run a program that's been signed by a certificate that isn't known to the system - even if the certificate says it's owned by Microsoft. (Of course, if you say to trust the certificate, you won't see the warning again). This dialogue offers an option to view the certificate by clicking on the signer's name. By inspecting the information in the certificate, you can easily tell whether it's one of the two bogus ones. Clearly, if the program has been signed by one of these certificates, you should not run it. Here are screen shots of the two bogus certificates:

The screen shot lists protecting e-mail messages as one of the intended purposes, but you said they could only be used to sign programs. Which is correct?
The "issued by" information is the authoritative piece of data, rather than the "intended purposes" information. Because the certificate was issued by the VeriSign Commercial Software Publishers CA, it can only be used to sign programs, regardless of what other sections of the certificate may say.

How would installing the Outlook E-mail Security Update help protect my system?
The Outlook E-mail Security Update prevents HTML mails from launching ActiveX controls, even if they have been digitally signed. By installing the update, you can ensure that you're protected against the mail-borne version of this attack. If you haven't already installed the update, do it today.

How would installing the Office Document Open Confirmation Tool help protect my system?
The Office Document Open Confirmation Tool prevents web sites and HTML e-mails from being able to open Office documents such as Word files without your consent. This would make it more difficult to cause a digitally signed Word macro to run.

I am hosting the full VeriSign CRL on my system. Do I need to take any special action when I install the update?
Yes. If you are already hosting a local CRL, you should be aware that the update will overwrite it with the CRL it contains. After installing the update, you'll need to download and install a fresh copy of the full VeriSign CRL.
Also, you should be aware of the maintenance burden associated with hosting the full CRL. Like most certificate issuers' CRLs, the full VeriSign CRL is short-lived. It's only valid for about a week from the date of issuance. The system will not use an expired CRL, so you would need to regularly download and install an updated CRL. In contrast, the CRL that's installed by the update has a very long life, and if you use it you won't ever need to refresh it.

What if I upgrade my system at some point? Will I need to re-apply the update?
You might need to. All currently-shipping versions of Windows and Internet Explorer - that is, versions of Windows equal to or earlier than Windows XP Beta 2, Windows 2000 Service Pack 1, and Windows Me, and versions of Internet Explorer equal to or earlier than IE 5.5 (regardless of service pack) - reset certain parameters when they're installed, and and this has the effect of disabling the update. If you upgrade Windows or IE to any of these versions, you'll need to re-apply the update after upgrading.
In contrast, Windows XP Gold, Windows 2000 beginning with Service Pack 2, and Internet Explorer 6 will no longer reset these parameters, so it won't be necessary to re-install the update when upgrading to these versions or later ones.

If there are multiple users who share a computer, do each of the users need to install the update?
No. Only an administrator can install the update, but once installed on a machine, it will take effect for all users who log onto it.

I heard that the CRL included in the update has three entries in it. Yet there are only two bogus certificates. Why is there a third entry in the CRL?
The third entry in the CRL is a bona fide Microsoft certificate that we deliberately revoked to assist in testing the update. Throughout much of the discussion above, we've been somewhat lax in our terminology, and have discussed using a digital certificate to sign a program. However, remember that in actuality a digital certificate only verifies a digital signature - it can't be used to create one. A digital signature is created using the private key that's associated with the digital certificate.
The problem is that although we have a copy of the two certificates, the private keys associated with them are in the hands of the person who bought them. This means that nobody except that person can digitally sign programs using them. However, we needed to test our update against programs that were signed using a revoked certificate. We therefore deliberately revoked an existing Microsoft test certificate, included it in the CRL, and then signed programs using that certificate's associated private key. We used these signed programs to test our update.

Is it possible to verify that the update is working correctly?
Yes. There are two ways to do this. The easiest way is to verify that the files installed by the patch are actually present on your machine. To do this, perform the following steps:

• Verify that the file verisignpub1.crl exists on the machine.
• Verify that CRL checking for code-signing certificates is enabled. In IE, select Tools, then Internet Options. Select the Advanced tab, then scroll to the section titled Security and verify that "Check for publisher's certificate revocation" has been selected.

There also is a file available that has been signed using the test certificate discussed in the previous question. By downloading this file and checking the signature, you can verify that the update is working correctly. The file is available at http://www.microsoft.com/downloads/details.aspx?FamilyId=BE633CFA-CA61-4D47-8F2D-537FEE155F26&displaylang=en.
If you choose to download this file, please keep in mind that this file, like any content signed using a revoked certificate, should never be run or installed. It should only be used to verify that the update works correctly, and should then be deleted.
After downloading the file into a folder, check the signature as follows:

• Right-click on the file and select Properties.
• Select the tab titled Digital Signatures.
• In the signature list, single-click on the name of the signer ("Microsoft Corp (Test Only)"), then click on the Details button.
• If the resulting dialogue states that the certificate has been revoked by its issuer, the patch is working correctly.

I received an e-mail that claimed to be from Microsoft and contained a program as an attachment. Could it be bona fide?
No. Microsoft has a strict policy against ever sending programs, security patches or any other type of executable content via e-mail. We distribute our software via our web site or on physical media like CD ROMs. If you receive such a mail, do not run the attachment.

Is it possible to tell whether I've ever run a program signed using one of the certificates?
It's possible to check your system for signs that indicate that you have run such a program. One way to do this is to use a tool that scans your hard drive for any content signed using either certificate. Several anti-virus vendors are developing such tools. Another way is to check your system registry to determine whether either certificate is on the listed of trusted ones. Microsoft Knowledge Base article Q293816 discusses how to do this. The presence of signed content on your system, or the presence of either certificate in the list of trusted ones, should be taken as an indication that you have run a program signed by one of these certificates.
However, it's important to understand that the absence of either of these indicators doesn't prove that you have not run a program signed using one of these certificates. An attacker could, for instance, create a signed program that, when run, would download unsigned programs to the hard drive, run them, and erase all traces of itself from the system.

If I discover that I have run a program signed using one of these certificates, what should I do?
Microsoft is continuing to aggressively investigate this issue, and we would be very interested in scrutinizing any programs signed using these certificates. If you encounter such a program, please send an e-mail to the Microsoft Security Response Center (secure@microsoft.com).

When I learned of this issue, I removed the VeriSign Commercial Software Publishers CA certificate from my Trusted Root Store. Now that the update is available, how can I reinstate the certificate?
Knowledge Base article Q293819 discusses how to do this.

Download locations for this patch

• http://www.microsoft.com/downloads/details.aspx?FamilyId=43FD979A-03C1-4008-B38D-70E9BCD67454&displaylang=en