Microsoft(R) Internet Explorer

In my last newsletter I explained about some security flaws in Internet Explorer and that there was a fix but is was withdrawn.

MS just released it again a few minutes ago!

 

Risk Rating:

============

- Internet systems: Critical

- Intranet systems: Critical

- Client systems: Critical

So I thought I notify you to get the fix!

Bink

 

 

Internet Explorer 6.0

 

Download FileSecurity Update

2.41 MB Download File

20 min @ 28.8 kbps

 

 

 

Internet Explorer 5.5 SP2

 

Download FileSecurity Update

2.15 MB Download File

18 min @ 28.8 kbps

 

 

 

Internet Explorer 5.5 SP1

 

Download FileSecurity Update

2.47 MB Download File

21 min @ 28.8 kbps

 

 

 

Internet Explorer 5.01 SP2

 

Download FileSecurity Update

1.74 MB Download File

15 min @ 28.8 kbps

 

More info:

 

  

 

Microsoft Security Bulletin MS02-005

 

11 February 2002 Cumulative Patch for Internet Explorer

Originally posted: February 11, 2002

Summary

Who should read this bulletin: Customers using Microsoftģ Internet Explorer

Impact of vulnerability: Six vulnerabilities, the most serious of which could allow an attacker to run code on another userís system.

Maximum Severity Rating: Critical

Recommendation: Customers using an affected version of IE should install the patch immediately.

Affected Software:

  • Microsoft Internet Explorer 5.01
  • Microsoft Internet Explorer 5.5
  • Microsoft Internet Explorer 6.0

Technical details

Technical description:

This is a cumulative patch that, when installed, eliminates all previously discussed security vulnerabilities affecting IE 5.01, 5.5 and IE 6. In addition, it eliminates the following six newly discovered vulnerabilities:

  • A buffer overrun vulnerability associated with an HTML directive thatís used to incorporate a document within a web page. By creating a web page that invokes the directive using specially selected attributes, an attacker could cause code to run on the userís system.
  • A vulnerability associated with the GetObject scripting function. Before providing a handle to an operating system object, GetObject performs a series of security checks to ensure that the caller has sufficient privileges to it. However, by requesting a handle to a file using a specially malformed representation, it would be possible to bypass some of these checks, thereby allowing a web page to complete an operation that should be prevented, namely, reading files on the computer of a visiting userís system.
  • A vulnerability related to the display of file names in the File Download dialogue box. When a file download from a web site is initiated, a dialogue provides the name of the file and lets the user choose what action to take. However, a flaw exists in the way HTML header fields (specifically, the Content-Disposition and Content-Type fields) are handled. This flaw could make it possible for an attacker to misrepresent the name of the file in the dialogue, in an attempt to trick a user into opening or saving an unsafe file.
  • A vulnerability that could allow a web page to open a file on the web site, using any application installed on a userís system. By design, IE should only open a file on a web site using the application thatís registered to that type of file, and even then only if itís on a list of safe applications. However, through a flaw in the handling of the Content-Type HTML header field, an attacker could circumvent this restriction, and specify the application that should be invoked to process a particular file. IE would comply, even if the application was listed as unsafe.
  • A vulnerability that could enable a web page to run a script even if the user has disabled scripting. IE checks for the presence of scripts when initially rendering a page. However, the capability exists for objects on a page to respond to asynchronous events; by misusing this capability in a particular way, it could be possible for a web page to fire a script after the page has passed the initial security checks.
  • A newly discovered variant of the "Frame Domain Verification" vulnerability discussed in Microsoft Security Bulletin MS01-058. The 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 use the Document.open function to pass information from the latter to the former. This could enable the web site operator to read, but not change, any file on the userís local computer that could be opened in a browser window. In addition, this could be used to mis-represent the URL in the address bar in a window opened from their site.

Mitigating factors:

