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
- Open the Registry Editor app.
- 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.
- 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
- 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:
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:
I do not have “MitigationOptions” key in that location – WIN10 64bit LTSB 10240
Then You should create it.
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.
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
Thanks! Fixed.
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!
After applying this WordPress PC app cannot start, cannot login on my site etc. Thanks for nothing.
your fix is wrong:
https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/
Actually, that’s not my fix. This is a solution offered by CERT.
But yeah, I see a missing 00 pair.
Adding, thank you.
i understand it and i mean you should post a microsoft’s version of the story
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.”
done.
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.
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/
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.