Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10

Martin Brinkmann
Nov 20, 2017
Updated • Nov 20, 2017

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, 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]

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: (Download Removed)

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)

Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10
Article Name
Microsoft Security Faux Pas: ASLR implementation issue on Windows 8 and 10
If you use Microsoft EMET or the new Windows Defender Exploit Guard your system may not have been protected properly by a protective feature called Address Space Layout Randomization (ASLR).
Ghacks Technology News

Tutorials & Tips

Previous Post: «
Next Post: «


  1. TelV said on November 23, 2017 at 2:02 pm

    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” appearing bottom right of the browser (Basilisk). Ctrl+F5 clears it.

  2. Noob said on November 22, 2017 at 12:46 pm

    Confirming that this “fix” ruined WordPress desktop app and it cannot start.

    1. FirehawkV21 said on November 23, 2017 at 7:26 am

      Some apps don’t support ASLR properly. Forcing ASLR breaks them.

  3. fred said on November 21, 2017 at 2:46 am

    Once the option was enabled I have already discovered a few random exe that completely refuse to run

  4. InGSoC said on November 20, 2017 at 10:45 pm

    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.

  5. chesscanoe said on November 20, 2017 at 8:08 pm

    For an expansive understanding of this problem and limitations on trying to circumvent it, see .

  6. James T. said on November 20, 2017 at 6:28 pm

    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?

  7. Sampei Nihira said on November 20, 2017 at 5:48 pm

    My registry value at default (mandatory ASLR off + bottom-up ASLR on) is:


    the correct value should be



  8. WD said on November 20, 2017 at 5:34 pm

    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.

    1. Rick said on November 20, 2017 at 6:41 pm

      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?

      1. Rick said on November 22, 2017 at 11:46 pm
      2. Rick said on November 21, 2017 at 2:32 am

        @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.

      3. WD said on November 20, 2017 at 10:21 pm

        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.

  9. Rick said on November 20, 2017 at 5:14 pm

    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.

Leave a Reply

Check the box to consent to your data being stored in line with the guidelines set out in our privacy policy

We love comments and welcome thoughtful and civilized discussion. Rudeness and personal attacks will not be tolerated. Please stay on-topic.
Please note that your comment may not appear immediately after you post it.