ASLR broken on win 8 &10

[Elixer]

I wonder how this got passed MS's testing?

The Problem

Both EMET and Windows Defender Exploit Guard enable system-wide ASLR without also enabling system-wide bottom-up ASLR. 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.
Impact

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.

Solution
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]
  "MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

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.

http://www.kb.cert.org/vuls/id/817544

 

[TheRyuu]

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

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.

I don't think it's as much of an issue as it makes it out to be.