Vulnerability Note VU#817544

Windows 8 and later fail to properly randomize every application if system-wide mandatory ASLR is enabled via EMET or Windows Defender Exploit Guard

Original Release date: 17 Nov 2017 | Last revised: 19 Nov 2017


Microsoft Windows 8 introduced a change in how system-wide mandatory ASLR is implemented. This change requires system-wide bottom-up ASLR to be enabled for mandatory ASLR to receive entropy. Tools that enable system-wide ASLR without also setting bottom-up ASLR will fail to properly randomize executables that do not opt in to ASLR.


Address Space Layout Randomization (ASLR)

Starting with Windows Vista, a feature called ASLR was introduced to Windows that helps prevent code-reuse attacks. By loading executable modules at non-predictable addresses, Windows can help to mitigate attacks that rely on code being at predictable locations. Return-oriented programming (ROP) is an exploit technique that relies on code that is loaded to a predictable or discoverable location. One weakness with the implementation of ASLR is that it requires that the code is linked with the /DYNAMICBASE flag to opt in to ASLR.

EMET and Windows Defender Exploit Guard

In order to help protect applications that don't necessarily opt in to using ASLR and other exploit mitigation techniques, Microsoft EMET was released. Using the EMET GUI, one can specify both system-wide and application-specific mitigations that can be enabled on a system. For system-wide mitigations, EMET simply acts as a front-end GUI to enable exploit mitigations that are built in to the Windows operating system. For application-specific mitigations, the EMET library is loaded into the process space of each application that is configured to be protected. Starting with the Windows 10 Fall Creators update, the capabilities that EMET provides have been replaced with Windows Defender Exploit Guard.

Mandatory ASLR and Windows 8

Both EMET and Windows Defender Exploit Guard can enable mandatory ASLR for code that isn't linked with the /DYNAMICBASE flag. This can be done on a per-application or system-wide basis. Before Windows 8, system-wide mandatory ASLR was implemented using the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages registry value. By settings this value to 0xFFFFFFFF, Windows will automatically relocate code that has a relocation table, and the new location of the code will be different across reboots of the same system or between different systems. Starting with Windows 8, system-wide mandatory ASLR is implemented differently than with prior versions of Windows. With Windows 8 and newer, system-wide mandatory ASLR is implemented via the HKLM\System\CurrentControlSet\Control\Session Manager\Kernel\MitigationOptions binary registry value. The other change introduced with Windows 8 is that system-wide ASLR must have system-wide bottom-up ASLR enabled to supply entropy to mandatory ASLR.

The Problem

Both EMET and Windows Defender Exploit Guard enable system-wide ASLR without also enabling system-wide bottom-up ASLR. Although Windows Defender Exploit guard does have a system-wide option for system-wide bottom-up-ASLR, the default GUI value of "On by default" does not reflect the underlying registry value (unset). This causes programs without /DYNAMICBASE to get relocated, but without any entropy. The result of this is that such programs will be relocated, but to the same address every time across reboots and even across different systems.


Windows 8 and newer systems that have system-wide ASLR enabled via EMET or Windows Defender Exploit Guard will have non-DYNAMICBASE applications relocated to a predictable location, thus voiding any benefit of mandatory ASLR. This can make exploitation of some classes of vulnerabilities easier.


The CERT/CC is currently unaware of a practical solution to this problem. Please consider the following workaround:

Enable system-wide bottom-up ASLR on systems that have system-wide mandatory ASLR

To enable both bottom-up ASLR and mandatory ASLR on a system-wide basis on a Windows 8 or newer system, the following registry value should be imported:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]

Note that importing this registry value will overwrite any existing system-wide mitigations specified by this registry value. The bottom-up ASLR setting specifically is the second 01 in the binary string, while the mandatory ASLR setting is the first 01. Also note that in the past, enabling system-wide mandatory ASLR could cause problems if older AMD/ATI video card drivers are in use. This issue was addressed in the Catalyst 12.6 drivers released in June, 2012.

Vendor Information (Learn More)

VendorStatusDate NotifiedDate Updated
Microsoft CorporationAffected16 Nov 201717 Nov 2017
If you are a vendor and your product is affected, let us know.

CVSS Metrics (Learn More)

Group Score Vector
Base 0.0 AV:--/AC:--/Au:--/C:--/I:--/A:--
Temporal 0.0 E:ND/RL:ND/RC:ND
Environmental 0.0 CDP:ND/TD:H/CR:ND/IR:ND/AR:ND



This issue was reported by Will Dormann of the CERT/CC, with assistance from Matt Miller of Microsoft.

This document was written by Will Dormann.

Other Information

  • CVE IDs: Unknown
  • Date Public: 16 Nov 2017
  • Date First Published: 17 Nov 2017
  • Date Last Updated: 19 Nov 2017
  • Document Revision: 40


If you have feedback, comments, or additional information about this vulnerability, please send us email.