When Windows Defender Exploit Guard ( WDEG ) and EMET were used to enable system-wide mandatory Address Space Layout Randomization ( ASLR ) on Windows 8 and above, the CERT/CC published an advisory last week outlining some unexpected behavior they saw. In this blog post, we’ll go over the configuration problem that CERT/CC ran into and offer solutions to make the desired behavior possible. In other words, ASLR is functioning as intended, and the CERT/CC-described configuration issue only affects applications where the EXE has n’t already chosen to opt-in. The configuration problem does not pose a vulnerability, increase risk, or compromise applications ‘ current level of security.
The most succinct of histories: bottom-up and mandatory ASLR
We previously discussed how ASLR functions on Windows in a blog post. Through the most recent version of Windows 10 ( 1709 ), the vast majority of this explanation is still valid. We’ll concentrate on the specifics that are pertinent to the behavior seen by CERT/CC in order to keep this short:
- EXEs and DLLs are randomly assigned. By connecting with the /DYNAMICBASE flag, EXEs/DLLs signal to the operating system that they are ASLR compatible. Since Visual Studio 2010, this flag has been turned on by default. The opt-in model was chosen on purpose to prevent serious compatibility issues with current applications.
- EXEs and DLLs that have not consented may be forcibly rebased under mandatoryASLR. If EXEs/DLLs did not opt-in to ASLR, we added operating system support in Windows 8 to make them reload at runtime. System-wide or per-process mitigation options are available. When a non-ASLR EXE/DLL is mapped, the base address conflict is forced, which is how it works. When this happens, a free region is found at the bottom of the address space to determine the new base address for the EXE/DLL.
- Bottom-up randomization offers entropy for allocations at the top. Opt-in support for bottom-up randomization was also added to Windows 8, adding entropy to the base address chosen for allocations that look for free regions beginning at the bottom of the address space ( e .g., EXEs/DLLs rebased as a result of mandatory ASLR ). All bottom-up allocations are implicitly biased as a result, and this can be enabled system-wide or per-process.
- Only when the process EXE opts in to ASLR is bottom-up randomization enabled by default. Applications whose EXE did not opt-in to ASLR (via /DYNAMICBASE ) do not necessarily anticipate their address space layout to change from one execution to the next, so this is done for compatibility reasons.
By taking into account the behavior of ASLR in various configurations for a specific process, the following table aims to simplify this:
The actions that CERT/CC saw
The entropy of images rebased by mandatory ASLR is inherently dependent on bottom-up randomization being enabled for the process, as a result of the foregoing. However, when the process EXE does not opt-in to ASLR ( as shown in yellow in the table above ), bottom-up randomization is not automatically enabled for process. In order to apply entropy to images that are rebased by required ASLR, bottom-up randomization must also be enabled. In reality, this problem only arises when an administrator purposefully tries to make ASLR mandatory for a procedure that would n’t otherwise gain much from it.
CERT/CC did find a problem with Windows Defender Exploit Guard’s ( WDEG ) configuration interface that currently prevents system-wide support for bottom-up randomization. This is a matter that the WDEG team is actively looking into, and they will deal with it accordingly. Similar to this, EMET cannot directly configure this setting because it does not support enabling bottom-up randomization system-wide.
Fortunately, there are solutions to this configuration problem.
Workarounds
For those who want to make ASLR mandatory and bottom-up randomization available for processes whose EXE did not opt-in, there are two workarounds. These modifications may cause compatibility problems with applications, as they do with all non-default configurations, so care should be taken to ensure that applications function as intended.
- enabling bottom-up randomization through the system-wide registry value and mandatoryASLR.
-
The following is being saved for optin. mandatory ASLR and bottom-up randomization system-wide reg and import it. Through their configuration user interfaces, WDEG and EMET both change this registry value.
-
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession Managerkernel]"MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00 -
Please be aware that any other system-wide mitigations will be superseded by the application of this registry file. The MitigationOptions registry value can be manually edited to set the second byte to ?1 ( where ) in order to keep the current settings. keeps its value ( for example, 01 ) and sets the third byte to ?1. The bottom-up ASLR is represented by the third byte, and the mandatoryASLR by a second.
- WDEG or EMET are used to enable mandatory ASLR and bottom-up randomization through program-specific configuration.
- The user interface or command line tools described here can be used to enable mitigations on a per-program basis from WDEG. The expected behavior will be made possible by enabling force randomization for images ( mandatory ASLR ) and randomizing memory allocations ( bottom-upASLR ).
Why did EMET on Windows 7 perform this differently?
Enabling system-wide mandatory ASLR via EMET on Windows 7 does not display the behavior described above, according to one noteworthy observation made by CERT/CC. Instead, it has been noted that processes whose EXE did not opt-in to bottom-up ASLR are randomized. This is due to the fact that EMET on Windows 7 enabled mandatory ASLR using a different setting than Windows 8 and above do today.
All images are treated as if they were opted-in to ASLR on Windows 7 thanks to the setting that EMET uses, such as when they are connected to /DYNAMICBASE. As a result, all processes are implicitly given the option to bottom-up randomize stacks and heaps, and the images themselves are randomized similarly to other ASLR images. Because mandatory ASLR forcibly rebases images rather than treating them as though they had chosen to join, this is different from how it behaves.
Due to the potential for application compatibility, the EMET setting on Windows 7 is not advised and is purposefully hidden by default. Users of EMET must access the Advanced options listed here in order to view this setting.
Putting an end to
In conclusion, the mandatory ASLR’s behavior was intentionally observed by CERT/CC, and it is functioning as intended. The WDEG team is looking into the configuration problem that prevents bottom-up ASLR from being enabled across the entire system and is working to fix it. Since this problem only arises when attempting to apply a non-default configuration to current Windows versions, it does not add to the risk. Even then, the default security posture is still effective, and it is simple to fix the problem by following the instructions in this post.
Miller, Matt
MSRC, or Microsoft Security Response Center