Buffer Overrun in HTML Directive:

  • The vulnerability could not be exploited if the "Run ActiveX Controls and Plugins" security option were disabled in the Security Zone in which the page was rendered. This is the default condition in the Restricted Sites Zone, and can be disabled manually in any other Zone.
  • Outlook 98 and 2000 (after installing the Outlook Email Security Update), Outlook 2002, and Outlook Express 6 all open HTML mail in the Restricted Sites Zone. As a result, customers using these products would not be at risk from email-borne attacks.
  • The buffer overrun would allow code to run in the security context of the user rather than the system. The specific privileges the attacker could gain through this vulnerability would therefore depend on the privileges accorded to the user.

File Reading via GetObject function:

  • This vulnerability could only be used to read files. It could not be used to create, change, delete, or execute them.
  • The attacker would need to know the name and location of the file on the user's computer.
  • Some files that would be of interest to an attacker Ė most notably, the SAM Database Ė are locked by the operating system and therefore could not be read even using this vulnerability.
  • The email-borne attack scenario would be blocked if the user were using any of the following: Outlook 98 or 2000 with the Outlook Email Security Update installed; Outlook 2002; or Outlook Express 6.
  • The web-based attack scenario could be blocked by judicious use of the IE Security Zones mechanism such as using the Restricted Sites zone.

File Download Dialogue Spoofing via Content-Type and Content-Disposition fields:

  • Exploiting this vulnerability would not give an attacker the ability to force code to run on a userís system. It would only enable the attacker to misrepresent the file name and type in the File Download dialogue. The download operation would not occur without the userís approval, and the user could cancel at any time.
  • The vulnerability could not be exploited if File Downloads have been disabled in the Security Zone in which the e-mail is rendered. This is not a default setting in any zone, however.
  • On versions of IE prior to 6.0, the default selection in the file download dialogue is to save, rather than open, the file. (In IE 6.0, the default is to open the file; however, this behavior is inappropriate, and the patch changes IE 6.0 to conform with the behavior of previous versions).

Application invocation via Content-Type field:

  • An attacker could only exploit this vulnerability if the application specified through the Content-Type field was actually installed on the userís system.
  • The vulnerability does not provide any way for the attacker to inventory the applications installed on the userís system and select one, nor does it provide any way to force the user to install a particular application.
  • The vulnerability would not provide any way to circumvent the security features of the application or to reconfigure it.
  • Outlook 2002 users who have configured Outlook to render HTML mail as plaintext would be at no risk from attack through HTML mail.

Script execution:

  • This vulnerability extends only to allowing scripts to run Ė it does not allow any other security restrictions to be bypassed. So, for instance, although an attacker could use this vulnerability to run a script, the script would still be subject to all other expected security settings.

Frame Domain Verification Variant via Document.Open function:

  • The vulnerability could only be used to view files. It could not be used to create, delete, modify or execute them.
  • The vulnerability would only allow an attacker to read files that can be opened in a browser window, such as image files, HTML files and text files. Other file types, such as binary files, executable files, Word documents, and so forth, could not be read.
  • The attacker would need to specify the exact name and location of the file in order to read it.

Severity Rating:
Buffer Overrun in HTML Directive:

 

Internet Servers

Intranet Servers

Client Systems

Internet Explorer 5.01

None

None

None

Internet Explorer 5.5

Critical

Critical

Critical

Internet Explorer 6.0

Critical

Critical

Critical


File Reading via GetObject function:

 

Internet Servers

Intranet Servers

Client Systems

Internet Explorer 5.01

Moderate

Moderate

Critical

Internet Explorer 5.5

Moderate

Moderate

Critical

Internet Explorer 6.0

Moderate

Moderate

Critical


File Download Dialogue Spoofing via Content-Type and Content-ID fields:

 

Internet Servers

Intranet Servers

Client Systems

Internet Explorer 5.01

Moderate

Moderate

Moderate

Internet Explorer 5.5

Moderate

Moderate

Moderate

