Internet Explorer MIME Handling Enforcement

The Microsoft Windows Server 2003 InternetExplorer Enhanced Security Configuration component (also known as
Microsoft InternetExplorer hardening) reduces a server’s vulnerability to attacks from Web content by applying more
restrictiveInternetExplorer security settings that disablescripts, ActiveX components,and file downloads for resources in the
Internet security zone. As a result, many of thesecurity enhancements included in thelatest release of InternetExplorer will
not beas noticeablein Windows Server 2003 Service Pack 1.For example, the new InternetExplorer Information Bar and
Pop-up Blocker features will not be used unless thesiteis in a zone whosesecurity setting allows scripting. If you are not
using theenhanced security configuration on your server, thesefeatures will function as they do in Windows XP Service
Pack 2.
What does MIME Handling Enforcement do?
InternetExplorer uses MultipurposeInternet Mail Extensions (MIME) typeinformation to decide how to handlefiles that have
been sent by a Web server.For example, when thereis a HypertextTransfer Protocol (HTTP) request for .jpg files, when they
arereceived, they will generally be displayed to the user in an InternetExplorer window. If InternetExplorer receives an
executablefile, InternetExplorer generally prompts the user for a decision on how to handlethefile.
InternetExplorer in Windows Server 2003 with Service Pack 1 will follow stricter rules than InternetExplorer in Windows
Server 2003.Theserules are designed to protect users from accidentally downloading or executing a dangerous file dueto
misleading MIME or file nameextension information.
Who does this feature apply to?
Web developers need to beaware of these new restrictions to plan changes or workarounds for any possibleimpact to their
Web site.
Application developers should review this featureto plan to adopt changes in their applications.Thefeatureis notenabled for
non-InternetExplorer processes by defaultand developers will need to register their applications to takeadvantage of the
changes.
End users will beaffected by sites or applications thatare not compatible with thesestricter rules.
What new functionality is added to this feature in Windows Server 2003 Service Pack 1?
MIME-handling file type agreement enforcement
Detailed description
When files areserved to theclient, InternetExplorer uses thefollowing pieces of information to decide how to handlethefile:
File nameextension, thecorresponding ProgID and CLSID for theregistered handler of that file nameextension.
Content-Typefrom the HTTP header (MIME type), thecorresponding ProgID,and CLSID for theregistered handler of that
Content or MIME type.
Content-Disposition from the HTTP header.
Results of the MIME sniff.
InternetExplorer is morerestrictiveaboutexecuting a downloaded filethat could be dangerous than it was in Windows
Server 2003.
InternetExplorer will enforceconsistency between how a fileis handled in the browser and how it is handled in the Windows
shell. As thefileis downloaded into thecache, InternetExplorer will comparethe MIME-type of thecachefileto theextension
of thecachefile. If thereis a mismatch between the MIME-typeand thefile nameextension, InternetExplorer will attempt to
reconcilethat mismatch by renaming thefilein thecache.
Beforea fileis loaded in its MIME handler or executed by its extension handler, InternetExplorer will comparethe CLSIDs of the
MIME handler and theextension handler. If thereis still a mismatch between thetwo handlers, InternetExplorer will imposea
mandatory prompt for the user to confirm that the user wants to load thefilein the MIME handler. If the MIME handler rejects
the mismatched file, InternetExplorer will show a download error dialog and notautomatically executethefilein the Windows
shell extension handler but the dialog will allow saving thefile.
Thereis a related but separatechangeto preventexecution of potentially corrupt files in their shell extension handlers. Internet
Explorer will show the download error dialog for any filethat is rejected by its MIME handler with theerror code
E_Cannot_Load_Data and will notexecutethat filein its shell extension handler regardless of MIME-type or file nameextension.
Thesechanges do notaffect cases wherea “Content-disposition=attachment” HTTP header is used for thefile. In those
cases, thefile name or extension suggested by theserver is considered final and thefilecan beexecuted regardless of
MIME/extension mismatch if the user chooses to accept thefile download prompt.
Why is this change important?
If filetypeinformation is misreported by theserver and that information is saved to thecomputer,a dangerous filecould be
incorrectly executed later.For example, InternetExplorer might download a filethatappears to bea text file. If thefilecan’t be
loaded by its MIME handler and has a .doc file nameextension, the.doc file might run in an application such as Microsoft Word
without prompting the user. In Microsoft Word, thefile may beableto useactivecontent, such as a macro, to run a program
(such as a virus) on the user’s machine.
What works differently?
InternetExplorer will now attempt to rename downloaded files in theInternetExplorer cacheto have matching content types
and extensions to protectagainst files that mislead the user about their type.
InternetExplorer will prompt the user to download thefileand will no longer execute MIME and extension mismatched files
thatarerejected by theregistered MIME handler.
InternetExplorer will also notexecutea filein its shell handler if the E_Cannot_Load_Data error code was reported by its MIME
handler.
Instead of executing such a filein theshell-handler, InternetExplorer will show an error dialog and givethe user an option to
savethefile.
Web developers can isolate nonworking applications dueto this behavior by switching off thefunctionality,as covered in the
Settings section later in this document.
How do I resolve these issues?
Web developers must changetheir Web servers to host files, using consistent content-type headers and file nameextensions. If
this is not possible,Web developers can usethe “Content-disposition=attachment” HTTP header to directly send thefileto
its extension handler rather than to the MIME handler. Notethat file downloads with the “Content-disposition=attachment”
header will prompt the user to open or savethefile.
If you have developed a MIME handler and intentionally rely on InternetExplorer to executefiles thatyour MIME handler
rejects,you will need to makechanges in your MIME handler to accommodatethis change.The most securechange would be
to natively handlethefile directly in the MIME handler rather than rejecting thefile.
For somescenarios, it may not be possibleto changethe behavior of the MIME handler to natively handle downloaded files. In
thosescenarios, therearea few options.
You may chooseto develop a MIME handler and file nameextension handler thatare both part of thesame CLSID; Internet
Explorer will accept the CLSID match and therefore not prompt the user to download thefile or block thefilefrom execution in
theextension handler.
If the MIME handler does not need to beloaded and will causeerrors dueto MIME and extension mismatch, the developer can
mark the MIME handler to beignored by InternetExplorer in thecase of a MIME and extension mismatch.For example, if the
MIME handler for a certain media MIME type has a mismatched extension and needs to beexecuted directly to be played
properly, the developer can mark the ProgID of their MIME handler to beignored on the mismatch when the media file name
extension belongs to a different ProgID.To do this, the developer sets thefollowing valuein theregistry with the MIME handler
to ignore:
HKEY_CLASSES_ROOT\PROG_ID_OF_MIMEHANDLER_TO_IGNORE\”PreferExecuteOnMismatch”=DWORD:00000001
If neither of thesesolutions is viable, developers should notify their users of theincompatibility and explain to the user how to
savethe mismatched fileto thefilesystem and then launch it manually.
If your scenario is affected by unwanted file-download prompts because of an irreconcilable MIME/extension mismatch,you
can register you MIME handler ProgID to bypass all download prompts including the new prompt on mismatch.
Before doing this,you should confirm thatyour MIME handler can securely deal with any filethat is delegated to it.For
example,you should confirm thatyour handler would never allow an attacker to gain more privilegethan allowed by thezone
of the originating file.This should be donethrough threat modeling,codereview for securefailure modes,and buffer overruns.
If you determinethatyour MIME handler is capable of safely handling any filethat might be delegated to it,you can register
your handler to circumvent download prompts by adding a new key to one of thefollowing registry settings:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\InternetSettings\Secure_Mi
me_Handlers
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings\Secure_Mim
e_Handlers
Thekey should be named with the ProgID of your MIME handler and havea DWORD=00000001.
MIMEsniffing file type elevation
Detailed description
One of the backup criteria for determining a filetypeis theresult of the MIME sniff. By examining (or sniffing) a file, Internet
Explorer can recognizethe bit signatures of certain types of files. In Windows Server 2003 Service Pack 1, InternetExplorer
MIME sniffing will not promotefiles of typetext\plain to more dangerous filetypes in the Restricted Sites zone.For example,
files thatarereceived as plain text but that include HTML code will not be promoted to the HTML type, which could contain
activecontent.
Why is this change important?
This change provides users additional defensein depth against malicious content posted on a friendly Web server wherethe
server serves files with content-type=text\plain for a file butan attacker has managed to load HTML with activecontent into
thefile.
What works differently?
Web servers that do not includethecorrect Content-Type header with their files and that use nonstandard file nameextensions
for HTML pages now may havetheir pages rendered as plain text rather than HTML.
How do I resolve these issues?
You should configure Web servers to usethecorrect Content-Type headers or you can namethefiles with theappropriatefile
nameextension for theapplication that should handlethefile.
What settings are added or changed in Windows Server 2003 Service Pack 1?
Setting
name
Location Previous
default
value
Default
value
Possible
values
IExplore.exe
Explorer.exe
HKEY_LOCAL_MACHINE(or Current User)\Software\Microsoft \Internet
Explorer\Main \FeatureControl \FEATURE_MIME_HANDLING\
None 1 0 – Off
1 – On
IExplore.exe
Explorer.exe
HKEY_LOCAL_MACHINE(or Current User)\Software\Microsoft \Internet
Explorer\Main \FeatureControl\FEATURE_MIME_SNIFFING\
None 1 0 – Off
1 – On
MIME Sniffing behavior per-zone settings
The new MIME sniffing restriction is controlled by the Open files based on content, not file extension security setting
which can beenabled or disabled for individual security zones.Thefollowing table provides a reference of the default settings
per security zone:
Security zone “Open files based on content, not file extension” Default security setting
Restricted Sites zone Disable
Internet zone Enable
Intranet zone Enable
Trusted Sites zone Enable
Do I need to change my code to work with Windows Server 2003 Service Pack 1?
You should configure Web servers to usethecorrect Content-Type headers. You can also namethefiles with theappropriate
file nameextension for theapplication that should handlethefile.