ifeo-mitigationoptions.txt

                        ------------------------
                        IFEO - MitigationOptions
                        ------------------------

Overview
--------

As far as I know the MitigationOptions (QWORD) registry entry from Window's
Image File Executable Options (IFEO) key isn't completely documented.  The
general gist of how it works is you create a key in IFEO which is the name of
the executable whose options you want to change.  This is explained in the
force ASLR Windows update KB article[1].

That is, you create a new key in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Using the executable name as its name (e.g. foo.exe).  You can then add various
entries under this key to change certain behaviors such as the various
mitigation technologies in Windows.  This document is about the
MitigationOptions QWORD entry.


Structure
---------

MitigationOptions is just a bitmask which can control the various mitigation
technologies in Windows.  The structure is very similar to the
PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY attribute from the
UpdateProcThreadAttribute function[2].  It follows the order and bitmask values
nearly identically.

Take the following example from an executable that's been added to EMET:

    0x2000000010111

This setup enables DEP, SEHOP, force ASLR and bottom up ASLR.  Furthermore it
disables Win10's system font restriction (although this also happens to default
to disabled as a system wide policy).


Breakdown
---------

For a complete breakdown we'll use the following hex value for
MitigationOptions:

    0x112010101111111

This is just about as much as can be reasonable enabled for most applications
without breaking them.  Some options will be redundant as they would've already
been enabled (such as DEP for 64-bit processes) or ignored completely (HEASLR
for 32-bit processes).

I'm just going to go one by one through the options from right to left
(increasing the << value essentially).  A value of 0 generally means it will
defer to the application/other ways of setting these.  It's essentially a
no-op so these can still be changed using the thread attributes, etc.  Certain
options can be enabled/disabled at will.  Some will be permanently enabled once
enabled for the first time.

These options were tested using Windows 10 TH2.  Certain options are not
available on older versions.  I've marked where roughly the boundaries are on
what should work for which Windows version.

    For all options:
        0 = Defer/Do Nothing

Windows 7+:
0x112010101111111
                ^
    This controls DEP (data execution prevention).
        1 = Always On
        2 = Always On but enable ATL thunk emulation

0x112010101111111
               ^
    SEHOP[3].  For 32-bit processes only, ignored for 64-bit.
        1 = Enabled SEHOP
    Also controlled with the IFEO DisableExceptionChainValidation DWORD.
        DisableExceptionChainValidation with a value of 0 ENABLES SEHOP

0x112010101111111
              ^
    Force ASLR[1], introduced in Windows 7.
        1 = Enable force relocate.  Modules that do not contain a reloc section
            will still load.
        2 = Force relocate off.  I'm not sure why'd you want to use this.
        3 = Force relocate always on.  Modules that do not contain a reloc
            section will NOT load.
    Unlike setting this programmatically, this will work on the executable
    itself if it has a relocation section but otherwise did not have
    /DYNAMICBASE set.

0x112010101111111
             ^
    Heap terminate.
        1 = Always On
        2 = Always Off (sort of, if not otherwise already enabled)
    Depending on the Windows version targeted in Visual Studio and/or the
    value of the subsystem image header this may already be enabled.

0x112010101111111
            ^
    Bottom-Up ASLR.  Includes stuff such as stack randomization.
        1 = Always On
        2 = Always Off

Windows 8+:
0x112010101111111
           ^
    HEASLR - High Entropy bottom-up ASLR (64-bit only).
        1 = Always On
        2 = Always Off
    Ignored for 32-bit processes.  Requires bottom-up randomization.

0x112010101111111
          ^
    Strict handle checks.
        1 = Always On
        2 = Always Off
    Causes an immediate exception on a bad handle reference.  Essentially a
    fail and crash now option instead of returning a failure status to the
    handle reference.

0x112010101111111
         ^
    Win32k system call disable policy.
        1 = Always On
        2 = Always Off
    One of the few options that can't be enabled here and for nearly all
    applications will cause a crash when ran.  This basically has to be
    enabled by the running process itself.  Chrome uses it for its renderer
    processes and is adding support for plugin processes (Flash, pdf and
    widevine should all be feature complete as of writing on the dev branch).

