This article is more than 1 year old

Microsoft's memory randomization security defense is a little busted in Windows 8, 10

RIP ROP? Think again

A Carnegie-Mellon CERT researcher has discovered that Microsoft broke some use-cases for its Address Space Layout Randomisation (ASLR) mechanism, designed to severely hamper hackers' attempts to exploit security bugs.

The programming blunder is simple: as of Windows 8, a flaw in Microsoft's system-wide mandatory ASLR implementation meant applications were allocated addresses with zero entropy – in other words, where they were placed in memory was supposed to be randomized, but wasn't. Windows 10 suffers from the same problem, too.

It means return-oriented programming (ROP) attack code written to exploit vulnerabilities have a much, much higher chance of working and successfully infecting a system than previously expected.

The bug was found by CERT/CC analyst Will Dormann, and was published late last week, here.

Dormann was researching why Microsoft's equation editor opened Excel to remote code execution (fixed in last week's patch Tuesday list) when he discovered the ASLR slip-up.

Here's the summary of the bug:

Microsoft Windows 8 introduced a change in how system-wide mandatory ASLR is implemented. 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 randomise executables that do not opt in to ASLR.

It's important to note that while bad, the bug only affects a subset of applications:

  • Applications forced to used ASLR, via a mandatory system-wide policy, are affected;
  • Applications that opt into ASLR aren't affected;
  • Applications that never used ASLR aren't affected either way, of course.

Essentially, system-wide mandatory ASLR requires a feature called system-wide bottom-up ASLR to be enabled. Unfortunately, Windows Defender Exploit Guard nor the deprecated Enhanced Mitigation Experience Toolkit (EMET) don't switch on that latter part, thus derailing the forced ASLR. Exploit Guard can enable bottom-up ASLR, but doesn't from the user interface – you have to have to prod around in the registry to flip the switch:

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.

As Dormann tweeted:

As Dormann's tweet – and his Gist post – describe, sysadmins can set a registry value to force bottom-up ASLR, a wonderful task if you're in charge of a fleet of machines. So far, Microsoft hasn't published any fix. ®

More about


Send us news

Other stories you might like