Bugtraq mailing list archives

ALERT: [MS00-039] IE PATCH SSL Certificate Validation Vulnerabilities in Microsoft Internet Explorer


From: devnull () BUTCHERFAMILY COM (Devon Null)
Date: Tue, 6 Jun 2000 03:13:52 -0400


PATCH DOWNLOAD URI: (1.9663 MB) [Win9x, NT 4.0]
<http://mssjus.www.conxion.com/download/ie501/secpach7/5.01/WIN98/EN-US/q254
902.exe>
--------------------------------------------------------------

THIS DOCUMENT [Last updated June 05, 2000]:
<http://www.microsoft.com/technet/security/bulletin/fq00-039.asp?a=printable>
--------------------------------------------------------------

Microsoft Security Bulletin (MS00-039):Frequently Asked Questions
[Originally posted: June 05, 2000]

What's this bulletin about?

Microsoft Security Bulletin MS00-039 announces the availability of a patch
that eliminates two vulnerabilities in Microsoft® Internet Explorer.
<http://www.microsoft.com/technet/security/bulletin/ms00-039.asp>

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.

In addition to eliminating the vulnerabilities discussed in this bulletin,
the patch also eliminates all vulnerabilities discussed in a
previously-released Microsoft Security Bulletin, MS00-033. We've
incorporated that patch into this one for customer convenience.
<http://www.microsoft.com/technet/security/bulletin/ms00-033.asp>

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. In addition, the patch includes all fixes
provided in the patch that previously was released via Microsoft Security
Bulletin MS00-033
<http://www.microsoft.com/technet/security/bulletin/ms00-033.asp>

Why does this patch include all of the fixes for MS00-033?

We've incorporate the previous patch into this one for customer
convenience. Customers who apply this patch will not need to apply the one
delivered in MS00-033.
<http://www.microsoft.com/technet/security/bulletin/ms00-033.asp>

How do I use the patch?

Microsoft Knowledge Base article Q254902 (available soon) 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.
<http://www.microsoft.com/technet/security/bulletin/ms00-039.asp>

If I previously applied the patch provided in Microsoft Security Bulletin
MS00-033, do I need to apply this patch?

Yes. The patch provided in Microsoft Security Bulletin MS00-033
<http://www.microsoft.com/technet/security/bulletin/ms00-033.asp> doesn't
eliminate the vulnerabilities discussed here. You'll need to apply this
patch provided above.

However, if you haven't yet applied the patch for MS00-033, you only need
to apply this one

How can I tell if I installed the patch correctly?

Knowledge Base article Q254902 (available soon) 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 bulletin and this FAQ to provide
customers with a detailed understanding of the vulnerability and the
procedure to eliminate it.
<http://www.microsoft.com/technet/security/bulletin/ms00-039.asp>

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 will issue Knowledge Base article Q254902, 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 Support can provide assistance with this or any other
product support issue.
<http://support.microsoft.com/support/contact/default.asp>

Last updated June 05, 2000
© 2000 Microsoft Corporation. All rights reserved. Terms of use.
==========================<-30->=========================


Current thread: