News

Microsoft: That Windows ASLR Flaw Is Actually a Feature

• By Kurt Mackie
• 11/29/2017

Microsoft is rationalizing that an apparent security flaw in the ASLR Windows protection scheme was placed there on purpose.

The alleged flaw was described in a vulnerability note published this month by CERT, a division of the Software Engineering Institute, which collaborates with U.S. security organizations to address software vulnerabilities. CERT found that when ASLR was used without bottom-up memory allocation, executable file memory allocations were no longer being randomized for applications that didn't opt in to using ASLR. Instead, those memory allocation locations became predictable, defeating the protection scheme, according to the description by Will Dormann of CERT.

CERT argued that Microsoft had changed the behavior of ASLR ever since the release of Windows 8. The change in behavior from Windows 7 days had introduced a flaw in which ASLR didn't randomize the memory allocation locations for executable modules (namely Dynamic Link Libraries and executable files) when those applications didn't opt in to use ASLR. Since such randomization is how ASLR adds protection against attacks, CERT suggested carrying out a workaround to deal with the issue.

CERT found the failure to randomize memory allocations to be an issue for users of both Windows Defender Exploit Guard and the deprecated Enhanced Mitigation Experience Toolkit (EMET), which is a standalone Microsoft tool designed to ward off general software exploits. EMET no longer works with Windows 10 as of the "fall creators update." Instead, its capabilities were rolled into Windows Defender Exploit Guard.

It turns out that the so-called flaw in ASLR is really a feature and is "working as intended," according to Matt Miller of the Microsoft Security Response Center, per Microsoft's explanation. He described CERT's finding as being a configuration issue that "only affects applications where the EXE does not already opt-in to ASLR." It occurs when "mandatory ASLR" gets turned on for those applications instead of using the default configuration setting.

Miller explained that the opt-in model of ASLR "was an intentional choice to avoid non-trivial compatibility issues with existing applications."

Miller and Dormann both offered the same registry edit as a workaround. The workaround turns on bottom-up ASLR and mandatory ASLR system wide for organizations using Windows 8 and higher OS versions, which enables memory allocation randomization for applications. However, Miller cautioned that "these changes may introduce application compatibility issues." The change has to be made through the registry. It can't be done using EMET's graphical user interface.

Since Miller collaborated with Dormann on CERT's vulnerability note, they don't seem to be in disagreement. However, Microsoft is investigating a configuration issue turned up by CERT in which Windows Defender Exploit Guard "prevents system-wide enablement of bottom-up ASLR," which perhaps really is a flaw.

ASLR supports bottom-up, top-down and "based" approaches when assigning virtual memory allocations to applications. The scheme is outlined in this Microsoft TechNet article.