Security researchers at CERT have stated that Windows 10, Windows 8,1 and Windows 8 fail to properly randomize every application if system-wide mandatory ASLR is enabled via EMET or Windows Defender Exploit Guard. Microsoft has responded by saying that the implementation of Address Space Layout Randomization (ASLR) on Microsoft Windows is working as intended. Let us take a look at the issue.
What is ASLR
ASLR is expanded as Address Space Layout Randomisation, the feature made a debut with the Windows Vista and is designed to prevent code-reuse attacks. The attacks are prevented by loading executable modules at non-predictable addresses thus mitigating attacks that usually depend on code placed at predictable locations. ASLR is fine-tuned to combat exploit techniques like Return-oriented programming which rely on code that is generally loaded into a predictable location. That apart one of the major downsides of the ASLR is that it needs to be linked with /DYNAMICBASE flag.
Scope of use
The ASLR offered protection to the application, but it didn’t cover the system-wide mitigations. In fact, it is for this reason that Microsoft EMET was released. EMET ensured that it covered both system-wide and application-specific mitigations. The EMET ended up as the face of system-wide mitigations by offering a front-end for the users. However, starting from the Windows 10 Fall Creators update the EMET features have been replaced with Windows Defender Exploit Guard.
The ASLR can be enabled compulsorily for both EMET, and Windows Defender Exploit Guard for codes that are not linked to /DYNAMICBASE flag and this can be implemented either on a per-application basis or a system-wide base. What this means is that Windows will automatically relocate code to a temporary relocation table and thus the new location of the code will be different for every reboots. Starting from the Windows 8, the design changes mandated that the system-wide ASLR should have system-wide bottom-up ASLR enabled in order to supply entropy to the mandatory ASLR.
ASLR is always more effective when the entropy is more. In much simpler terms increase in entropy increases the number of search space that needs to be explored by the attacker. However, both, EMET and Windows Defender Exploit Guard enable system-wide ASLR without enabling system-wide bottom up ASLR. When this happens the programs without /DYNMICBASE will get relocated but without any entropy. As we explained earlier the absence of entropy would make it relatively easier for attackers since the program will reboot the same address every time.
This issue is currently affecting Windows 8, Windows 8.1 and Windows 10 which have a system-wide ASLR enabled via Windows Defender Exploit Guard or EMET. Since the address relocation is non-DYNAMICBASE in nature, it typically overrides the advantage of ASLR.
What Microsoft has to say
Microsoft has been swift and has already issued a statement. This is what the folks at Microsoft had to say,
“The behaviour of mandatory ASLR that CERT 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”
They have specifically detailed the workarounds that will help in achieving the desired level of security. 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.
1] Save the following into optin.reg and import it to enable mandatory ASLR and bottom-up randomization system-wide.
Windows Registry Editor Version 5.00
2] Enable mandatory ASLR and bottom-up randomization via program-specific configuration using WDEG or EMET.
Said Microsoft – This issue does not create additional risk as it only occurs when attempting to apply a non-default configuration to existing versions of Windows.