Internet Explorer 6.0

Moderate

Moderate

Moderate


Application Invocation via Content-Type field:

 

Internet Servers

Intranet Servers

Client Systems

Internet Explorer 5.01

Moderate

Moderate

Moderate

Internet Explorer 5.5

Moderate

Moderate

Moderate

Internet Explorer 6.0

Moderate

Moderate

Moderate


Script Execution:

 

Internet Servers

Intranet Servers

Client Systems

Internet Explorer 5.01

None

None

None

Internet Explorer 5.5

Moderate

Moderate

Moderate

Internet Explorer 6.0

Moderate

Moderate

Moderate


Frame Domain Verification Variant via Document.open function:

 

Internet Servers

Intranet Servers

Client Systems

Internet Explorer 5.01

None

None

None

Internet Explorer 5.5

Moderate

Moderate

Critical

Internet Explorer 6.0

Moderate

Moderate

Critical


Aggregate severity of all vulnerabilities eliminated by patch:

 

Internet Servers

Intranet Servers

Client Systems

Internet Explorer 5.01

Moderate

Moderate

Critical

Internet Explorer 5.5

Critical

Critical

Critical

Internet Explorer 6.0

Critical

Critical

Critical

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.

Vulnerability identifier:

Tested Versions:
The following table indicates which of the currently supported versions of Internet Explorer are affected by the vulnerabilities. Versions of IE prior to 5.01 Service Pack 2 are no longer eligible for
hotfix support. IE 5.01 SP2 is supported only via Windowsģ 2000 Service Packs and Security Roll-up Packages.

 

IE 5.01 SP2

IE 5.5 SP1

IE 5.5 SP2

IE 6.0

Buffer overrun

No

Yes

Yes

Yes

File reading via GetObject function

Yes

Yes

Yes

Yes

File download spoofing via Content-Type and Content-ID fields

Yes

Yes

Yes

Yes

Application Invocation via Content-Type field

Yes

Yes

Yes

Yes

Script execution

No

Yes

Yes

Yes

Frame Domain Verification Variant via Document.open function

No

Yes

Yes

Yes

Frequently asked questions

What vulnerabilities are eliminated by this patch?

This is a cumulative patch that, when applied, eliminates all known security vulnerabilities affecting Internet Explorer 5.01, 5.5 and 6.0. In addition to eliminating all previously discussed vulnerabilities versions, it also eliminates six new ones:

  • A vulnerability that could enable an attacker to take any action on another userís system that the user himself could take.
  • A vulnerability through which an attacker could read files from another userís system.
  • A vulnerability that could assist an attacker in convincing a user to download or run an unsafe file.
  • A vulnerability through which an attacker could start an application on another userís system.
  • A vulnerability that could enable a web page to flout one of the security settings a user had selected.
  • A newly discovered variant the "Frame Domain Verification" vulnerability discussed in Microsoft Security Bulletin MS01-058.






Whatís the scope of the first vulnerability?

This is a buffer overrun vulnerability. By creating a specially formed web page and either posting it on a web site or sending it to a user as an HTML mail, it could be possible for an attacker to take action on another userís system, including adding, creating or deleting files, communicating with web sites, or reformatting the hard drive.

The vulnerability is subject to several mitigating factors:

  • The email-borne attack scenario would be blocked if the user were using any of the following: Outlook 98 or 2000 with the Outlook Email Security Update installed; Outlook 2002; or Outlook Express 6.
  • The web-based attack scenario could be blocked by judicious use of the IE Security Zones mechanism.
  • An attacker who successfully exploited this vulnerability could gain the same privileges as the legitimate user, but not system-level privileges. If the user had only few privileges on the system, the attacker would gain only those privileges; on the other hand, if the user had more privileges, the attacker would gain these as well.

What causes the vulnerability?

The vulnerability results because of an unchecked buffer in the implementation of an HTML directive that allows a web page to incorporate a document. By creating a web page that invokes this directive in the right way, an attacker could overrun the buffer and cause any desired code to run on the userís system.

