Application Security , Endpoint Security , Next-Generation Technologies & Secure Development

Windows 10 Security Feature Broken, CERT/CC Warns

Entropy Alert: Non-Random ASLR Leaves Systems Open To Buffer Overflow Attacks
Windows 10 Security Feature Broken, CERT/CC Warns
Photo: Andrew Writer via Flickr/CC

Recent versions of the Windows operating system have a security problem: They're not random enough.

See Also: 4 Key Elements of an ML-Powered NGFW

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.

Entropy Problem

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 says it's aware of the research, but suggests it's not a vulnerability but rather a configuration problem. "The issue described by the CERT/CC is not a vulnerability," a Microsoft spokeswoman tells Information Security Media Group. "ASLR is functioning as designed and customers running default configurations of Windows are not at increased risk."

The spokeswoman adds: "The CERT/CC 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."

Dormann says that however the configuration problems in EMET and WDEG get classified, they need to be fixed. "If I enabled system-wide *mandatory* ASLR, I have made the decision that I want everything randomized. Full stop," he says. "Call it what you want, but it should be fixed, and it has a security impact."

But for anyone who does not want to enforce mandatory ASLR on all applications - whether or not they provide it themselves - there's no problem, Dormann tells ISMG. "If you're OK with the default (ASLR for everything that says it's compatible), you don't have to do anything."

Two Different ASLR Settings

It's important to differentiate between the two different system-wide ASLR settings now facing users:

  • Mandatory ASLR: Leaves Windows 8, Windows 8.1 and Windows 10 unprotected by ASLR.
  • Bottom-up ASLR: Provides full ASLR protection on all Windows operating systems for which it's available. Enabling this is required to provide entropy for 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.

"Bottom-up ASLR provides the entropy to mandatory ASLR starting with Win8," Dormann says. "Bottom-up is not a superset of mandatory ASLR. In other words, if you want mandatory ASLR on Win8+, you need *both*, and not just the latter."

ASLR Upsides

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."

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.

He's published a Windows registry file that will rewrite the relevant portion of the registry, but warns that using it may have unintended effects.

Microsoft Equation Editor Flaw Led to Discovery

Dormann says he discovered the ASLR problem while reviewing an Oct. 14 blog post from security firm Embedi. It warns that an "obsolete component" included in Microsoft Office since 2000 called Microsoft Equation Editor - eqnedt32.exe - could be remotely exploited.

On Nov. 14, Microsoft patched the Office flaw, CVE-2017-11882, by issuing updates for Microsoft Office 2007 Service Pack 3, Microsoft Office 2010 Service Pack 2, Microsoft Office 2013 Service Pack 1 and Microsoft Office 2016. But users of unpatched and older versions of Office would still be at risk.

"I was looking into what mitigations would have protected users against the eqnedt32 vulnerability when I noticed the [ASLR] problem," Dormann tells ISMG.

***

This story has been updated with comment from Microsoft and additional comments from Dormann.


About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing databreachtoday.com, you agree to our use of cookies.