• Article

Security Bulletin

Microsoft Security Bulletin MS00-039 - Critical

Patch Available for 'SSL Certificate Validation' Vulnerabilities

Published: June 05, 2000 | Updated: August 09, 2000

Version: 1.1

Originally posted: June 05, 2000

Summary

Microsoft has released a patch that eliminates two security vulnerabilities in Microsoft® Internet Explorer. The vulnerabilities involve how IE handles digital certificates; under a very daunting set of circumstances, they could allow a malicious web site operator to pose as a trusted web site.

Affected Software:

  • Microsoft Internet Explorer 4.x
  • Microsoft Internet Explorer 5.x
    Note: Microsoft Internet Explorer 5.01 Service Pack 1 and Internet Explorer 5.5 are not affected by these vulnerabilities.

Vulnerability Identifiers

General Information

Technical details

Technical description:

Two vulnerabilities have been identified in the way IE handles digital certificates:

  • When a connection to a secure server is made via either an image or a frame, IE only verifies that the server's SSL certificate was issued by a trusted root - it does not verify the server name or the expiration date. When a connection is made via any other means, all expected validation is performed.
  • Even if the initial validation is made correctly, IE does not re-validate the certificate if a new SSL session is established with the same server during the same IE session.

The circumstances under which these vulnerabilities could be exploited are fairly restricted. In both cases, it is likely that the attacker would need to either carry out DNS cache poisoning or physically replace the server in order to successfully carry out an attack via this vulnerability. The timing would be especially crucial in the second case, as the malicious user would need to poison the cache or replace the machine during the interregnum between the two SSL sessions.

Frequently asked questions

What's this bulletin about?
Microsoft Security Bulletin MS00-039 announces the availability of a patch that eliminates two vulnerabilities in Microsoft® Internet Explorer. The vulnerabilities could allow a malicious web site operator, under very unusual conditions, to misrepresent his web site as a trusted site. Microsoft is committed to protecting customers' information, and is providing the bulletin to inform customers of the vulnerability and what they can do about it.

What's the scope of the vulnerabilities?
The vulnerabilities could allow a malicious web site operator to misrepresent his web site as a trusted web site, and engage in a secure session with the user as though his was the trusted site. The vulnerabilities would be difficult to exploit, and would require that the malicious user already have significant control over the communications channel. Even then, it would represent a target of opportunity at best -- the malicious user could not compel anyone to connect to his server.

How are these vulnerabilities related to each other?
The vulnerabilities are only related in the sense that both affect how IE handles digital certificates used in Secure Socket Layer (SSL) sessions.

What is SSL?
SSL is a protocol that allows web sessions to be encrypted for greater security. Whenever you visit a web site via IE and see an icon in the lower right corner of the browser window that looks like a key, it means you've got an SSL session in progress with the site.

What is a digital certificate and how is one used in SSL?
A digital certificate is a piece of data that binds a public key to the person or organization who owns it. Digital certificates are issued by certificate authorities, who digitally sign the certificates in order to make them tamperproof and vouch for the authenticity of the certificate. In order for a web server to offer secure web sessions via SSL, it must have a digital certificate. When a web user establishes an SSL session with a server, the user's browser and the server conduct a handshake process. A simplified version of this process proceeds as follows:

  • The server passes its certificate to the browser
  • The browser validates it by verifying the digital signature and ensuring that the name on the certificate is the right one, the certificate has not expired, it was issued by a trusted party, and so forth.
  • The browser generates data needed for the creation of cryptographic key material, encrypts it using the public key on the server's certificate, and sends it to the server.
  • The browser and server generate keys and encrypt all session traffic from that point forward

Why does the first vulnerability occur?
The first vulnerability occurs because IE doesn't perform all of the expected certificate validation, if the session was set up in either of two ways. Under normal circumstances, IE does perform all expected certificate validation. However, if the connection to the server is made via either an image or within a frame, IE only verifies that the certificate was issued by a trusted party.

Why does this pose a security threat?
It could help make it possible for a malicious web site to pose as a different web site - one that the user trusts. By itself, the vulnerability wouldn't be sufficient to accomplish this, but it would be an important part of such an attack. To pose as a trusted site, a malicious web site operator would need to accomplish two goals:

  • He would need to be able to convince someone who visited his site that it was actually a different site.
  • He would need to be able to set up an SSL session in the guise of the site his is posing as.

This vulnerability could enable him to accomplish the second goal, because it would allow his site to present a certificate and have it accepted even if it didn't match the name of his site. However, accomplishing the first goal would be a separate issue, requiring that the malicious user either carry out DNS poisoning or physically interpose his machine in place of the other server.

What is DNS poisoning?
DNS (Domain Name Service) is the protocol by which web addresses (e.g., www.microsoft.com) are translated into IP addresses (e.g., 207.46.131.30). DNS poisoning involves providing bogus data to a DNS server in order to misdirect users. For instance, a malicious user who operated Web Site A but wanted to pose as Web Site B might mount a DNS poisoning attack in order to put Web Site A's IP address into the entry for Web Site B. Users who used the "poisoned" DNS server to locate Web Site B would then be served Web Site A's IP address. DNS poisoning is a technically-difficult attack. Even when successful, the effects are limited to particular DNS servers and only last for a short period. Thus, even with the vulnerability in hand, it would be very difficult for a malicious web site operator to actually carry out an attack using it.

