Internet Explorer MIME Handling Enforcement

IT Support Forum Forums Windows Windows Server 2003 R2 General Discussion Internet Explorer MIME Handling Enforcement

Viewing 0 reply threads
  • Author
    • #2205

      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
      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
      Instead of executing such a filein theshell-handler, InternetExplorer will show an error dialog and givethe user an option to
      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:
      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:
      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
      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
      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?
      Location Previous
      HKEY_LOCAL_MACHINE(or Current User)\Software\Microsoft \Internet
      Explorer\Main \FeatureControl \FEATURE_MIME_HANDLING\
      None 1 0 – Off
      1 – On
      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.

Viewing 0 reply threads
  • You must be logged in to reply to this topic.