Beware: Windows incorrectly implements ASLR, Fix is Available

Windows Win Logo Icon 7

Starting with Vista, Windows comes with Address space layout randomization (ASLR). ASLR is a computer security technique involved in preventing exploitation of memory corruption vulnerabilities. In order to prevent an attacker from reliably jumping to, for example, a particular exploited function in memory, ASLR randomly arranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap and libraries. There is a bug in Windows 8 and above that makes this  technique useless, but you can fix it.

The ASLR (Address Space Layout Randomization) feature was first introduced in Windows Vista. It allows preventing code-reuse attacks. ASLR  provides random memory address to execute code.

In Windows 8, Windows 8.1 and Windows 10 the ASLR feature doesn't work properly. Due to wrong configuration defaults, ASLR is not using random memory addresses.

Update: There is an official blog post on Technet that explains the sutiation. Read it here: Clarifying the behavior of mandatory ASLR.

The post says:

The configuration issue is not a vulnerability, does not create additional risk, and does not weaken the existing security posture of applications.

A post on CERT explains the issue in detail.

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.

Thankfully, it is easy to fix the issue.

Fix ASLR in Windows 8, Windows 8.1 and Windows 10

  1. Open the Registry Editor app.
  2. Go to the following Registry key.
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel

    See how to go to a Registry key with one click.

  3. On the right, create a new REG_BINARY value named MitigationOptions and set its value data to
    00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

  4. To make the changes done by the Registry tweak take effect, restart Windows 10.

To save your time, you can download the following Registry tweak:

Download Registry Tweak

That's it.

Support us

Winaero greatly relies on your support. You can help the site keep bringing you interesting and useful content and software by using these options:

If you like this article, please share it using the buttons below. It won't take a lot from you, but it will help us grow. Thanks for your support!

Author: Sergey Tkachenko

Sergey Tkachenko is a software developer who started Winaero back in 2011. On this blog, Sergey is writing about everything connected to Microsoft, Windows and popular software. Follow him on Telegram, Twitter, and YouTube.

15 thoughts on “Beware: Windows incorrectly implements ASLR, Fix is Available”

  1. Yeah, this registry “fix” completely killed both Wise Disk Cleaner and iSkysoft iMedia Converter on my Windows 10. Coincidence both programs are Chinese haha? I have used both programs for years and will continue to do so.

  2. Hi Sergey,

    I think you are missing a ‘0’ from the third last pair of digits (both on this page and the reg download).
    You have: “00,01,01,00,00,00,00,00,00,00,00,0,00,00”
    Shouldn’t it be: “00,01,01,00,00,00,00,00,00,00,00,00,00,00”
    Cheers
    John

  3. It’s funny to see this when Microsoft advertises Windows 10 is the most secure Windows ever and warns Windows 7 is dangerously insecure earlier this year!

    1. Actually, that’s not my fix. This is a solution offered by CERT.
      But yeah, I see a missing 00 pair.
      Adding, thank you.

        1. and the version is
          “The configuration issue is not a vulnerability, does not create additional risk, and does not weaken the existing security posture of applications.”

  4. I am not sure if this “fix” doesn’t enable mandatory ASLR even if you don’t set it in the GUI of 1709. That would be bad, because I would not advise users to enable mandatory ASLR anyway. This breaks old apps without providing much more protection if the app is 32 bits anyway, since the address space is not large enough to ensure adequate entropy.

    So, ignoring this warning and only using opt-in ASLR (not mandatory) is probably the best option for most people. This will likely not have any consequence on their day to day computing experience as they were probably not using mandatory ASLR in the first place and the fix might activates mandatory ASLR in addition to making it work properly while it was simply off by default before.

    Remember that for ASLR to protect you, the app protected needs to be targeted specifically by a specific malware. Most people should be more scared to hit a drive-by download that targets Flash than an old app they use that is not that popular, plus they would have to have this app read an infected file from the Internet or infected data gathered from a specific location the software looks at. That seems like a pretty low risk to me.

  5. Read this before going anywhere near that fix posted above:
    https://www.askwoody.com/forums/topic/issue-if-system-wide-mandatory-aslr-is-enabled-in-emet-or-win-def-explo-guard/

  6. I think this post should be corrected, at least you should include that:

    Enabling system-wide mandatory ASLR on Windows will result in a lot old software crash, and what even i worse:

    Taken from MS

    “In our tests we encountered issues in a common use scenario where having ASLR set to “Always On” would cause a system to blue screen during boot. This occurred because the address space for certain third party video drivers was being randomized. These drivers had not been built to support this randomization and subsequently crashed, causing the whole system to crash as well.”

    So US-Cert mitigation patch published here, may be applied only before official patch from MS came out.

    Also Windows 10 Creator Update (1709), has Exploit Guard built-in, so applying this patch will cause more harm, than security.

Leave a Reply

Your email address will not be published.

Exit mobile version
Using Telegram? Subscribe to the blog channel!
Hello. Add your message here.