|
|
|
|
| |
Microsoft has released a patch that eliminates two newly discovered vulnerabilities affecting Internet Explorer, both of which could enable an attacker to spoof trusted web sites. The first vulnerability involves how digital certificates from web servers are validated. When CRL checking for such certificates is enabled, it could be possible for any or all of the following checks to no longer be performed:
* Verification that the certificate has not expired
* Verification that the server name matches the name on the certificate
* Verification that the issuer of the certificate is trusted
The second vulnerability could enable a web page to display the URL from a different web site in the IE address bar. This spoofing could occur within a valid SSL session with the impersonated site. Both vulnerabilities could be used to convince a user that the attacker's web site was actually a different one - one that the user presumably trusts and would provide sensitive information to. However, as discussed in the Mitigating Factors section below, there would be significant hurdles to exploiting either vulnerability.
In addition to eliminating the two new vulnerabilities, the patch also eliminates two new variants of a previously discussed vulnerability, the Frame Domain Verification vulnerability. Like the original version, these new variants vulnerability could enable a malicious web site operator to open two browser windows, one in the web site's domain and the other on the user's local file system, and to pass information from the latter to the former. This could enable the web site operator to read any file on the user's local computer that could be opened in a browser window.
Finally, the patch incorporates the functionality of the patch provided in Microsoft Security Bulletin MS01-020. |
| |
Credit:
The information has been provided by Microsoft Product Security.
|
| |
Vulnerable systems:
* Microsoft Internet Explorer 5.01
* Microsoft Internet Explorer 5.5
Mitigating factors:
Server certificate validation vulnerability:
* The vulnerability only affects how certificates from web servers are validated. It does not affect how code-signing certificates or any other types of certificate are validated.
* The specific checks that might be bypassed vary with both the user and the actions she may have taken during the current browsing session. An attacker could not predict with any degree of certainty which checks might be bypassed in a particular case.
* The vulnerability does not provide any way to force users to the attacker's web site. It is likely that this vulnerability could only be exploited in conjunction with a successful DNS poisoning or similar attack.
Web page spoofing vulnerability:
* Like the vulnerability above, this vulnerability would not provide any way to force users to the attacker's web site, and DNS poisoning or other measures would likely be required to exploit it.
* Any hyperlinks within the page would correctly show the target. As a result, the attacker would need to point these to bona fide locations on the spoofed web site, with the result that the attacker would likely only be able to spoof a single web page, rather than an entire site.
New variants of "Frame Domain Verification" vulnerability:
* The vulnerability could only be used to read - not add, delete or change - files.
* The attacker would need to know the exact name and location of every file he wished to read.
* The vulnerability could only be used to read file types that can be opened within a browser window - for example, .htm, .txt or .doc files, but not .exe or .xls files.
Patch availability:
The download locations for this patch are:
http://www.microsoft.com/windows/ie/download/critical/q295106/default.asp
What vulnerabilities are discussed in this bulletin?
This bulletin discusses four security vulnerabilities:
* A vulnerability affecting the way digital certificates from web servers are validated.
* A vulnerability affecting the URL that is displayed for a web page.
* Two new variants of the previously discussed "Frame Domain Verification" vulnerability.
Does the patch provided here do anything besides eliminating these vulnerabilities?
Yes. It also incorporates the functionality of the patch previously provided in Microsoft Security Bulletin MS01-020. We have done this to make it more convenient for customers to protect their systems against the vulnerability discussed there.
What is the scope of the vulnerability affecting digital certificates?
When IE is configured to perform certain types of checking on digital certificates provided by web servers, it no longer performs other expected checks. This could potentially enable an attacker's web site to masquerade as a trusted site.
Exploiting this vulnerability would be an extremely daunting challenge. The vulnerability does not provide any way to actually divert web sessions from the trusted site to the attacker's site - it only provides a way to pass the site off as the bona fide once visitors arrive there. Diverting traffic to the site would require that the attacker successfully carry out a DNS poisoning or other technically difficult attack as a prerequisite.
What causes the vulnerability?
A flaw in IE causes certain certificate checks to no longer be made when CRL checking has been enabled for server certificates. Specifically, if CRL checking is selected, IE may not correctly verify the trust status of the root CA, the expiration date for the certificate, or the common name specified in the certificate.
What is a CRL?
A CRL (certificate revocation list) is a list of digital certificates that are known to be untrustworthy. Digital certificates are issued by organizations called certificate authorities (CAs). Each CA periodically publishes a list of all certificates that might appear to be valid, based on the expiration date and other information, but actually are not. For instance, the certificates may have been lost or stolen, or the person to whom the certificate was issued may no longer have authorization to use the certificate. For more information about CRLs, and PKIs in general, see http://www.microsoft.com/TechNet/win2000/2000cert.asp.
What is wrong with the way CRLs are checked?
There is nothing wrong with how IE checks CRLs. The problem results because if one type of CRL checking is enabled, other types of checks are no longer performed correctly.
What types of CRL checking are available, and which is affected by the vulnerability?
IE provides two options for checking CRLs in different circumstances. One option determines whether the CRL is checked when a web server presents a certificate. The other determines whether the CRL is checked when a digitally signed program or ActiveX control is downloaded. Only the option associated with checking server certificates is affected by the vulnerability.
What types of checks don't work correctly if server certificate CRL checking is enabled?
The flaw could prevent any or all of the following checks from being performed:
* Verification that the certificate has not expired
* Verification that the server name matches the name on the certificate
* Verification that the issuer of the certificate is trusted
Does the vulnerability prevent these check from ever being made, or does it only prevent them from being made in certain circumstances?
It only prevents the checks from being made in certain circumstances. There are a large number of factors that determine which checks would continue to made correctly, most of which are a function of the user is browsing history. Two users whose browsers were identically configured might be affected in completely different ways by the vulnerability, depending on what sites they had previously visited and what certificates they had previously verified.
Do these checks work correctly if server certificate CRL checking is not enabled?
Yes. If CRL checking is disabled (this is the default condition), all of the other checks are performed correctly all of the time. It is only when CRL checking is enabled that they function sporadically.
What would this vulnerability enable an attacker to do?
In the worst case, it could enable an attacker to represent his web site as though it was a different one - one that a visitor might trust.
Suppose John operated a web site, but wanted to impersonate Jane's web site. Let us also suppose that John had a means of causing people to arrive at his site when they actually intended to go to Jane's. (We will discuss this aspect of the problem in more detail later). This vulnerability would provide John with a way to convince visitors that they actually were at Jane's site, by providing a certificate that would pass all of the expected checks.
How could John create a certificate that would pass the checks?
There are two ways he might do this, depending on which of the checks he wanted to spoof. For example, he might:
* Set up his own CA and issue a certificate to himself that identified his site as Jane's. Visitors whose browsers did not correctly check the issuer of the certificate would incorrectly conclude that the certificate was bona fide.
* Obtain a certificate from a bona fide trusted issuer in his own name. Visitors whose browsers did not check the name on the certificate would incorrectly conclude that it was bona fide.
An important point to remember, though, is that different visitors' browsers would be affected differently by the vulnerability. As a result, regardless of the option John chose, it would not work on every visitor's machine.
You said that John would need a way to cause visitors to arrive at his site when they intended to go to Jane's. How could he do this?
John could only force visitors unknowingly to his site if he could successfully mount a DNS poisoning attack first. A DNS poisoning attack involves compromising a DNS server and changing its database so that it incorrectly resolves a particular URL (like the URL to Jane's site) to a different server's IP address (in our example, the one for John's site).
DNS poisoning attacks are fraught with problems for an attacker:
* They are difficult to carry out.
* Their effects tend to be only temporary. DNS servers constantly update their databases, and even a compromised database would eventually resume providing correct information.
* Their effects are local. Different users rely on different DNS servers, so the attacker would need to compromise the specific DNS server that his intended victim used.
How frequently is CRL checking enabled for server certificates?
In practice, CRL checking tends to only be used within enterprises that have deployed public key infrastructures.
If I do not use CRL checking, do I need to apply the patch?
No. However, you may want to consider applying it as a contingency in case you should decide to enable CRL checking later.
How can I tell if I've enabled CRL checking for server certificates?
Select Options from the IE Tools menu, then click on the Advanced tab. Scroll down to the Security section, and see whether "Check for server certificate revocation" has been selected. If it has, server certificate CRL checking is enabled and you are affected by the vulnerability. By default, it is not selected.
The option immediately above this one, titled "Check for publisher's certificate revocation", refers to whether a CRL is checked when digitally signed programs and ActiveX controls are downloaded. As discussed above, this option is not affected by the vulnerability in any way.
In Microsoft Security Bulletin MS01-017, you said that CRL checking in IE works correctly, yet now you are delivering a patch for a problem involving CRL checking. How are these statements consistent?
This bulletin and Microsoft Security Bulletin MS01-017 discuss two completely different types of certificates, with two completely different validation mechanisms. The certificates at issue in this bulletin are used to identify web servers; the ones discussed in MS01-017 are used to digitally sign programs. IE does not correctly handle web server certificates when CRL checking is turned on; but it does correctly handle code-signing certificates when CRL checking is turned on.
How does the patch eliminate this vulnerability?
The patch eliminates the vulnerability by ensuring that all expected checking is performed even when server certificate CRL checking is enabled.
What is the scope of the vulnerability affecting the URL that is displayed for a web page?
This vulnerability could make it possible for an attacker to make it appear that content from his web site actually originated from another site. If the other site were trusted by the user, the attacker might be able to persuade the user to provide sensitive or personal information. It would be possible for the attacker's site to establish an SSL session that would appear to confirm that the content was genuine.
There are two significant limitations on the scope of this vulnerability:
* Like the vulnerability discussed above, this vulnerability does not provide any way to actually cause users to arrive at the attacker's site - it only provides a way to pose as the bona fide site once visitors arrive there.
* The vulnerability would likely only enable the attacker to convincingly spoof a single page on the target web site.
What causes the vulnerability?
The vulnerability results because it is possible for a browser window to display another site's URL in the address bar. In addition, it is possible to establish an SSL session with another site, in order to provide convincing proof that the URL is the correct one.
How might an attacker exploit this vulnerability?
An attacker might use this vulnerability in order to spoof another site - that is, his web site could exploit this vulnerability in order to present a web page that essentially appeared to be a page on a different web site.
For instance, assume that Joe operates a web site. If he could convince Jane to visit his site, he could exploit this vulnerability to make it appear to Jane that she was actually at her bank's web site. Joe might then use the spoofed page in effort to, for instance, persuade Jane to enter the PIN for her online banking account.
Would the vulnerability enable the attacker to spoof SSL-protected sessions?
Yes. By carefully manipulating the web page, it would be possible for the attacker to make his content appear within a valid SSL session with the spoofed web site. In our example, this would enable Joe's phony content to not only display the URL for Jane's online banking site, but also to display the "lock" icon indicating that the session was protected by SSL. Further, if Jane clicked on the "lock" icon and checked the certificate, it would pass inspection - because it would indeed be her bank's digital certificate.
Would this enable the attacker to spoof an entire site?
No. The vulnerability does not provide any way to spoof the hyperlinks on the page itself. The upshot of this is that the attacker would likely be able to carry out a convincing deception only if he spoofed a single page, rather than an entire web site.
For instance, Joe could construct a page that appeared to belong to the web site for Jane's bank. However, if Jane did a mouse-over on any hyperlink on the page, IE would display the actual URL it leads to. (This information would be displayed in the lower left corner of the IE window).
Because of this, Joe would have to make a choice. He could try to spoof multiple pages on the bank's site, thereby providing Jane with an easy to realize the deception, or he would need to ensure that every hyperlink on his page led to a bona fide page on the bank's site. Of course, once Jane followed one of those links, she would no longer be at Joe's site, and he would have no way to make her return.
Could the attacker use this vulnerability to force a user to his site?
No. As in the case of the vulnerability discussed above, this vulnerability would provide a way to fool a user once she arrived at the attacker's site, but wouldn't provide a way to make her come to the site in the first place. It is likely that the attacker would need to resort to DNS poisoning or some other technical attack, none of which are easily carried out.
How does the patch eliminate this vulnerability?
The patch eliminates this vulnerability by changing the affected function in order to prevent HTML code from manipulating the URL that is displayed.
What is the scope of the two new variants of the "Frame Domain Verification" vulnerability?
The scope of the new variants is exactly the same as for the original variant, discussed in Microsoft Security Bulletin MS00-033. Although the underlying causes of the vulnerabilities are different, both could enable an attacker who operated a web site to view files on the computer of visiting user. The attacker would need to know the name and location of the file on the user's computer, and could only view files that can be opened in a browser window.
Where can I get more information on the "Frame Domain Verification" vulnerability?
Microsoft Security Bulletins MS00-033, MS00-055, MS00-093 and MS00-015 discuss previous variants of the vulnerability in detail.
Are there any differences between the new variants and the previous variants?
The new variants have exactly the same cause, effect, and remediation as the previously reported ones.
* The new variants, like the previous ones, occur because certain functions do not prevent browser windows in different domains from communicating with each other.
* The effect of all variants is the same - an attacker could open a browser window in his web site, and one on the local computer, then transfer data from the latter window to the former one. This would enable the attacker to read files, but not add, change or delete them.
* The remediation is to apply the patch, which causes the functions to properly isolate browser windows in different domains.
There are only two differences between the new variants and the previously discussed ones:
* The specific functions containing the flaw are different.
* One of the functions is only present on Windows 2000 systems, and as a result the variant associated with that function couldn't be exploited on any other system.
Does this patch eliminate the original variants as well as the new one?
Yes. When installed on a Windows 2000 system, the patch eliminates the new variant, and all preceding variants. When installed on any other system, the patch eliminates the previous variants, but not the current one since it does not affect non-Windows 2000 systems.
|
|
|
|
|
|
|
