Clarifying the behavior of mandatory ASLR

[Nytro]

Clarifying the behavior of mandatory ASLR

 

swiat

November 21, 2017

---

Last week, the CERT/CC published an advisory describing some unexpected behavior they observed when enabling system-wide mandatory Address Space Layout Randomization (ASLR) using Windows Defender Exploit Guard (WDEG) and EMET on Windows 8 and above. In this blog post, we will explain the configuration issue that CERT/CC encountered and describe work arounds to enable the desired behavior. In short, ASLR is working as intended and the configuration issue described by CERT/CC only affects applications where the EXE does not already opt-in to ASLR. The configuration issue is not a vulnerability, does not create additional risk, and does not weaken the existing security posture of applications. 

The briefest of histories: mandatory and bottom-up ASLR 

In a previous blog post we explained how ASLR works on Windows. The vast majority of this explanation still holds true through the latest version of Windows 10 (1709). In the interest of brevity, we’ll focus on the details that are relevant to the behavior observed by CERT/CC: 

1. Randomization of EXEs/DLLs is opt-in. EXEs/DLLs tell the operating system they are compatible with ASLR by linking with the /DYNAMICBASE flag. This flag has been enabled by default since Visual Studio 2010. The opt-in model was an intentional choice to avoid non-trivial compatibility issues with existing applications. 
2. Mandatory ASLR can be used to forcibly rebase EXEs/DLLs that have not opted in. In Windows 8, we introduced operating system support for forcing EXEs/DLLs to be rebased at runtime if they did not opt-in to ASLR. This mitigation can be enabled system-wide or on a per-process basis. It works by forcing a base address conflict at the time that a non-ASLR EXE/DLL is mapped. When this occurs, the new base address of the EXE/DLL is selected by searching for a free region starting from the bottom of the address space. 
3. Bottom-up randomization provides entropy for bottom-up allocations. In Windows 8, we also introduced opt-in support for bottom-up randomization which adds entropy to the base address selected for allocations that search for a free region starting from the bottom of the address space (e.g. EXEs/DLLs rebased due to mandatory ASLR). This provides implicit biasing of all bottom-up allocations and can be enabled system-wide or on a per-process basis. 
4. Bottom-up randomization is enabled by default only if the process EXE opts in to ASLR. This is for compatibility reasons as applications whose EXE did not opt-in to ASLR (via /DYNAMICBASE) do not necessarily expect their address space layout to change from one execution to the next.  

The following table attempts to make this easier to understand by considering the behavior of ASLR in different configurations for a given process: 

The behavior that CERT/CC observed

A consequence of the above is that the entropy of images rebased by mandatory ASLR is inherently reliant on bottom-up randomization being enabled for the process. However, bottom-up randomization is not automatically enabled for process when the process EXE does not opt-in to ASLR (as highlighted in yellow in the table above). This means that bottom-up randomization must also be enabled for entropy to be applied to images that are rebased by mandatory ASLR. In practice, this issue only affects scenarios where an administrator is intentionally attempting to enable mandatory ASLR for a process that would otherwise not fully benefit from ASLR.

CERT/CC did identify an issue with the configuration interface of Windows Defender Exploit Guard (WDEG) that currently prevents system-wide enablement of bottom-up randomization. The WDEG team is actively investigating this and will address the issue accordingly. Similarly, EMET does not support enabling bottom-up randomization system-wide and therefore cannot directly configure this setting.

Fortunately, there are workarounds available for this configuration issue.

Workarounds

There are two workarounds for those who would like to enable mandatory ASLR and bottom-up randomization for processes whose EXE did not opt-in to ASLR. As with all non-default configuration, these changes may introduce application compatibility issues and care should be taken to validate that applications work as expected.

1. Directly enabling mandatory ASLR and bottom-up randomization via the system-wide registry value.

• Saving the following into optin.reg and importing it will enable mandatory ASLR and bottom-up randomization system-wide. This is the same registry value that WDEG and EMET modify through their configuration user interfaces.

   

• Windows Registry Editor Version 5.00
  
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] 
  "MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00
  

• Note, applying this registry file will override any other mitigations that have been applied system-wide. To retain the existing settings, the MitigationOptions registry value can be manually edited such that the 2nd byte is set to ?1 (where ? retains its value, e.g. 01) and the 3rd byte is set to ?1. The second byte corresponds to mandatory ASLR and the third byte corresponds to bottom-up ASLR.

2. Enabling mandatory ASLR and bottom-up randomization via program-specific configuration using WDEG or EMET. 

• From WDEG, mitigations can be enabled on a per-program basis using the user interface or command line tools as described here. Enabling force randomization for images (mandatory ASLR) and randomize memory allocations (bottom-up ASLR) will enable the expected behavior as shown below:

Why did this work differently with EMET on Windows 7?

One of the noteworthy observations that CERT/CC made is that enabling system-wide mandatory ASLR via EMET on Windows 7 does not exhibit the behavior described above. Instead, processes whose EXE did not opt-in to bottom-up ASLR are still observed to be randomized. The reason for this is that EMET on Windows 7 enabled mandatory ASLR using a different setting versus what is now used on Windows 8 and above.

The setting that EMET uses on Windows 7 results in all images being treated as if opted-in to ASLR (e.g. as if they were linked with /DYNAMICBASE). As a consequence, bottom-up randomization of stacks and heaps is implicitly enabled for all processes as a side effect of them being treated as if they had opted-in to ASLR and the images themselves are randomized just like other ASLR images. This differs from the behavior of mandatory ASLR because mandatory ASLR forcibly rebases images and does not treat them as if they had opted into to ASLR.

The setting used by EMET on Windows 7 is not recommended and is intentionally hidden by default due to the application compatibility risk associated with it. EMET users must expose this setting by navigating to EMET’s Advanced options as described here.

Wrapping up

In summary, the behavior of mandatory ASLR that CERT/CC observed is by design and ASLR is working as intended. The WDEG team is investigating the configuration issue that prevents system-wide enablement of bottom-up ASLR and is working to address it accordingly. This issue does not create additional risk as it only occurs when attempting to apply a non-default configuration to existing versions of Windows. Even then, the effective security posture is no worse than what is provided by default and it is straightforward to work around the issue through the steps described in this post.

Matt Miller

Microsoft Security Response Center (MSRC)

 

Sursa: https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/