Privacy and Legal Notice
[CIAC] INFORMATION BULLETIN
M-027: Microsoft Internet Explorer-Content Type Falsification (Three
Vulnerabilities)
[Microsoft Security Bulletin MS01-058]
December 17, 2001 22:00 GMT
------------------------------------------------------------------------
PROBLEM: Users of Microsoft Internet Explorer versions 5.5 and
6.0 can be misled into executing code, exposing
information, or accepting unsafe file types.
PLATFORM: Microsoft Internet Explorer versions 5.5 and 6.0.
DAMAGE: Depending on which vulnerability is exploited, an
attacker can cause the system to run arbitrary code,
view files on the visiting computer, or mislead a user
into executing an unsafe file.
SOLUTION: Apply the patch as directed in Microsoft bulletin
MS01-058.
------------------------------------------------------------------------
VULNERABILITY The risk is MEDIUM. The third vulnerability can use
ASSESSMENT: e-mail to fool a user into executing an unsafe file.
------------------------------------------------------------------------
LINKS:
CIAC http://www.ciac.org/ciac/bulletins/m-027.shtml
BULLETIN:
ORIGINALhttp://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS01-058.asp
BULLETIN:
PATCHES:http://www.microsoft.com/windows/ie/downloads/critical/Q313675/default.asp
------------------------------------------------------------------------
[***** Start Microsoft Security Bulletin MS01-058 *****]
Microsoft Security Bulletin MS01-058
13 December 2001 Cumulative Patch for IE
Originally posted: December 13, 2001
Summary
Who should read this bulletin: Customers using Microsoft® Internet Explorer.
Impact of vulnerability: Run code of attacker’s choice.
Maximum Severity Rating: Critical
Recommendation: Customers using IE should install the patch immediately.
Affected Software:
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.5 and IE 6. In addition,
it eliminates three newly discovered vulnerabilities.
The first vulnerability involves a flaw in the handling of the
Content-Disposition and Content-Type header fields in an HTML stream. These
fields, the hosting URL, and the hosted file data determine how a file is
handled upon download in Internet Explorer. A security vulnerability exists
because, if an attacker altered the HTML header information in a certain way,
it could be possible to make IE believe that an executable file was actually
a different type of file -- one that it is appropriate to simply open without
asking the user for confirmation. This could enable the attacker to create a
web page or HTML mail that, when opened, would automatically run an executable
on the user's system. This vulnerability affects IE 6.0 only. It does not
affect IE 5.5.
The second vulnerability is a newly discovered variant of the "Frame Domain
Verification" vulnerability discussed in Microsoft Security Bulletin MS01-015.
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 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. This vulnerabilty affects both
IE 5.5 and 6.0.
The third vulnerability involves a flaw related to the display of file names in
the File Download dialogue box. When a file download is initiated, a dialogue
provides the name of the file. However, in some cases, it would be possible for
an attacker to misrepresent the name of the file in the dialogue. This could be
invoked from a web page or in an HTML email in an attempt to fool users into
accepting unsafe file types from a trusted source. This vulnerabilty affects
both IE 5.5 and 6.0.
Mitigating factors:
File Execution Vulnerability:
The vulnerability could not be exploited if File Downloads have been disabled in
the Security Zone from which the file is being received. In most attempts to
maliciously exploit this vulnerability the file would be received from the Internet
or Intranet zone. Therefore, disabling File Downloads in these zones can protect
customers. This is not the default setting for either of these zone, however.
This affects IE 6.0 only.
Frame Domain Verification Variant:
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 file
types, such as binary files, executable files, Word documents, and so forth, could
not be read.
The attacker would have to have knowledge of the exact file name and location in
other to successfully read the file on the local system.
File Name Spoofing Vulnerability:
The determination on choosing to accept a file download from an Internet site
should always be based on the trustworthiness of the source and not on the file
type. File downloads should never be accepted from an untrusted source, no matter
how harmless the type may appear to be.
Severity Rating:
File Execution vulnerability:
Internet Servers Intranet Servers Client Systems
Internet Explorer 6.0 Critical Critical Critical
Frame Domain Verification Variant:
Internet Servers Intranet Servers Client Systems
Internet Explorer 5.5 Moderate Moderate Moderate
Internet Explorer 6.0 Moderate Moderate Moderate
File Name Spoofing Vulnerability:
Internet Servers Intranet Servers Client Systems
Internet Explorer 5.5 Moderate Moderate Moderate
Internet Explorer 6.0 Moderate Moderate Moderate
Aggregate severity of all vulnerabilities eliminated by patch:
Internet Servers Intranet Servers Client Systems
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. For the File Execution vulnerability, the vulnerability by-passes
the security control for making trust decisions regarding file downloadings. For
the Frame Domain Verification variant, the file would have to be of a type that could
be displayed in a browser window and the full path and file name would have to be
known to the attacker. For the File Name Spoofing vulnerability, file downloads from
the Internet should be trusted on the basis of their source and not the file type.
Finally, this aggregate rating includes ratings for issues addressed from previous
patches which are superceded by this patch.
Vulnerability identifiers:
File Execution Vulnerability: CAN-2001-0727
Frame Domain Verification Variant: CAN-2001-0874
File Name Spoofing Vulnerability: CAN-2001-0875
Tested Versions:
Microsoft tested Internet Explorer 5.5 and 6.0 to assess whether they are affected
by these vulnerabilities. Previous versions are no longer eligible for hotfix
support.
Frequently asked questions
What vulnerabilities are eliminated by this patch?
This patch, when installed, eliminates all known security vulnerabilities affecting
Internet Explorer 5.5 and 6.0. In addition to eliminating all previously discussed
vulnerabilities affecting these versions, it also eliminates three new ones:
A vulnerability involving the handling of downloads that can lead to automatic
code execution.
A newly discovered variant of the the "Frame Domain Verification" vulnerability
discussed in Microsoft Security Bulletin MS01-015.
A vulnerability involving the display of file names in the File Download dialogue box.
What’s the scope of the first vulnerability?
This vulnerability could enable an attacker to potentially run a program of her
choice on the machine of another user. Such a program would be capable of taking
any action that the user himself could take on his machine, including adding,
changing or deleting data, communicating with web sites, or reformatting the hard
drive.
In order for the attacker to successfully attack the user via this vulnerability,
she would need to craft a specially formed web page and host the malicious
executable on a site that is accessible to the victim, either on the Internet or
on their local network. She would then have to force the user to view the web page.
She could do this either by enticing the user to go to her site, or by sending the
web page as an HTML email. When the web page on the site finished loading, the file
could execute automatically. In the case of an HTML email, when the user opened the
mail or viewed it in a preview pane, the file could execute automatically.
What causes the vulnerability?
The vulnerability results because it is possible to malform the HTML header
information in a web page, in such a way as to misrepresent the filetype of a file
that’s referenced by the HTML page. If done properly, this could cause IE to handle
the file inappropriately when opening the HTML page. In the worst case, a page
could misrepresent an executable file as one that’s safe to open without user
confirmation, causing IE to automatically run an executable file when the HTML page
was opened.
What are HTML headers?
HTML headers are fields within web pages that tell the browser how to handle certain
aspects of the page. For instance, HTML headers may tell the browser how to render
the page or interpret data on it. The vulnerability at issue here results because of
a flaw in the way IE handles two HTML headers fields that tell it how to handle a
non-HTML file referenced by a web page.
What do you mean by "a non-HTML file referenced by a web page"?
Web pages usually consist of HTML files – that is, files that contain commands that
tell the browser what text to display and how to display it. However, in some cases,
a web page may need to refer to a file that consists of other data. For instance, a
web page might need to refer to a streaming media file, a text file, a program file,
or some other type of data.
Early browsers were built to read and display only HTML; all other files would be
downloaded to the local system and the user would then open those files using the
appropriate application. However, to provide a richer browsing experience, browser
capabilities have been extended so that they can handle non-HTML files directly.
For instance, IE handles .DOC files by opening them directly in WordPad or Word,
and handles streaming media files by starting the user’s media player and playing
the file.
How does IE determine the appropriate way to handle a non-HTML file?
Most modern browsers, including IE, use Multipurpose Internet Mail Extensions (MIME)
information to handle non-HTML data. MIME types were first developed so that Internet
mail clients could handle file attachments intelligently, but their use has been
extended so that browsers too can use them to handle files intelligently.
When a web page instructs IE to download a non-HTML page, it provides the MIME type
information via two HTML header fields, known as Content-Disposition and Content-Type.
Once IE has determined the MIME type of the non-HTML file, it consults an internal
table that tells it what the right way to handle the file is.
What are the Content-Disposition and Content-Type header fields?
The Content-Disposition and Content-Type header fields are used in conjunction to
provide the MIME type information to the browser. The Content-Disposition field
alerts the browser that non-HTML data is coming. The Content-Type field then provides
the MIME type information.
So, is the problem that IE is handling certain MIME types incorrectly?
No. IE handles files appropriate for their MIME types – the problem in this case is
that it’s possible to convince IE that a file is of a different MIME type than it
really is, by altering the Content-Disposition and Content-Header fields. IE would
then handle the file in the wrong way, potentially with dangerous results.
What would this vulnerability enable an attacker to do?
An attacker could use this vulnerability to make a program run when a user opened
a web page. Specifically, the attacker could create a program and host it on a web
site, then create a web page that would open the program. By altering the
Content-Disposition and Content-Header fields in a certain way, the attacker could
tell IE that the program was actually a different type of file – one that’s safe
to simply open.
The vulnerability could be exploited through either of two scenarios. The attacker
could simply host the program and the web page on a web site, in order to attack
anyone who visited the site. Alternatively, she could send the web page as an HTML
mail; in this case, the program would be automatically executed when the recipient
opened the mail.
Why would an attacker be able to exploit this via HTML email?
HTML mails are essentially web pages that are sent by mail. By creating a web page
that exploits the vulnerability, and then sending it as an HTML mail, an attacker
could mount essentially the same attack as discussed above via a web site. When
the mail was opened, either by double-clicking the message or viewing it in a
preview pane, the file would download and execute automatically.
Would the user have any opportunity to prevent the program from running?
He might. While the file was being downloaded, a dialogue would be displayed that
would enable the user to cancel the download. If he cancelled the download before
it was completed, the program could not run. However, how long the button would be
available to halt the process would depend on the speed of the download and the
size of the file.
What kind of actions could the executable take if it ran?
The executable would be able to take any action that the user himself could take
on his system. The exact actions it could take would depend on the privileges of
the user when they viewed the page and ran the attachment. If they were running
in as an unprivileged user, it might be able to do very little. However, if the
user were an administrator on his system, the attachment would be able to do
virtually anything, including reformatting the hard drive.
Could a web page and executable accidentally be created that would exploit this
vulnerability?
No. To create such a web page and executable, an attacker would need to craft
the page and executable in a particular, purposeful way. This could not be done
accidentally.
You said that the attacker would have to "post a malicious executable on a
server", what does that mean?
For the attack to succeed, the malicious file would have to be downloaded to
the user's computer. To accomplish this, the file would have to be placed in a
location from which the user would be able to access it. If that server were
unreachable for any reason, the attack would fail. This means, for example,
that if a known server were hosting this malicious executable on the Internet,
a company could protect its users by blocking access to that server. If a
server on the local Intranet were hosting the executable, the threat would be
eliminated if that server were removed from the network or made inaccessible
through other means.
So, for the attack to succeed, the attacker needs to be able to download their
file to my computer?
Correct. If the malicious executable cannot be downloaded for any reason, the
attempted attack would fail. This offers an additional means of protecting
against the attack.
If File Downloads are disabled in the Security Zone from which the malicious
code was being received, the attack would fail. Since most attempts to exploit
this vulnerability would originate from the Internet, which is governed by the
Internet Zone, or the local network, which is governed by the Intranet Zone,
disabling file downloads in these zones would help to protect vulnerable
systems. However, this setting is not the default for either zone.
What versions of IE are affected by this?
IE 6.0 only is affected by this. IE 5.5 is not affected by this particular
vulnerability.
What does the patch do?
The patch eliminates the vulnerability by instituting proper checking for
incorrect Content-Disposition and Content-Type headers.
What’s the scope of the second vulnerability?
The second vulnerability is a new variant of the "Frame Domain Verification"
vulnerability originally discussed in Microsoft Security Bulletin MS01-015.
The vulnerability could allow a malicious web site operator to view files on the
computer of visiting user.
There a number of significant mitigating factors associated with this vulnerability:
It could only be used to read file – not create, change, delete, or execute them.
The attacker would need to know the name and location of the file on the user's computer
Even if successfully exploited, the attacker could only view files that can be opened in
a browser window, such as HTML files, image files, or text files.
The vulnerability requires Active Scripting in order to succeed. If the malicious site
were in a Security Zone that does not allow Active Scripting, the vulnerability could
not be exploited.
Where can I get more information on the "Frame Domain Verification" vulnerability?
Microsoft Security Bulletins MS00-033, MS00-055, MS00-093, and MS01-015 discuss the
vulnerability in detail.
Are there any differences between the new variant and the previous variants?
No. The scope of the new variant is exactly the same as for previous ones.
Does this patch eliminate the original variants as well as the new one?
Yes. It eliminates all known variants.
What’s the scope of the third vulnerability?
The third vulnerability could enable an attacker to cause the wrong name to appear in
a File Download dialogue box. An attacker could exploit this vulnerability in an
attempt to fool a user into downloading an unsafe file.
The vulnerability would not provide any way for the attacker to override normal system
behavior with respect to the download. That is, it would not provide a way for the
attacker to force the user to accept the download – the user could simply cancel the
operation via the dialogue box. Likewise, even if the user did choose to allow the
download to proceed, the attacker would have no way to make the file open – the default
action is to save, not run, the file.
What causes the vulnerability?
This vulnerability occurs because, when the IE File Download dialogue encounters certain
special characters, it stops displaying the file name. By carefully selecting a file
name and inserting such a character into it at the proper place, an attacker could cause
IE to display a misleading name for the file – one that the user might choose to trust.
What’s wrong with the way the File Download dialogue handles file names?
When a web page initiates a file download, IE displays a dialogue that shows the file
name and asks the user whether to save the file, open it, or cancel the download. By
design, IE should display the entire name. However, a vulnerability exists because IE
will actually stop displaying the name upon reaching certain special characters.
This could enable an attacker to cause only a subset of the name to be displayed. For
instance, suppose the attacker created a program named file.txt.exe. By inserting one
of the special characters at issue here after the “.txt”, the attacker could cause the
file name to be shown in the dialogue as “file.txt”, not “file.txt.exe”.
What could this enable an attacker to do?
It could potentially enable an attacker to create a web page that, when displayed,
would start a file download and display a misleading name for the file, in the hope
of convincing the user that it was safe to download. The page could be hosted on a web
server or sent to a user as an HTML mail.
Where would the file be located?
The file would need to be located on a server that the attacker controlled. If that
server couldn’t be reached for some reason, the attack would fail.
Would the web page be able to automatically start such a download?
Yes. By design, a web page can always initiate a file download. However, it’s important
to be specific about what that means. The user is still in control of whether the
download will proceed or not. That is, as soon as the file download starts, the File
Download dialogue is displayed, and the user has the opportunity to cancel the download.
Nothing in the vulnerability enables the attacker to prevent the user from simply choosing
“Cancel” at the download dialogue.
If the user did choose to let the download proceed, what would happen?
It would depend on the user’s choice. The default choice in the File Download dialogue
is to save the file to a location of the user’s choosing on the system. If the user
chose this option, the file would be stored on the system but would only run if the user
later located the file and deliberately ran it. On the other hand, if the user chose the
option to open it, the program would execute.
If the attacker can’t force the user to accept the download, and can’t force the program
to run, why is this a security vulnerability?
In the web-borne scenario, this doesn’t actually quality as a security vulnerability. IE
always lets the user identify the web site that he or she is visiting, and users should
always base trust decisions like this on the degree to which they trust the site. That is,
trust should be based on the source of the file, not what’s displayed in a dialogue.
However, the email-borne scenario is a different story, and is the reason why this
qualifies as a security vulnerability. It’s not possible to base trust on the source of
an email. Not only is it simple to spoof an email address, many viruses cause infected
systems to send copies of themselves to other users. That is, just because an email says
it came from someone you trust, it doesn’t mean that it actually did – and even if it
did come from that person’s email account, it doesn’t necessarily mean that the person
deliberately sent it.
What does the patch do?
The patch causes IE’s File Download dialogue to correctly handle special characters
within file names.
Patch availability
Download locations for this patch
Microsoft Internet Explorer 5.5 and 6.0:
http://www.microsoft.com/windows/ie/downloads/critical/Q313675/default.asp
Additional information about this patch
Installation platforms:
The IE 5.5 patch can be installed on IE 5.5 Service Pack 2.
The IE 6 patch can be installed on IE 6 Gold.
Inclusion in future service packs:
The fix for these issue will be included in IE 5.5 Service Pack 3, and IE 6 Service
Pack 1.
Reboot needed: Yes
Superseded patches: MS01-055.
Verifying patch installation:
To verify that the patch has been installed on the machine, open IE, select Help,
then select About Internet Explorer and confirm that Q313675 is listed in the Update
Versions field.
To verify the individual files, use the patch manifest provided in Knowledge Base
articles Q313675.
Caveats:
None
Localization:
Localized versions of this patch are available at the locations discussed in
"Patch Availability".
Obtaining other security patches:
Patches for other security issues are available from the following locations:
Security patches are available from the Microsoft Download Center, and can be most
easily found by doing a keyword search for "security_patch".
Patches for consumer platforms are available from the WindowsUpdate web site
All patches available via WindowsUpdate also are available in a redistributable form
from the WindowsUpdate Corporate site.
Other information:
Acknowledgments
Microsoft thanks Jouko Pynnonen of Oy Online Solutions Ltd for reporting this issue
to us and working with us to protect customers.
Support:
Microsoft Knowledge Base article Q313675 discusses this issue and will be available
approximately 24 hours after the release of this bulletin. Knowledge Base articles
can be found on the Microsoft Online Support web site.
Technical support is available from Microsoft Product Support Services. There is no
charge for support calls associated with security patches.
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:
V1.0 (December 13, 2001): Bulletin Created.
[***** End Microsoft Security Bulletin MS01-058 *****]
------------------------------------------------------------------------
CIAC wishes to acknowledge the contributions of Microsoft Corporation for
the information contained in this bulletin.
------------------------------------------------------------------------
CIAC services are available to DOE, DOE Contractors, and the NIH. CIAC can
be contacted at:
Voice: +1 925-422-8193 (7 x 24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@llnl.gov
World Wide Web: http://www.ciac.org/
http://ciac.llnl.gov
(same machine -- either one will work)
Anonymous FTP: ftp.ciac.org
ciac.llnl.gov
(same machine -- either one will work)
------------------------------------------------------------------------
This document was prepared as an account of work sponsored by an agency of
the United States Government. Neither the United States Government nor the
University of California nor any of their employees, makes any warranty,
express or implied, or assumes any legal liability or responsibility for
the accuracy, completeness, or usefulness of any information, apparatus,
product, or process disclosed, or represents that its use would not
infringe privately owned rights. Reference herein to any specific
commercial products, process, or service by trade name, trademark,
manufacturer, or otherwise, does not necessarily constitute or imply its
endorsement, recommendation or favoring by the United States Government or
the University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
------------------------------------------------------------------------
UCRL-MI-119788
[Privacy and Legal Notice]
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
