Entropy Alert: Non-Random ASLR Leaves Systems Open To Buffer Overflow Attacks
Recent versions of the Windows operating system have a security problem: They’re not random enough.
See Also: How to Scale Your Vendor Risk Management Program
The problem centers on ASLR, which refers to address space layout randomization. This operating system feature, introduced with Windows Vista, is designed to randomize the location in which applications get loaded and executed. That randomness helps to block code-reuse or return-oriented programming attacks, in which attackers can predict where applications will load and launch buffer overflow attacks that could allow them to remotely seize control of a device.
But depending on Windows operating system settings, ASLR may not have sufficient entropy, meaning randomness, warns the the CERT Coordination Center, or CERT/CC, which is a part of the Software Engineering Institute, a federally funded research and development center attached to Carnegie Mellon University. As a result, even if ASLR gets activated via the Windows Enhanced Mitigation Experience Toolkit, it may not be doing any good for users of Windows 8, Windows 8.1 and Windows 10. Note that as of last month’s Windows 10 Fall Creators Update, Windows Defender Exploit Guard replaced EMET as the way to force the mandatory use of ASLR.
The ASLR problem was discovered by Will Dormann, a vulnerability analyst at CERT/CC. He says he received assistance from Matt Miller, a security engineer who works for the Microsoft Security Response Center.
“Starting with Windows 8.0, system-wide mandatory ASLR – enabled via EMET – has zero entropy, essentially making it worthless. Windows Defender Exploit Guard for Windows 10 is in the same boat,” Dornan says via Twitter.
Microsoft didn’t immediately respond to a request for comment about the vulnerability or when it might issue a patch.
Two Routes to Mandatory ASLR
It’s important to differentiate between the two different ways that mandatory ASLR can be enabled:
- System-wide ASLR: Leaves Windows 8, Windows 8.1 and Windows 10 unprotected by ASLR.
- System-wide bottom-up ASLR: Provides full ASLR protection on all Windows operating systems for which it’s available. Enabling this also mitigates the entropy problem present with system-wide ASLR in Windows 8, Windows 8.1 and Windows 10.
The entropy problem only occurs on systems for which system-wide ASLR – but not system-wide bottom-up ASLR – has been enabled via EMET or the Windows Defender Exploit Guard.
Microsoft initially released EMET so that administrators could force applications to use ASLR even if developers had not explicitly coded their applications to do so. Unfortunately for users of Windows 8 and newer operating systems, the mandatory, system-wide mitigation setting alone does not correctly load the required Windows library to make ASLR random.
“For system-wide mitigations, EMET simply acts as a front-end GUI to enable exploit mitigations that are built in to the Windows operating system,” CERT/CC says. “For application-specific mitigations, the EMET library is loaded into the process space of each application that is configured to be protected.”
Starting with Windows 8, Microsoft made coding changes which resulted in a lack of ASLR entropy if only the system-wide setting is enabled. “Microsoft Windows 8 introduced a change in how system-wide mandatory ASLR is implemented,” CERT/CC says in an alert. “This change requires system-wide bottom-up ASLR to be enabled for mandatory ASLR to receive entropy. Tools that enable system-wide ASLR without also setting bottom-up ASLR will fail to properly randomize executables that do not opt in to ASLR.”
Actually, with Windows 7 and EMET System-wide ASLR, the loaded address for eqnedt32.exe is different on every reboot. But with Windows 10 with either EMET or WDEG, the base for eqnedt32.exe is 0x10000 EVERY TIME.
Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ
— Will Dormann (@wdormann) November 15, 2017
Waiting For Patches
While the problem with system-wide ASLR setting has now been documented, as yet there’s no easy fix. “The CERT/CC is currently unaware of a practical solution to this problem,” it says in its alert.
But there is a workaround: By enabling not only system-wide ASLR but also bottom-up ASLR, ASLR with full entropy will be in effect. Putting that workaround into effect, however, would require IT administrators to edit the Windows registry on every affected system.
“To be clear: Mandatory ASLR doesn’t necessarily make exploitation *impossible*. But it *DOES* block known exploits in the wild, which obviously is a good thing,” Dormann says via Twitter.
Or for those not proficient in setting bits in binary registry values (such as myself), either manually set the values indicated in this picture, or if you don’t care about clobbering any existing system-wide mitigations, import this .REG file:https://t.co/nOnhvU2xZF pic.twitter.com/i4YNpET0wq
— Will Dormann (@wdormann) November 16, 2017