Internet Explorer MIME Handling Enforcement
Applies To: Windows Server 2003 with SP1
Note
The Microsoft Windows Server 2003 Internet Explorer Enhanced Security Configuration component (also known as Microsoft Internet Explorer hardening) reduces a server’s vulnerability to attacks from Web content by applying more restrictive Internet Explorer security settings that disable scripts, ActiveX components, and file downloads for resources in the Internet security zone. As a result, many of the security enhancements included in the latest release of Internet Explorer will not be as noticeable in Windows Server 2003 Service Pack 1. For example, the new Internet Explorer Information Bar and Pop-up Blocker features will not be used unless the site is in a zone whose security setting allows scripting. If you are not using the enhanced security configuration on your server, these features will function as they do in Windows XP Service Pack 2.
What does MIME Handling Enforcement do?
Internet Explorer uses Multipurpose Internet Mail Extensions (MIME) type information to decide how to handle files that have been sent by a Web server. For example, when there is a Hypertext Transfer Protocol (HTTP) request for .jpg files, when they are received, they will generally be displayed to the user in an Internet Explorer window. If Internet Explorer receives an executable file, Internet Explorer generally prompts the user for a decision on how to handle the file.
Internet Explorer in Windows Server 2003 with Service Pack 1 will follow stricter rules than Internet Explorer in Windows Server 2003. These rules are designed to protect users from accidentally downloading or executing a dangerous file due to misleading MIME or file name extension information.
Who does this feature apply to?
Web developers need to be aware of these new restrictions to plan changes or workarounds for any possible impact to their Web site.
Application developers should review this feature to plan to adopt changes in their applications. The feature is not enabled for non-Internet Explorer processes by default and developers will need to register their applications to take advantage of the changes.
End users will be affected by sites or applications that are not compatible with these stricter 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 are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file:
File name extension, the corresponding ProgID and CLSID for the registered handler of that file name extension.
Content-Type from the HTTP header (MIME type), the corresponding ProgID, and CLSID for the registered handler of that Content or MIME type.
Content-Disposition from the HTTP header.
Results of the MIME sniff.
Internet Explorer is more restrictive about executing a downloaded file that could be dangerous than it was in Windows Server 2003.
Internet Explorer will enforce consistency between how a file is handled in the browser and how it is handled in the Windows shell. As the file is downloaded into the cache, Internet Explorer will compare the MIME-type of the cache file to the extension of the cache file. If there is a mismatch between the MIME-type and the file name extension, Internet Explorer will attempt to reconcile that mismatch by renaming the file in the cache.
Before a file is loaded in its MIME handler or executed by its extension handler, Internet Explorer will compare the CLSIDs of the MIME handler and the extension handler. If there is still a mismatch between the two handlers, Internet Explorer will impose a mandatory prompt for the user to confirm that the user wants to load the file in the MIME handler. If the MIME handler rejects the mismatched file, Internet Explorer will show a download error dialog and not automatically execute the file in the Windows shell extension handler but the dialog will allow saving the file.
There is a related but separate change to prevent execution of potentially corrupt files in their shell extension handlers. Internet Explorer will show the download error dialog for any file that is rejected by its MIME handler with the error code E_Cannot_Load_Data and will not execute that file in its shell extension handler regardless of MIME-type or file name extension.
These changes do not affect cases where a "Content-disposition=attachment" HTTP header is used for the file. In those cases, the file name or extension suggested by the server is considered final and the file can be executed regardless of MIME/extension mismatch if the user chooses to accept the file download prompt.
Why is this change important?
If file type information is misreported by the server and that information is saved to the computer, a dangerous file could be incorrectly executed later. For example, Internet Explorer might download a file that appears to be a text file. If the file can’t be loaded by its MIME handler and has a .doc file name extension, the .doc file might run in an application such as Microsoft Word without prompting the user. In Microsoft Word, the file may be able to use active content, such as a macro, to run a program (such as a virus) on the user’s machine.
What works differently?
Internet Explorer will now attempt to rename downloaded files in the Internet Explorer cache to have matching content types and extensions to protect against files that mislead the user about their type.
Internet Explorer will prompt the user to download the file and will no longer execute MIME and extension mismatched files that are rejected by the registered MIME handler.
Internet Explorer will also not execute a file in its shell handler if the E_Cannot_Load_Data error code was reported by its MIME handler.
Instead of executing such a file in the shell-handler, Internet Explorer will show an error dialog and give the user an option to save the file.
Web developers can isolate nonworking applications due to this behavior by switching off the functionality, as covered in the Settings section later in this document.
How do I resolve these issues?
Web developers must change their Web servers to host files, using consistent content-type headers and file name extensions. If this is not possible, Web developers can use the "Content-disposition=attachment" HTTP header to directly send the file to its extension handler rather than to the MIME handler. Note that file downloads with the "Content-disposition=attachment" header will prompt the user to open or save the file.
If you have developed a MIME handler and intentionally rely on Internet Explorer to execute files that your MIME handler rejects, you will need to make changes in your MIME handler to accommodate this change. The most secure change would be to natively handle the file directly in the MIME handler rather than rejecting the file.
For some scenarios, it may not be possible to change the behavior of the MIME handler to natively handle downloaded files. In those scenarios, there are a few options.
You may choose to develop a MIME handler and file name extension handler that are both part of the same CLSID; Internet Explorer will accept the CLSID match and therefore not prompt the user to download the file or block the file from execution in the extension handler.
If the MIME handler does not need to be loaded and will cause errors due to MIME and extension mismatch, the developer can mark the MIME handler to be ignored by Internet Explorer in the case 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 be executed directly to be played properly, the developer can mark the ProgID of their MIME handler to be ignored on the mismatch when the media file name extension belongs to a different ProgID. To do this, the developer sets the following value in the registry with the MIME handler to ignore:
HKEY_CLASSES_ROOT\PROG_ID_OF_MIMEHANDLER_TO_IGNORE\"PreferExecuteOnMismatch"=DWORD:00000001
If neither of these solutions is viable, developers should notify their users of the incompatibility and explain to the user how to save the mismatched file to the file system 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 that your MIME handler can securely deal with any file that is delegated to it. For example, you should confirm that your handler would never allow an attacker to gain more privilege than allowed by the zone of the originating file. This should be done through threat modeling, code review for secure failure modes, and buffer overruns. If you determine that your MIME handler is capable of safely handling any file that might be delegated to it, you can register your handler to circumvent download prompts by adding a new key to one of the following registry settings:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\InternetSettings\Secure_Mime_Handlers
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\InternetSettings\Secure_Mime_Handlers
The key should be named with the ProgID of your MIME handler and have a DWORD=00000001.
MIME sniffing file type elevation
Detailed description
One of the backup criteria for determining a file type is the result of the MIME sniff. By examining (or sniffing) a file, Internet Explorer can recognize the bit signatures of certain types of files. In Windows Server 2003 Service Pack 1, Internet Explorer MIME sniffing will not promote files of type text\plain to more dangerous file types in the Restricted Sites zone. For example, files that are received as plain text but that include HTML code will not be promoted to the HTML type, which could contain active content.
Why is this change important?
This change provides users additional defense in depth against malicious content posted on a friendly Web server where the server serves files with content-type=text\plain for a file but an attacker has managed to load HTML with active content into the file.
What works differently?
Web servers that do not include the correct Content-Type header with their files and that use nonstandard file name extensions for HTML pages now may have their pages rendered as plain text rather than HTML.
How do I resolve these issues?
You should configure Web servers to use the correct Content-Type headers or you can name the files with the appropriate file name extension for the application that should handle the file.
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 be enabled or disabled for individual security zones. The following 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 use the correct Content-Type headers. You can also name the files with the appropriate file name extension for the application that should handle the file.