0x112010101111111
        ^
    Extension point disable policy.  Disables legacy extension points.
        1 = Always On
        2 = Always Off
    Will disable:
        - AppInit DLLs
        - Winsock Layered Service Providers (LSPs)
        - Globoal Windows Hooks
        - Legacy Input Method Editors (IMEs)
    Local hooks still work.

Windows 10+:
0x112010101111111
       ^
    Dynamic code policy (probably).  Prevents a process from generating dynamic
    code or modifying executable code.
        0 = Defer
        1 = Always On
        2 = Always Off
        3 = Always On but allow opt-out.
    Not sure if this is useful yet.

0x112010101111111
      ^
    Control Flow Guard (CFG).
        1 = Enable
        2 = Disable(?)
    This just enables support for the given executable.  If it lacks CFG
    instrumentation then this isn't going to fix that.  HOWEVER it may be
    useful for allowing modules compiled with CF instrumentation to actually
    use it.  Currently if the executable isn't linked with CFG support any
    loaded modules even if they have CFG support won't use it, perhaps this can
    enable its use (untested).

0x112010101111111
     ^
    Binary signature policy.
        1 = Microsoft signed only.
        2 = ?? (disable? not sure)
        ? = ?? The other options[4] don't appear to be available.

0x112010101111111
    ^
    Font loading prevention.  When enabled applications can't load non-system
    fonts (i.e. System32/Fonts).
        0 = Defer
        1 = Always On
        2 = Always Off
        3 = On but audit instead of hard failing
    Funny thing about this option, if you use EMET and use the default Chrome
    profile it will actually wind up disabling Chrome's use of this feature
    because it sets it to always off.  So if you use EMET with Chrome you may
    want to change this to 0 in the registry so some of Chrome's processes can
    use it (e.g. renderer, plugin, gpu).

Windows 10 TH2+:
0x112010101111111
   ^
    Image load policy (remote images).
        0 = Defer
        1 = Always On
        2 = Always Off
        3 = Reserved(?)
    Blocks loading of remote images.

0x112010101111111
  ^
    Image load policy (low mandatory label).
        0 = Defer
        1 = Always On
        2 = Always Off
        3 = Reserved(?)
    Blocks loading of images with the low mandatory label (e.g. temp internet
    files).

The prefer system32 image load policy does not seem to be accessible through
MitigationOptions (or at least I didn't seem to find it).

You can use Process Hacker to view some of the enabled mitigations by right
clicking a running process -> Properties -> under the General tab click
"details" on the Mitigation policies line.  Clicking on the mitigations can
show additional information such as HEASLR being used under the ASLR entry.


Thoughts/Other
--------------

You can use Process Hacker to view some of the enabled mitigations by right
clicking a running process -> Properties -> under the General tab click
"details" on the Mitigation policies line.  Clicking on the mitigations can
show additional information such as HEASLR being used under the ASLR entry.

I'm not sure why these features are more well documented or otherwise exposed.
EMET only exposes a handful of them and it took them until the latest few
versions to actually get around to using this registry entry.  I can understand
it's probably out of concern for compatibility and possibly unknown side effects
but they still seem like a useful way to gain protection from mitigations for
images that weren't compiled with them built-in (do developers even know about
half of these options?).

The MitigationOptions IFEO registry entry kind of seems like a useful feature
that you would want to better document.


Disclaimer:
Using any of these may cause dragons to appear or otherwise break something.
Use at your own risk.

Changelog:
2016/06/21 - Initial version.

Sources:
[1] https://support.microsoft.com/en-us/kb/2639308
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms686880%28v=vs.85%29.aspx
[3] https://blogs.technet.microsoft.com/srd/2009/02/02/preventing-the-exploitation-of-structured-exception-handler-seh-overwrites-with-sehop/
[4] https://msdn.microsoft.com/en-us/library/windows/desktop/mt706242(v=vs.85).aspx