Address Space Layout Randomization (ASLR) isn’t properly applied on versions of Microsoft Windows 8 and newer, an alert from Carnegie Mellon University-run CERT Coordination Center (CERT/CC) warns.
The issue is created by the tools that enable system-wide ASLR on newer Windows systems without also setting bottom-up ASLR, a vulnerability note explains.
Starting with Windows 8, system-wide bottom-up ASLR is required for mandatory ASLR to receive entropy, but executables that do not opt in to ASLR aren’t properly randomized if the tools that enable system-wide ASLR don’t also set bottom-up ASLR.
ASLR was introduced in Windows Vista to prevent code-reuse attacks by loading executable modules at non-predictable addresses. Because of this feature, attack methods relying on code being loaded to a predictable or discoverable location, such as return-oriented programming (ROP), were mitigated.
ASLR, however, requires that the code is linked with the /DYNAMICBASE flag to opt in to ASLR, which represents an implementation weakness, the vulnerability note from DHS-sponsored CERT/CC reveals.
To protect applications that don't opt in to using ASLR (or other exploit mitigation techniques), Microsoft released the Enhanced Mitigation Experience Toolkit (EMET), which allows users to specify both system-wide and application-specific mitigations on the system.
Thus, EMET acts as a front-end GUI for system-wide exploit mitigations built in to the Windows operating system. When it comes to application-specific mitigations, the EMET library is loaded into the process space of the applications to be protected.
Starting with the Windows 10 Fall Creators update, Microsoft made EMET native to the operating system by incorporating its capabilities into the Windows Defender Exploit Guard. Both EMET and Windows Defender Exploit Guard can enable mandatory ASLR on a per-application or system-wide basis.
Starting with Windows 8, system-wide mandatory ASLR is implemented via the HKLMSystemCurrentControlSetControlSession ManagerKernelMitigationOptions binary registry value and requires system-wide bottom-up ASLR enabled to supply entropy to mandatory ASLR.
“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,” CERT/CC explains.
Because of this issue, non-DYNAMICBASE applications are relocated to a predictable location on Windows 8 and newer systems that have system-wide ASLR enabled via either EMET or Windows Defender Exploit Guard. This also makes exploitation of the vulnerability easier in some instances.
The CERT team notes that no practical solution to the problem is known at the moment, but that enabling system-wide bottom-up ASLR on systems that have system-wide mandatory ASLR should mitigate the issue.
Importing the following registry value enables both bottom-up ASLR and mandatory ASLR on a system-wide basis on Windows 8 or newer systems:
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
“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,” the CERT team notes.
System-wide mandatory ASLR could cause issues on systems with older AMD/ATI video card drivers in use, but the problem was addressed in the Catalyst 12.6 drivers released in June, 2012.
Microsoft was notified on the vulnerability on November 16, the vulnerability note explains.
Related: Researchers Break ASLR Protection via JavaScript Attack
Related: Microsoft Manually Patched Office Component: Researchers