ASLR

[deltarho[1859]]

Over at the PowerBASIC forums there is a discussion on ASLR (Address Space Layout Randomization), I had never heard of it. I knew what DEP (Data Execution Prevention) is and have that set globally; as most of you probably have. ASLR is not enabled in Windows 10 and the gcc compilers do not force it either. It worth reading up ASLR if it is new to you as well.

Adding the columns ASLR and DEP to SysInternals Process Explorer I could see that the many processes have ASLR enabled. At PB the opening post gave a link to a utility which will add ASLR to either a dll or exe.

However, after some digging I found a way to add it our gcc compilations by adding '-Wl -dynamicbase' to our compiler options. I compiled Encrypternet without this option and Process Explorer told me that ASLR was not enabled, with the option ASLR was enabled. It seems that ASLR was added to Windows 7 and later.

Now for most ASLR is probably not important but for my Encrypternet application, and for some of your applications, it is a must-have addition. Both 32-bit and 64-bit Encrypternet are now ASLR enabled.

[srvaldez]

hello deltarho[1859]
I downloaded Process Explorer and tried on a test program, the compiler option seems to make no difference, or am I missing something?
in both cases I get the confusing statement: Address Space Load Randomization: Enabled(permanent)Disabled
or is there another way to check?
btw, from my very brief Google search, it seems that the option is a rather recent addition to gcc, at least that's what I gather from a post in 2016 asking that it be added

[srvaldez]

hello deltarho[1859]
I need to do more testing, now I get it, Enabled(permanent)Disabled means enabled
however, please check with other compilers and toolchains, I will do the same
the result in first post was from a rather recent gcc toolchain
[edit]
on 64-bit it's enabled with or without the switch but on 32-bit it's disabled with or without the switch regardless of gcc compiler version.

[deltarho[1859]]

Nothing is straight forward, is it?

I cannot get ASLR at all now!

In 32-bit I don't get DEP enabled but in 64-bit I do. However, in 32-bit I can force it with '-Wl -nxcompat'. That is with gcc 5.2.

I'm off out shortly but tomorrow I will do further testing.

ASLR was first implemented on Linux in 2005. In 2007, the technique was deployed on Microsoft Windows and MacOS.

GCC should have got their act together long before now!

I can see us producing a table with what we need to do with what. 'Yer gotta' laugh.

Apparently Microsoft published a patch to force ASLR for Windows 7 - I'll check that out. One thing is for sure, if we write a security process we must use ASLR.

[badidea]

GCC should have got their act together long before now!

I am not an expert on this (first time I read about it), but it seems to be called PIE in GCC, see: https://www.theurbanpenguin.com/aslr-ad ... omization/
And according to Wikipedia, actually implemented on linux in 2003 and enabled on in the kernel (in a weak form) in 2005. If linux supports it sine 2003, I expect that GCC supports it since 2003.

[deltarho[1859]]

I got back early.

@badidea

Our gcc did not recognize PIE.

In 32-bit I don't get DEP enabled but in 64-bit I do. However, in 32-bit I can force it with '-Wl -nxcompat'.

In 'Performance Options>Data Execution Prevention' I had 'Turn on DEP for essential Windows programs and services'. I have never touched that, ever! I have now changed that to 'Turn on DEP for all programs and services except those I select:' I am now getting DEP enabled for both 32-bit and 64-bit compilations. Why I got DEP for 64-bit with the other radio button selected is beyond me, unless gcc did it for me.

I compiled Encrypternet without this option and Process Explorer told me that ASLR was not enabled, with the option ASLR was enabled.

This is no longer working. It seems my system is saying: "Yeah, OK, I did allow it but I have now changed my mind"

A consensus with syntax would be helpful: For gcc I have seen -Wl,-dynamicbase, -Wl,--dynamicbase and -Wl -dynamicbase. Our gcc did not like the first one but accepted the last two - neither of which work, with the last one no longer working.

Apparently Microsoft published a patch to force ASLR for Windows 7

Last update for that is Jan 4, 2013 but the certification is now failing so Windows rejected the installation.

Found a Microsoft registry script for ASLR opt in called, wait for it, optin.reg to force ASLR for apps which do not opt in with dynamicbase.

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] 
"MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

That didn't work so I Googled MitigateOptions. That script is the default. We have to mess about with the bits as follows.

Code: Select all

"MitigationOptions"=hex:01,01,01,00,00,00,00,00,01,00,00,00,00,00,00,01

Bit 0 enables DEP, bit 8 is FORCE_RELOCATE_IMAGES_ALWAYS_ON, and bit 15 is BOTTOM_UP_ASLR_ALWAYS_ON.

Guess what? That hasn't worked either.

on 64-bit it's enabled with or without the switch but on 32-bit it's disabled with or without the switch regardless of gcc compiler version.

I am not getting that.

It would seem that I have unwittingly walked into a minefield.

I am not worried. Why? Well, because I will get Encrypternet to permanently use ASLR even if it kills me.

[deltarho[1859]]

At PB the opening post gave a link to a utility which will add ASLR to either a dll or exe - see PESecinfo V1.0

I ran this at the command prompt:

Code: Select all

E:\Downloads\PESecInfo.exe E:\FreeBASIC\InternetEnc-Dec\Encrypternet.exe -e aslr

According to Process Explorer it did not work, so I ran it again and got 'ASLR is already Enabled.

This begs the question: Does anyone check their code any more before publishing on the internet. Perhaps I am old-fashioned because I do.

I am now looking for something else to confirm whether Encrypternet has ASLR or not.

[deltarho[1859]]

My latest info is that we must generate position independent executables ie use gcc's -fpie and -Wl -pie; which may explain why none of the methods tried above are working. So even if ASLR is enabled it will not work unless we have positioned independent executables. Our gcc does not know what fpie or pie is.

I don't know why I saw ASLR in Process Explorer when I first used dynamicbase.

I also don't know why srvaldez is getting it with 64-bit unless he is looking at DEP and not ASLR? 'Enabled (permanent)' is to do with DEP. With ASLR we get ASLR in Process Explorer's ASLR column or blank.

I will get Encrypternet to permanently use ASLR even if it kills me.

I am starting to feel decidedly unnecessary.

I wonder if when the toolchains are built there is an option to allow positioned independent executables ie allow -fpie and -Wl -pie because I am seeing them mentioned quite a lot at stackoverflow.

[deltarho[1859]]

With regard "MitigationOptions" it seems that I should have read from right to left and not left to right. So, I tried this:

Code: Select all

"MitigationOptions"=hex:01,00,00,00,00,00,00,01,00,00,00,00,00,01,01,01

Needless to say that did not make a blind bit of difference.

I have been looking at gcc 8.3 and 9.2.

This thread has turned out to be a disaster area.

So, Windows first deployed ASLR twelve years ago but our versions of gcc compile binaries which cannot exploit it even when a process has ASLR enabled. That is not good, is it?

At least I got DEP working regardless otherwise Encrypternet would have running with the door wide open.

[deltarho[1859]]

Bad news!

I compiled a small program using PowerBASIC and used PESecInfo.exe to add ASLR. It is showing in Process Explorer as ASLR & DEP.

I am not a happy sausage.

[deltarho[1859]]

Of course there may something in Encrypternet which is upsetting the apple cart. So, I compiled dodicat's Pool program using -Wl -dynamicbase and Process Explorer said no to ASLR. I then ran PESecInfo.exe to add ASLR but it said it was already enabled.

I then compiled Encrypternet using '-gen gas' and then used PESecInfo.exe to add ASLR but Process Explorer said no to that as well.

I am now expecting to turn a stone over and get bitten by something.

I am not at my wits end yet, but I am working on it.

FWIW, I reckon that the problem is not being able to get PIEs with gcc or gas.

[deltarho[1859]]

Found -fPIC instead of -fPIE. That is also an invalid command line option.

Seven posts in a row - I am starting to crumble.

[srvaldez]

Hi deltarho[1859]
I read your posts, but I have nothing to contribute except that gcc above 5.2 does accept the -fPIE switch, at least no warning is given, however nothing seems to work regarding setting ASLR
I will test the PB exe's and see if it works
[edit]
perhaps there's some abnormality in the PE header?

[srvaldez]

some year ago don't remember in which forum, Mike Lobanovsky mentioned that mingw did not produce proper dll's, something about a table, I wonder if mingw is producing executables that are not 100% Windows compliant?

[srvaldez]

found it, see https://www.thinbasic.com/community/sho ... #post90519
and https://www.thinbasic.com/community/sho ... #post90523
now the question is, is there an expert on PE headers on this forum that may be able to help?