Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10
If you use Microsoft EMET on Windows 8.x or Windows 10 machines, or the new Windows Defender Exploit Guard on Windows 10 version 1709, your system may not have been protected properly by a protective feature called Address Space Layout Randomization (ASLR).
Security researcher Will Dormann of the CERT/CC discovered an ASLR implementation issue on Windows 8 and Windows 10 machines.
Microsoft introduced ASLR in Windows Vista to prevent code-reuse attacks by randomizing the addresses that executable files were loaded in on the operating system.
While applications can make use of ASLR directly, Microsoft EMET could be used to add system-wide or application-specific support for ASLR on Windows machines.
Microsoft announced plans to retire Microsoft EMET recently, and added exploit protections to the company's Windows 10 Fall Creators update version of Windows 10 as a substitution.
According to the disclosure on Cert.org, Microsoft introduced a change in the handling of ASLR. Basically, what Microsoft did was add another requirement so that system-wide ASLR required system-wide bottom-up ASLR as well.
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 randomize executables that do not opt in to ASLR.
The effect is problematic from a security point of view as the address of applications becomes predictable even if system-wide ASLR is enabled via EMET or Exploit Guard in Windows 10 Version 1709.
Luckily, there is a workaround for the issue. All that needs to be done is enable ASLR and bottom-up ASLR on the target machine to fix the issue.
Note: It is recommended that you back up the Registry before modifying it. Also note, that importing the value will overwrite any system wide mitigations specified by the Registry value.
This is done by importing the following Registry value:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00
You can do this the manual way, but it is faster if you create a Registry file and import it instead. We have created the Registry file for you, so that you only have to double-click on it to import the data.
Download it with a click on the following link: aslr.zip
Just extract the downloaded archive, and double-click on the Registry file to import the data in the Registry. You can open the file in any plain text editor first to evaluate what it does before you do so. (via Born City)
Everyone will just run to implement the Registry change, but I think it’s a little more nuanced than that. Martin, maybe you can clear this up.
The key phrase in the source article for the Registry change is: “Enable system-wide bottom-up ASLR **on systems that have system-wide mandatory ASLR**.”
I just checked Windows Defender Security Center on 1709, and of all the related settings, Mandatory ASLR is the only one defaulting to OFF. So, 1709 out of the box does not meet the above statement.
I have to wonder why Mandatory ASLR is off by default. MS might have a good reason to do so, like application compatibility. I’m assuming that if you want it ON though in 1709, Windows Defender Security Center is the place to do it.
That action may or may not be in place of the Registry change, it’s unclear. Maybe you should also do the Registry change. But my point is that it maybe shouldn’t be on at all.
The registry file in this article enables both system-wide mandatory ASLR (the second byte, which is ‘0x01’), and system-wide bottom-up ASLR (the third byte, which is ‘0x01’). So importing the registry change will indeed enable proper system-wide mandatory ASLR with the entropy that it needs to function.
The latter is already enabled on 1709, so is simply flipping Mandatory ASLR to its ON state via the UI in 1709 the same as implementing the .reg file? It sounds like you’re saying that it is.
But, again, the question of why it’s off by default in 1709 must be raised (MS didn’t leave it that way accidentally). If applications need to be written for it, and they aren’t, what happens?
Bottom-up ASLR is *not* enabled by default in Windows 1709. Despite the Windows Defender Exploit Guard GUI telling you that it is, the underlying registry value is 0x00 (unset) in a clean Windows install. Toggling it off and then back on again will correct the underlying registry value.
@WD: There is no “MitigationOptions” (or “MitigationAuditOptions”) at all on a clean install–until you visit the UI to toggle things.
How are you testing for the presence or absence of any of them when there’s no Registry value to check against?
However, once you toggle one off/on, “MitigationOptions” is all zeroes.
I had a feeling that there was more to the story:
https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr
My registry value at default (mandatory ASLR off + bottom-up ASLR on) is:
01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
the correct value should be
01,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00
Correct?
It took three full operating systems to figure this out
Was someone asleep at the wheel at M.Soft or will we find out later from WikiLeaks?
For an expansive understanding of this problem and limitations on trying to circumvent it, see
https://www.kb.cert.org/vuls/id/817544 .
Hello, activated Exploit Protection in Windows Security Center is NOT enough?
But i am sitting behind a Routerfirewall + Windowsfirewall + Panda Security including Heuristicanalysis and Processmonitor.
Never had any issues since Panda installed, so System is clean and smooth.
Why is there a Reason to use Emet, if it is already implemented in WSC in Windows 10?
I guess i am safe.
Greets, InGSoC.
Once the option was enabled I have already discovered a few random exe that completely refuse to run
Confirming that this “fix” ruined WordPress desktop app and it cannot start.
Some apps don’t support ASLR properly. Forcing ASLR breaks them.
Windows Defender is disabled and I don’t have EMET installed so I assume my 8.1 system isn’t vulnerable. Have I got that right?
By the way, when I click the Submit button the page hangs with “Read pagead2.googlesyndication.com” appearing bottom right of the browser (Basilisk). Ctrl+F5 clears it.