Windows 8 and Later Fail to Properly Apply ASLR, Here's How to Fix

Edit: I'm not sure what's up with the fix. I applied it through the .reg file and all was well for a day until I went to use Steam and play some games. Chaos ensued, Steam is acting like it was the first install and installing DirectX and all the rest. Call of Juarez: Gunslinger wouldn't launch, and DOOM launched but in FUBAR mode. Though I was able to discern what buttons to click on to set it right. I undid the registry change, rebooted, and now COJ: Gunslinger launched. A previous reinstall and reboot did nothing. The plot thickens as when I went into Windows Defender Settings Menu and I set both settings to enabled, and the problem returned after the reboot. Bottom up has a default of on. I went with that, rebooted, and now COJ: Gunslinger is working again. Bizarre, and I throw my hands up in surrender. I say avoid all of this, but keep it in mind.


I saw this posted at slashdot, read the higher ranked comments, looked at the article, and thought I'd check. Son of a gun, I didn't have it set the way they advise. I didn't even know those setting were there.

https://it.slashdot.org/story/17/11/17/207239/windows-8-and-later-fail-to-properly-apply-aslr

https://www.bleepingcomputer.com/ne...fail-to-properly-apply-aslr-heres-how-to-fix/



You have to click on that highlighted blue icon, and then click on Exploit protection settings in order to see the above options. Much ado about nothing, or what?

Edit: The fix might also involve editing the registry, so let’s put a pin in this. I can’t say to just go for it when it comes to regedit.
The title looke like it was Windows 8 related but the later part of it got me interested. Sigh. Gotta enable that option, then.
Could someone explain what this is and why I'd want it before I jump through all these hoops, in little words please that a very stupid person could understand. ;)
The second link kinda sums it up quite well and has pictures plus it includes a register file with a fix.
https://www.bleepingcomputer.com/ne...fail-to-properly-apply-aslr-heres-how-to-fix/
 
I have third party antivirus and I can see the options.


Only one of those security options was turned off at my end. Forcing ASR for programs not compiled with a certain flag was indeed off. (so for programs with the flag, ASR would still work by default)

I've no clue how reliable is the windows runtime in reading compiler flags (or how standardized they are for this situation) but it seems the default off is there in case somebody might be relying on fixed addresses when their program is executed. Which seems beyond silly, but one should never overestimate the avereage windows application developer?

(I do remember back in uni days when I built Visual studio programs under Vista how x64 compiled programs would do ASR by default , unlike compiling for x86 target)
 
Last edited:
I figured it out. It showed up after I updated to Windows Fall Update, build 1709 or later. I dont know why build 1703 wouldnt have had it.
That must be whats happening to me, I was under the mistaken impression that on the Windows Update tab when it saiz
'Windows Update: Your device is up to date, last checked today at 9am"
that that means my device is up to date, but no it doesnt mean that at all, silly me :cry:

heads up for anyone else, ignore what they say here, it could be wrong
Checkfor-updates-1024x645.png
 
Could someone explain what this is and why I'd want it before I jump through all these hoops, in little words please that a very stupid person could understand. ;)

ASLR means that when the OS runs an application, it put the application in a randomized location in the memory. Therefore, even if the application has some exploitable bug, it's much harder to make an attack works because the attacker will have to guess the correct memory location.
 
heads up for anyone else, ignore what they say here, it could be wrong
Yeah, that page is a liar. I've had it tell me that it checked just a few hours ago and was up to date, when in reality there's a big patch to download and install.

Ok, theoretically MS could have released that patch inside the relatively short intervening timespan between when my PC checked for updates and when I manually did it, but I'm sceptic.

Also, I've had windows start menu show no indication there's a patch laying wanting to restart my PC. Usually the text in the start menu changes to update and restart (or shutdown), but this one time it was just the plain olde standard update / restart. *shrug*
 
Yeah, that page is a liar. I've had it tell me that it checked just a few hours ago and was up to date, when in reality there's a big patch to download and install.

Ok, theoretically MS could have released that patch inside the relatively short intervening timespan between when my PC checked for updates and when I manually did it, but I'm sceptic.

Also, I've had windows start menu show no indication there's a patch laying wanting to restart my PC. Usually the text in the start menu changes to update and restart (or shutdown), but this one time it was just the plain olde standard update / restart. *shrug*

Actually it's worse than that. In my case, it said there's an update waiting restart to be installed. A few days later it's no longer there and saying there's no new updates. Naturally you'd expect it's already installed. But it's not, as when I clicked on the "install history" it says something like some updates are awaiting restart. So I restarted the computer (it didn't install anything), and now it says "update install failed @ [a few days ago]"...

Of course, I'm using pre-release software so maybe that's expected. But comparing version numbers shouldn't be that difficult.
 
FWIW I can now access the ASLR stuff with the latest windows update, which seems to improved some things, though windows still struggles with 4k monitors, some apps have become more blurry since the update :cry:, esp visual studio
 
So, the last few days had problems with my windows instllation : crypto coin wallets and gpu-z most notably failing to start. I was really annoyed as the messages gave nothing away. GPU-z never even throwed an error.

