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:
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.— Will Dormann (@wdormann) November 15, 2017
Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ
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
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. ®