US-CERT Warns of ASLR Implementation Flaw In Windows

US-CERT is warning of a vulnerability in Microsoft’s implementation of Address Space Layout Randomization that affects Windows 8, Windows 8.1 and Windows 10.

The U.S. Computer Emergency Readiness Team is warning of a vulnerability in Microsoft’s implementation of Address Space Layout Randomization that affects Windows 8, Windows 8.1 and Windows 10. The vulnerability could allow a remote attacker to take control of an affected system.

Microsoft said it is investigating the matter.

Address Space Layout Randomization (ASLR) is championed as a system hardening technology used in most major desktops and mobile operating systems. ASLR is used to thwart memory-based code-execution attacks. iOS, Android, Windows, macOS and Linux each use ASLR to keep systems safer.

Over the years bypassing ASLR has become somewhat of a sport for attackers and white-hat researchers. However, this latest ASLR issue has to do with Microsoft’s implementation of ASLR in Windows.

According to Will Dormann, a senior vulnerability analyst at CERT, Microsoft introduced an error in how it implemented ASLR in 2012, with the release of Windows 8. Ever since then, according to Dormann, the vulnerability has continued, also affecting Windows 10.

“Windows 8 and later fail to properly randomize every application if system-wide mandatory ASLR is enabled via EMET or Windows Defender Exploit Guard,” Dormann wrote. Under those specific conditions a flawed implementation could create an opportunity for an attacker to pull off a memory-based attack.

Microsoft told Threatpost it acknowledges the issue.

“The issue described by the US-CERT is not a vulnerability. ASLR is functioning as designed and customers running default configurations of Windows are not at increased risk. The US-CERT discovered an issue with configuring non-default settings for ASLR using Windows Defender Exploit Guard and EMET, and provided workarounds. Microsoft is investigating and will address the configuration issue accordingly,” Microsoft said.

The problem is tied to how the way ASLR protects against attacks. It does so by randomizing where programs execute in memory locations. Instead of executing at predictable memory locations that a hacker can anticipate, ASLR randomizes the process.

But what Dormann found was that Microsoft’s flawed application of ASLR results in programs being relocated to predictable address every time.

“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,” Dormann wrote in a US-CERT vulnerability note.

Dormann said he discovered the vulnerability when he enabled system-wide ASLR in Windows 8. The researcher explained it this way on Twitter: “Starting with Windows 8.0, system-wide mandatory ASLR (enabled via EMET) has zero entropy, essentially making it worthless.”

EMET stands for Enhanced Mitigation Experience Toolkit and it is a utility that works to prevent software vulnerabilities from being exploited.

The impact of this type of ASLR misconfiguration, Dormann said is:

“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.”

No patch exists yet for this vulnerability, the US-CERT bulleting said. However, a workaround is offered starting with enabling system-wide bottom-up ASLR on systems that have system-wide mandatory ASLR.

Dormann also credits Matt Miller, a security engineer working for the Microsoft Security Response Center of Microsoft, for research assistance. Microsoft did respond to a request for comment for this report.

Suggested articles