What could this vulnerability enable an attacker to do?

An attacker could use this vulnerability to modify the functionality of IE while it was running. Because IE runs in the userís security context, this would enable the attacker to do anything on the userís system that the user himself could do. The specific actions the attacker could perform would depend on the privileges the user had on the system. If the user had few privileges, the attacker might be able to take relatively few actions; on the other hand, if the user had administrative privileges, the attacker could gain complete control over the system.

How could the attacker exploit the vulnerability?

The attacker would need to create a web page that, when opened, would invoke the HTML directive we discussed above, and cause the buffer overrun to occur. The attacker would likely use either of two strategies to cause another user to open the page:

  • Host the page on a web site. If a user visited the site and opened the web page, the page would attempt to exploit the vulnerability.
  • Send the page to a user as an HTML mail. If the recipient opened the mail, it would attempt to exploit the vulnerability.

In both of the scenarios, you said the web page would attempt to exploit the vulnerability. What's the significance of the word "attempt"?

A web page could only exploit the vulnerability if a particular security setting Ė "Run ActiveX Controls and Plugins" Ė has been enabled. If itís been disabled, the attacker couldn't exploit the vulnerability. This setting is enabled in some IE Security Zones, but disabled in others.

How great a risk does the web-borne scenario pose?

The principal advantage of the web-borne scenario to the attacker is that, by default, all Internet web sites reside in the Internet Zone, and the ďRun ActiveX Controls and Plugins" setting is enabled there. This means that unless a user took special steps Ė either by disabling the setting in the Internet Zone or moving the attackerís web site into the Restricted Sites Zone Ė theyíd be vulnerable. The disadvantage to the attacker is that the web-borne scenario would require enticing the user to the web site. This could require significant social engineering.

How great a risk does the mail-borne scenario pose?

The advantage to the attacker of the mail-borne scenario is that it could be used to attack a large number of users. The attacker could create a mail that exploits the vulnerability, and send it to as many users as desired. They would only need to open the mail to potentially be affected by it.

The disadvantage to the attacker is that many usersí systems are configured to open HTML mail in the Restricted Sites Zone, where the "Run ActiveX Controls and Plugins" setting is disabled by default. Specifically, the Outlook Email Security Update configures Outlook 98 or 2000 to open mail in the Restricted Sites Zone. Outlook 2002 and Outlook Express 6 open mail there by default.

Iím using one of the email products you listed above. Does this mean I donít need the patch?

The Outlook Email Security Update, Outlook 2002, and Outlook Express 6 will protect you against the mail-borne attack scenario. However, we still recommend that you install the patch, to ensure that youíre protected against the web-based scenario.

How does the patch eliminate this vulnerability?

The patch restores proper buffer handling to the HTML directive at issue in this vulnerability.






Whatís the scope of the second vulnerability?

This vulnerability could allow an attacker to view files on the computer of another user. It could be exploited via either of two scenarios. An attacker could send a specially formatted HTML mail to another user which, when opened, would send a fileís contents to the attacker; or the attacker could set up a web site that, when visited by a user, would read a file on the userís computer.

There a number of significant mitigating factors associated with this vulnerability:

  • It could only be used to read files. It could not be used to create, change, delete, or execute them.
  • The attacker would need to know the name and location of the file on the user's computer.
  • The vulnerability could only be used to read files that arenít locked by the operating system. Some files that would be of interest to an attacker would therefore be unavailable even using this vulnerability.
  • The email-borne attack scenario would be blocked if the user were using any of the following: Outlook 98 or 2000 with the Outlook Email Security Update installed; Outlook 2002; or Outlook Express 6.
  • The web-based attack scenario could be blocked by judicious use of the IE Security Zones mechanism.

What causes the vulnerability?

