Microsoft says ASLR behavior in Windows 10 is a feature, not a bug
Security analyst Will Dormann of Carnegie Mellon University's CERT Coordination Center (CERT/CC) caused a major kerfuffle earlier this month when he tweeted that Windows 10's implementation of a security feature known as system-wide mandatory ASLR is "essentially worthless."
He followed that tweet with a CERT advisory, which in turn led to a flurry of caustic headlines in the tech press, typified by ZDNet's own story on the issue: Key Windows 10 defense is 'worthless' and bug dates back to Windows 8.
That headline has two problems.
First, the feature in question isn't a "key Windows 10 defense." System-wide mandatory ASLR is an esoteric option that applies mostly in edge cases and has to be configured manually.
And second, Microsoft argues that the behavior Dormann complained about is not a bug. In a blog post from the Microsoft Response Security Center titled "Clarifying the behavior of mandatory ASLR," Microsoft's Matt Miller writes, "[T]he behavior of mandatory ASLR that CERT/CC observed is by design..."
In short, ASLR is working as intended and the configuration issue described by CERT/CC only affects applications where the EXE does not already opt-in to ASLR. The configuration issue is not a vulnerability, does not create additional risk, and does not weaken the existing security posture of applications.
[...]
CERT/CC did identify an issue with the configuration interface of Windows Defender Exploit Guard (WDEG) that currently prevents system-wide enablement of bottom-up randomization. The WDEG team is actively investigating this and will address the issue accordingly.
Most of the press coverage that initially covered this story treated it as a classic he-said-they-said story. That's complicated by the fact that the feature in question is as difficult to explain as it is to configure. Let's break it down.
Address Space Layout Randomization (ASLR) is a fundamental security feature of every modern operating system. ASLR support was added to Windows more than a decade ago with the release of Windows Vista.
As the name explains, the point of ASLR is to randomize the memory addresses used by executable code (including DLLs) so that an attacker who finds a memory flaw, such as a buffer overflow, can't easily exploit it.
(For a thorough technical explanation of how ASLR works in combination with another security feature called Data Execution Prevention (DEP), see this StackExchange thread: "How do ASLR and DEP work?" For Microsoft's explainer on the implementation of ASLR in Windows 8 and later, see "Software defense: mitigating common exploitation techniques.")
Since 2010, developers of Windows programs have had the ability to opt in to ASLR support by setting the /DYNAMICBASE flag when they compile a program. If you run any Windows program that's been updated in the past six or seven years, it almost certainly supports ASLR natively.
even More Windows 10 Tips
In Windows 10, ASLR works just fine on programs that have opted in. That includes Office 2013 and Office 2016, every program in the Adobe Creative Cloud suite, modern browsers like Chrome and Firefox, every executable included with Windows itself, and every program distributed through the Windows Store.
(To confirm that ASLR is enabled for a process running on your PC, download and run the Microsoft Sysinternals utility Process Explorer and add the ASLR column.)
For those programs, which encompass the vast majority of what every Windows user does, day in and day out, ASLR is not broken, buggy, or worthless. It works exactly as it should, blocking the type of attacks that previously would have turned into zero-day exploits.
So, where's the problem?
The issue with ASLR on Windows 10 (and on earlier Windows versions, for that matter) arises when you run an older program that hasn't been compiled using the flag that opts in to ASLR. For compatibility reasons, Windows doesn't randomize the addresses of those programs. Because they're thus located at a predictable address in memory, they're more vulnerable to memory-based attacks.
In Windows 7 and Windows 8.x, you can use a tool called the Enhanced Mitigation Experience Toolkit (EMET) to force randomization of one of those older, insecure programs. (I wrote about EMET in 2011, calling it "The one security tool every Windows user should know about.")
Beginning with the just-released Windows 10 version 1709, Microsoft has deprecated EMET and has built its exploit mitigation functionality into the operating system. To get to this feature, called Windows Defender Exploit Guard (WDEG), open Windows Defender Security Center, click App & Browser Control, and then click Exploit Protection Settings.
These settings affect older programs that aren't explicitly ASLR-aware
As that screen indicates, you can change WDEG settings systemwide or on a per-program basis.
If you choose the per-program option, you have to identify the specific program and then adjust settings as shown here.
Enabling ASLR randomization for a specific program exposes these options
For my testing, I used a Windows utility that was last updated in 2008, before support for ASLR was added to Microsoft's development tools. That utility still works on Windows 10. (I've blurred the program's name, which isn't relevant to the discussion here.)
Turning on the option to force ASLR for this program relocates its base address in memory, but that location is still predictable and thus vulnerable to memory-related exploits.
The second option on that screen, Bottom-up ASLR, is what relocates the program's address to a truly random location in memory and prevents possible attacks. Unfortunately, in this case it also prevents the program from running.
The configuration issue that CERT/CC identified arises when you use the WDEG system settings to force all programs to run with ASLR. From the aforementioned Microsoft blog post:
Bottom-up randomization is enabled by default only if the process EXE opts in to ASLR. This is for compatibility reasons as applications whose EXE did not opt-in to ASLR (via /DYNAMICBASE) do not necessarily expect their address space layout to change from one execution to the next.
It's possible to override that behavior by modifying the registry in Windows 10 version 1709, but the preferred alternative is to enable this behavior on a per-program basis. As Microsoft notes:
One of the noteworthy observations that CERT/CC made is that enabling system-wide mandatory ASLR via EMET on Windows 7 does not exhibit the behavior described above. Instead, processes whose EXE did not opt-in to bottom-up ASLR are still observed to be randomized. The reason for this is that EMET on Windows 7 enabled mandatory ASLR using a different setting versus what is now used on Windows 8 and above.
[...]
The setting used by EMET on Windows 7 is not recommended and is intentionally hidden by default due to the application compatibility risk associated with it. EMET users must expose this setting by navigating to EMET's Advanced options as described here.
For most people, this behavior is a non-issue. Older programs that weren't written to support ASLR are inherently less secure than newer programs that support this security feature. If you must run an older program that's likely to be a target of attacks, you can enable ASLR and bottom-up randomization for that program and hope that it runs.