Turns out it was due to the "Force randomization of images" setting which I had turned on, saying "what could possibly go wrong?".
 
One has to wonder though, why would randomization make software fail?

I remember from my dusty old programmer's guide to the Commodore Amiga, one of the golden rules was to never rely on absolute addresses; the lone exception allowed was the so-called Execbase offset address ($4).

Surely the PC is governed by similar rulesets? :p
 
One has to wonder though, why would randomization make software fail?

I remember from my dusty old programmer's guide to the Commodore Amiga, one of the golden rules was to never rely on absolute addresses; the lone exception allowed was the so-called Execbase offset address ($4).

Surely the PC is governed by similar rulesets? :p

It partly because 8086 has this segmentation system, allowing a 64KB program to be loaded at any address (every 16 bytes) with 0 offset. Therefore, very old programs were able to assume the base offset is always 0.

But it's mostly about the unbelievable compatibility provided by DOS and Windows, which leaves a huge library of legacy applications with pitfalls here and there (e.g. Windows has quite a lot internal patches for individual applications).
 
Modern programs, even x64 software, really shouldn't fall prey to ancient segmentation stuff though. Must be programmers who are REALLY stuck in their old ways of doing things... :p

This is a big reason why the PCs suck, really. All this legacy crap cluttering up the architecture, complicating things and - these days - making security less effective. One wishes MS/Intel/AMD would just decide to make a clean break at some point. Out with the old, in with the new. Apple has done it several times, it worked for them. Now they're even phasing out (almost) everything 32-bit ARM-related other than their own embedded stuff.

Yes, it would be painful at first, especially for those fools who have kept on using ancient software because 'they have no other choice'. Even if you give say, two, three years' advance warning or even five, some will just keep pushing change out further and further until finally the day when they'll get cut off looms, and then they start crying "we didn't have enough time! boo hoo, you can't do this, it would kill us!", and then MS would get cold feet and change their mind. :???:
 
It partly because 8086 has this segmentation system, allowing a 64KB program to be loaded at any address (every 16 bytes) with 0 offset. Therefore, very old programs were able to assume the base offset is always 0.

But it's mostly about the unbelievable compatibility provided by DOS and Windows, which leaves a huge library of legacy applications with pitfalls here and there (e.g. Windows has quite a lot internal patches for individual applications).

Seems to me you are speculating still, though (as we all were ) . Doesn't seem to explain why something like GPU-Z fails when randomization of images is enabled, this is obviously not an ancient program.
 
Modern programs, even x64 software, really shouldn't fall prey to ancient segmentation stuff though. Must be programmers who are REALLY stuck in their old ways of doing things... :p

This is a big reason why the PCs suck, really. All this legacy crap cluttering up the architecture, complicating things and - these days - making security less effective. One wishes MS/Intel/AMD would just decide to make a clean break at some point. Out with the old, in with the new. Apple has done it several times, it worked for them. Now they're even phasing out (almost) everything 32-bit ARM-related other than their own embedded stuff.

Yes, it would be painful at first, especially for those fools who have kept on using ancient software because 'they have no other choice'. Even if you give say, two, three years' advance warning or even five, some will just keep pushing change out further and further until finally the day when they'll get cut off looms, and then they start crying "we didn't have enough time! boo hoo, you can't do this, it would kill us!", and then MS would get cold feet and change their mind. :???:

Well, it's OT but one main reason for backward compatibility is to protect people's investment in software. If you can't be sure that your software will still be running after your next upgrade, you'll be less likely to invest in software. It's not just about applications, it's also about libraries. Sometimes a library for a relatively common task can be pretty old (for example, some JPEG decoders are probably more than 10 years old).
Of course, it's quite different now. App stores are filled with free apps, and you can find tens of apps with basically the same function. That's probably also why Apple suddenly decided to make the cut with iOS 11 (before that, iOS actually has pretty good backward compatibility).
Virtualization is probably going to be the main approach for providing backward compatibility in the future (and it already is in a few places). Generally if you have to keep running some no-longer maintained legacy stuff, you probably don't need it to be fast.
 
While it's nice that a software investment will be 'protected', there's also limits we should go to but not beyond. Backwards compatibility can be an anchor creating drag on a platform, weighing it down with bad programming practices and old, outdated, wonky APIs/function libraries/DLLs people shouldn't be using. x86 CPUs are full of shit like this, old, bad, obsolete opcodes (like say, the entire x87 FPU), 16-bit compatibility mode and so on. If we could just cut all the old crud out of the design, make x86/x64 into a modern CPU with a modern, well-designed instruction set, that'd be great.

Not holding my breath for this to happen though.
 
GPU-Z fails when randomization of images is enabled, this is obviously not an ancient program.
Ancient enuf to not support hi DPI

edit: grall intel tried getting away x86, that didnt go well
also ARM
I would myself like to see a restart as long as intel is not in charge i.e have it controlled by a group, as intel will have a lot of propriety stuff in there, because well its intel and thats what they do
 
edit: grall intel tried getting away x86, that didnt go well
Yeah, well, itanic was a genuinely badly thought-out concept right from the start, it's not like everything HAS to end up like that just because you've pushed the reset button on your architecture! :)
 
Back
Top