Why does the second vulnerability occur?
The second vulnerability occurs because IE caches certificates that it has validated, and doesn't revalidate certificates from the same site if a subsequent SSL session is started with that site during the same IE session. Consider the following scenario:

  • The user starts IE and establishes an SSL session with Web Site A
  • He ends the SSL session with Web Site A and browses some other sites
  • He returns to Web Site A and establishes a new SSL session

When establishing the first SSL session, IE would validate the certificate from Web Site A. (Note that, because of the first vulnerability, there are cases in which IE would not perform this validation completely). When establishing the second SSL session with Web Site A, IE would note that it has previously validated a certificate from that site, and would simply use the certificate the site presented without validating it -- even if the certificate were completely different.

Why does this pose a security threat?
It's easiest to see by example. Suppose you just completed an SSL session with Web Site A, and five minutes later decided to start another SSL session with the same site. Now suppose that during the previous five minutes, a malicious user had somehow managed to interpose his server between you and Web Site A, or had carried out a DNS poisoning attack to masquerade as Web Site A. When you started a new SSL session with Server B (thinking it was Server A), the malicious user could send you a bogus certificate. The vulnerability would cause IE to not try to validate the certificate, but instead simply use the certificate blindly. The result would be an SSL session with Web Site B that appeared to be with Web Site A.

Would I need to return to the same site in order for this vulnerability to be exposed?
Yes. IE correctly validates a site's certificate the first time it's used (within the limits of the first vulnerability, discussed above). It's only if you establish a subsequent session with the same site (or one that appears to be the same site) that the vulnerability is exposed.

What would happen if I closed IE between the two SSL sessions?
The vulnerability wouldn't be exposed. IE only skips the certificate validation if it already has a validated certificate in the cache. The cache is cleared each time you close IE.

Is there a way to manually verify certificates?
Yes. At any point during an SSL session, you can view the server's certificate by double-clicking on the key icon that appears at the lower right corner of the screen. This will let you see who the certificate was issued to, who issued it, the expiration date, and other details. In addition, you can configure IE to always request manual confirmation of a certificate before setting up any SSL session. Anytime a certificate is submitted that wasn't issued by a trusted party, IE will display a warning message that lets you inspect the certificate and decide whether to proceed. If you want to always make the choice yourself, you can do this by removing the default trusted certification authorities in IE as follows:

  • Choose Tools, then Internet Options
  • Select the Content tab, then click "Certificates"
  • Select the tab labeled "Trusted Root Certification Authorities" and remove the entries.
  • Click OK

What does the patch do?
The patch causes IE to correctly validate certificates no matter how the session was established, and to validate the certificate before every SSL session, under all conditions.

The Patch Availability section of the bulletin says that the patch for the issues discussed here was incorporated into a later-released one. Why was this done?
We incorporated the patch for the issues discussed here into a later-released patch in order to minimize the number of patches customers would need to install. Customers who have applied the patch provided in Microsoft Security Bulletin MS00-055 are automatically protected against the vulnerabilities discussed here and do not need to take any other action.

How do I use the patch?
The Knowledge Base article contains detailed instructions for applying the patch to your site.

Where can I get the patch?
The download location for the patch is provided in the "Patch Availability" section of the security bulletin.

How can I tell if I installed the patch correctly?
Knowledge Base article Q254902 provides a manifest of the files in the patch package.The easiest way to verify that you've installed the patch correctly is to verify that these files are present on your computer, and have the same sizes and creation dates as shown in the KB article.

What is Microsoft doing about this issue?
Microsoft has developed a procedure that eliminates the vulnerability.

  • Microsoft has provided a security bulletinand this FAQ to provide customers with a detailed understanding of the vulnerability and the procedure to eliminate it.
  • Microsoft has sent copies of the security bulletin to all subscribers to the Microsoft Product Security Notification Service, a free e-mail service that customers can use to stay up to date with Microsoft security bulletins.
  • Microsoft has issued a Knowledge Base article explaining the vulnerability and procedure in more detail.

Where can I learn more about best practices for security?
The Microsoft TechNet Security web site is the best to place to get information about Microsoft security.

How do I get technical support on this issue?
Microsoft Technical Supportcan provide assistance with this or any other product support issue.

Patch availability

Download locations for this patch

  • https: Note: The patch for these issues has been incorporated into a subsequently-issued patch. See Microsoft Security Bulletin MS00-055 for more information. Customers using IE 5.01 SP1 or IE 5.5 may wish to apply the patch even though these versions are not affected by the vulnerabilities discussed here; the patch is an omnibus patch that eliminates a wide variety of vulnerabilities, some of which do affect IE 5.01 SP1 and IE 5.5.

    Note: Customers who install this patch on versions other than IE 4.01 SP2, IE 5.01, IE 5.01 SP1 or IE 5.5 may receive a message reading "This update does not need to be installed on this system". This message is incorrect. More information is available in KB article Q254902.

Additional information about this patch

Installation platforms: Please see the following references for more information related to this issue.

  • Microsoft Knowledge Base (KB) article Q254902, </https:>https:

Other information:

Acknowledgments

Microsoft thanks  the ACROS Penetration Team, Slovenia, for reporting this issue to us and working with us to protect customers.

Support: This is a fully supported patch. Information on contacting Microsoft Technical Support is available at </https:>https:.

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:

  • June 05, 2000: Bulletin Created.
  • August 09, 2000: Patch Availability section updated to advise availability of a subsequently-released patch that eliminates vulnerabilities in addition to those discussed here.

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