The vulnerability results because the GetObject functionís security checks can be spoofed if called using an argument thatís been malformed in a particular way. This flaw could allow a web page to open and read files on a userís system.

Whatís the GetObject function?

GetObject is a scripting command thatís used to establish contact with data files and other operating system objects. Before a script can work with such an object, it first has to use the GetObject function to access it.

Whatís wrong with the GetObject function?

When GetObject is invoked by a web page, it performs a series of security checks designed to ensure that the page can only use the object in ways that pose no threat to the userís data. However, by specifying the object in a particular way, itís possible to force GetObject to perform these checks incorrectly, and give the web page the ability to read files on the userís computer.

What would this vulnerability enable an attacker to do?

An attacker could use this vulnerability to read Ė but not create, delete or modify Ė files on another userís system.

How could the attacker exploit the vulnerability?

The attacker would need to create a web page that, when opened, invokes the GetObject function to open a file on the userís system. By specifying the file name as discussed above, the web page would exploit the vulnerability and gain the ability to read a file on the system of any user who opened the page. The attacker would likely deliver the page through one of two strategies:

  • Hosting the page on a web site. If a user visited the site and opened the web page, the page would attempt to exploit the vulnerability.
  • Sending the page to a user as an HTML mail. If the recipient opened the mail, it would attempt to exploit the vulnerability.

What files could the attacker read through the vulnerability?

The vulnerability can be used to read any file on the userís system, but the attacker would need to specify the exact location of the file. This would make it harder to exploit the vulnerability for several reasons:

  • It could be difficult for the attacker to guess the names and locations of files that other users have created. The vulnerability doesnít provide any way for the attacker to enumerate the files on the system and select one for reading.
  • Even though many system files are located in well-known places, these places vary from operating system to operating system. That is, a file thatís located in one place in Windows 95 might be located in an entirely different place in Windows XP. The web page would have no way to tell which operating system a particular user was using.

I heard that an attacker could use this vulnerability to obtain my systemís login password. Is this correct?

No. Itís true that Windows NTģ, Windows 2000, and Windows XP store an encrypted version of user passwords in a system data structure called the SAM Database, and that this database takes the form of a system file. Itís also true that if an attacker obtained a copy of the SAM Database, it would be possible to subject it to a password cracking attack in which the attacker simply guesses passwords until the right one is found.

However, this vulnerability does not provide a way for an attacker to read the SAM Database. The operating system locks this file (and other important system files) and doesnít allow any other processes to read it. So, even using this vulnerability, an attacker could not gain a copy of the SAM Database and crack a userís password.

How great a risk do the web-borne and mail-borne attack vectors pose?

The web-borne attack scenario would allow the attacker to attack targets of opportunity (i.e., users who happened to visit the web site). However, it wouldnít provide any way for the attacker to force specific users to visit the site.

The mail-borne scenario would allow the attacker to attack selected users. However, it would require that the attacker know these usersí email addresses. In addition, the mail-borne scenario would fail if the user had installed the Outlook Email Security Update on Outlook 98 or 2000; was using Outlook 2002 (which includes the Outlook Email Update by default); or was using Outlook Express 6.

Iím using one of the email products you listed above. Does this mean I donít need the patch?

The Outlook Email Security Update, Outlook 2002, and Outlook Express 6 will protect you against the mail-borne attack scenario. However, we still recommend that you install the patch, to ensure that youíre protected against the web-based scenario.

How does the patch eliminate this vulnerability? The patch causes the GetObject function to correctly perform the expected security checks even in the case in which the file name is malformed as described above.

[bink@bink.nu] This is a posting from the
BinkNewsFlash List. To unsubscribe, forward this message (Including these lines) to <unsub-BinkNewsFlash@lyris.sunbelt-software.com>.

[bink@bink.nu] This is a posting from the
BinkNewsFlash List. To unsubscribe, forward this message (Including these lines) to <unsub-BinkNewsFlash@lyris.sunbelt-software.com>.