STE WILLIAMS

A Carnegie-Mellon CERT researcher has discovered the Microsoft broke some use-cases for its Address Space Layout Randomisation (ASLR), designed to block code-reuse attacks.

The bug is simple: as of Windows 8, a bug in Microsoft’s system-wide mandatory ASLR implementation meant applications were allocated addresses with zero entropy – in other words, they weren’t randomised. Windows 10 has the problem, too.

The bug was discovered by CERT/CC vulnerability 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.

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 using mandatory ASLR are affected;
• Applications that used opt-in ASLR aren’t affected;
• Applications that never used ASLR aren’t affected either way, of course.

The CERT/CC advisory explains that the problem introduced with Windows 8 was a change in the mandatory ASLR implementation: “system-wide mandatory ASLR is implemented via the HKLMSystemCurrentControlSetControlSession ManagerKernelMitigationOptions binary registry value. The other change introduced with Windows 8 is that system-wide ASLR must have system-wide bottom-up ASLR enabled to supply entropy to mandatory ASLR.”

The other problem was in Windows Defender Exploit Guard (and before it, the now-deprecated Enhanced Mitigation Experience Toolkit, EMET), because that’s where the developer chose whether or not to use ASLR.

However: “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.”

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.

Conclusion: Win10 cannot be enforce ASLR as well as Win7! pic.twitter.com/Jp10nqk1NQ

— Will Dormann (@wdormann) November 15, 2017

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); otherwise, it seems to El Reg customers would have to wait for application developers to make the change, and install an update. So far, Microsoft hasn’t published any fix. ®

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/11/21/microsoft_windows_8_address_space_layout_randomisation_weakness/