System-wide Mandatory ASLR Failure to Properly Randomize (Win8+)

HxD.exe is always mapped at the same memory region because it lacks .reloc section.


To sum up:
if a binary is lacking relocation table (.reloc section), it can not be forced to be randomized regardless of WDEG setting (the same for eg for CFG, you can not force a binary to support such technology if that binary is not properly compiled because it lacks the required bitmap table of all the legitimate target locations the code can jump too)

 

So, in the 2nd screenshoot you can easily see that AIMP.exe is lacking .reloc section and is always mapped at the same memory region (across reboot etc regardless WDEG application-setting about ASLR) while it's dll are properly randomized...

 

Thanks for the detailed explanation. I knew that not all apps were compatible with ASLR but didn't know the reason why.

 

This brings up other points that needs mentioning. Once you apply the .reg fix to fully enable both system-wide ASLR and bottom-up ASLR, any individual app settings are no longer visible in the WD Security Center Exploit App setting except for some strange reason 7Z apps. This indicates to me that system-wide ASLR is indeed set to opt-out. So if individual app exploit settings were previously applied, they will be lost?



Also if you have previously applied the system-wide untrusted fonts mitigation, the .reg fix will negate that. So you need to set the first hex "00" value to "01."

 

https://www.bankinfosecurity.com/windows-10-security-feature-broken-us-cert-warns-a-10465

I think that for OS where mandatory ASLR is "Off" by default it is better to wait for a Microsoft patch rather than apply the registry modify.

Last night I did some tests with Powershell.
Result that today my registry value (Mandatory ASLR Off - Bottom - Up ASLR On) is:





Someone has similar values?
TH.

 

It also appears to me that one of EMET's most secure settings is missing from Win 10 1709(no more confusion on ref. @mood). That setting is deep hooks. I know its not enable since it previously conflicted with Eset's Online Payment Protection and I have had no conflicts with it since upgrading to 1709.

 

What shows up in WD Security Center Exploit settings?

 

Mandatory ASLR Off - Bottom - Up ASLR On



The values of by default.

 

Well you never did set the second hex "00" to "01" as instructed? As such, the default settings remained in place.

 

There is also the question of if all the ASLR "finagling" is worth it.

ASLR has been by bypassed software-wise by JavaScript nonetheless: http://www.securityweek.com/researchers-break-aslr-protection-javascript-attack and also hardware-wise: http://www.securityweek.com/researchers-bypass-aslr-hardware-vulnerability

 

If I change the value 21 to 01 (as it was yesterday), nothing changes.

__________________________________________________

@ All

Please your values.
TH.

 

Good point, indeed. If a user is running Windows 10 64-bit, any and all 64-bit applications will already have ASLR enforced by default during execution. Same goes for SEHOP and a few others. This tweak would be most beneficial for users running 32-bit apps still. There is a setting in Group Policy to enforce SEHOP on 32-bit apps as well which is quite important. Although I would always suggest to run 64-bit as much as possible anyway.

 

The recommended .reg fix is:

In other words, both the second and third hex values have to be set to "01."

 

Well, Adobe Reader is 32 bit. I also stupidly installed MS Office Pro 2010 many, many moons ago in default mode which is 32 bit. I can't find my CD to reinstall it as 64 bit.

 

Correct.
So in the end we have the first 3 values at "01".

But I will leave the second value at "00".

 

Yes, sometimes we don't have much of a choice. I am surprised that Adobe hasn't yet compiled Reader as 64-bit yet but I suppose maybe there is not much incentive for them to do so.

I still run Office 2010 Starter (click-to-run) which is also 32-bit. However, I do fortify it with all possible process mitigations and additional protection from MemProtect so that nothing can mess with the memory space (to or from).

 

Clarifying the behavior of mandatory ASLR
Link: https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/

You would have to read it all since it covers all aspects, EMET, and such. Matt Miller is a hugely respected researcher who has implemented many of MS process mitigations. Good read.

 

If anyone is curious, I've shared my Windows 10 RS3 (1709) research on Process Mitigations which is essentially just figuring out which binary bits do which mitigation and compiled in a simple spreadsheet.

Link: https://github.com/WildByDesign/GFlagsX/raw/master/MitigationOptions-RS3.xlsx

 

Thanks

 

Hum..... I thought the first hex "xx" setting in mitigations reg key value was used for untrusted fonts. Appears MS removed that in ver. 1703: https://blogs.technet.microsoft.com...dropping-the-untrusted-font-blocking-setting/ . Glad you posted your matrix of settings for that reg key value.

 

As far as this article goes, MS starts out with this statement:

They then digress into a long discussion on mandatory and bottom-up ASLR. Then they give token acknowledge that the CERT recommendation has substance:

And finally wrap things up with this statement:

and:

It is the convoluted and flat out misspeaking that has and always will lead me to disregard anything that Microsoft says in regards to OS security issues.

 

Last night I asked the question you can read in the picture below:



Repeated today............................

 

Hello,
I applied BleepingComputer fix and IntelliJ IDEA stopped working. What was default value for MitigationOptions in Windows 8.1 64-bit?

Edit:
I applied Sampei Nihira default value from Windows 10 and it is working well.

 

Hi.
Have you entered the values as default?

01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

or those with correction

01,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00