Skip to content
Naked Security Naked Security

Microsoft defends Windows 10 against ASLR criticism

It’s one of the oldest debates in software: is it a bug or a feature?

Is it a bug or a feature? It’s one of the oldest debates in software.

Earlier this month the OS world was treated to the latest instalment, this time focusing on the way Microsoft implemented a low-level security protection called Address Space Layout Randomization (ASLR) in Windows 8 and 10.

On one side of the argument is Will Dormann, an engineer with Carnegie Mellon University’s CERT Coordination Center (CERT/CC), the body tasked by the US Department of Homeland Security with handing out important security advice.

His opening salvo was a tweet on 16 November in which he described the way Windows implements ASLR as “essentially making it worthless.”


In case anyone was in doubt, this was followed by an official vulnerability alert describing the claimed failings in detail. The summary being:

Windows 8 and later fail to properly randomize every application if system-wide mandatory ASLR is enabled via EMET [Enhanced Mitigation Experience Toolkit] or Windows Defender Exploit Guard [WDEG].

Stung, within days Microsoft put out a refutation stating that “ASLR is working as intended.”

That’s a significant difference of opinion, so who is right?

Let’s skip to the paradox of a punchline: they both might be, albeit within different frames of reference.

The theory behind ASLR (also used in different forms by Linux, Android, iOS and macOS) is to randomise the memory locations where executable programs and DLLs run in order to deter memory attacks such as buffer overflows.

The gist is that attackers can’t assume they know the memory location for a targeted processes because Windows could have put it anywhere.

Except, according to Dormann, it doesn’t work properly:

Both EMET and Windows Defender Exploit Guard enable system-wide ASLR without also enabling system-wide bottom-up ASLR … 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.

Microsoft asserts that this is by design and is intended to allow older software not compiled to support ASLR to remain compatible:

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.

That “opt-in” is the /DYNAMICBASE flag which software can use to indicate to Windows that it’s compatible with ASLR (and the operating system can infer that if the flag is missing the software may not work correctly under ASLR).

Windows can treat applications that don’t “opt-in” in a number of different ways. It can leave them to determine their own memory location, move them to a different but non-random location (the behaviour observed by Dormann) or move them to a random location using a setting called mandatory ASLR and bottom-up randomization.

The CERT advisory also notes a problem in the way Windows Defender Exploit Guard implements mandatory ASLR and bottom-up randomization, a point Microsoft concedes:

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.

On the Windows 10 Fall Creators update, the issue can be mitigated manually by setting a registry value.

Neutrals might at this point be wondering what all the fuss is about: ASLR works most of the time as advertised, and the few occasions when it doesn’t won’t apply to many users.

If you like, Microsoft thought it was pragmatically ensuring compatibility (a feature) which Dormann interprets as an area of potential weakness (the bug).

It’s not the first time Dormann has taken a pop at Windows’ security: a year ago, his beef was Microsoft’s plans to drop EMET, now replaced in Windows 10 by WDEG.

Or perhaps the real issue is what users are supposed to make of a back and forth now so technically specialised that even some experts can’t keep up with its finer points.

OS security has been getting more complex with every passing year. It shouldn’t surprise us that the same is happening to arguments about whether these new layers inside Windows and its rivals are up to the job.


I’ve wondered why they don’t use something like PunkBuster for monitoring OS files. It worked pretty good for games.


The idea of ASLR is to prevent remote code injection in the first place, by making it difficult to the attackers to figure out where to aim in memory.

Monitoring the behaviour of running code and scanning memory for malicious artefacts are valid security techniques (any decent anti-virus does both), but ASLR is an earlier layer of defence than both of those.


Am I missing something? The way it is described sounds like they only don’t use ASLR for software that doesn’t explicitly state it’s compatible with it. Sodoes Will Dormann only want software to run that is compatible with ASLR and other software to just not work?


Has Microsoft not yet fixed the issue with the configuration interface of Windows Defender Exploit Guard (WDEG) that prevents system-wide enablement of bottom-up randomization? If its own personnel cannot deal competently with the issue, can its software be trusted to be adequately secure when an important anti-exploit mechanism cannot be relied upon?


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!