ASLR

[deltarho[1859]]

above 5.2 does accept the -fPIE switch

Using -Wc or -Wl?

If I use -Wl I am told that -f cannot be used without -shared, but when I use -shared I'm in trouble.

I tried this:
-gen gcc -Wc -O2 -Wc -pie -Wl -dynamicbase -Wl -highentropyva

No errors, no warnings but I could not see any mention of -pie in the compiler output.

Looking at the Properties sheet in Process Explorer I get this:

The top one is Encrypternet and the bottom one is 'MailWasher Pro'. Process Explorer still reckons Encrypternet has not got ASLR but 'MailWasher Pro' has.

Not seeing -pie in the compiler output is still telling me that we are not getting PIE/PIC.

I will now have a look at the link in your last post.

Added: I like his attitude.

is there an expert on PE headers on this forum that may be able to help?

Well, I am not for one.

[srvaldez]

@deltarho[1859]
when passing switches to gcc you only use Wc or Wl once (at least that's what I was told), for example
-gen gcc -Wc -O2,-pie -Wl -dynamicbase,-highentropyva

[deltarho[1859]]

From WikiPedia

Generating position-independent code is often the default behavior for compilers,

Except in our case.

[deltarho[1859]]

when passing switches to gcc you only use Wc or Wl once

I have tried on numerous occasions but could not get it to work. However, your example did. I know that I could repeat -Wc and so on so used that method. I have just put your example into a file I call, imaginatively, Notes; which has nearly seven hundred lines, with '----' separating each note. If only my private life was so organized - cannot have everything.

[srvaldez]

yes, I was told that only one of the switches will be passed on if you use multiple Wc or Wl
I jus downloaded PE Explorer, but being a complete noob to PE headers am not sure it will help much

[deltarho[1859]]

yes, I was told that only one of the switches will be passed on if you use multiple Wc or Wl

OK, but I think that you were told wrong.

Examples from Help:

Code: Select all

fbc -gen gcc -Wc -m32,--verbose,-include,some-header.h
fbc -gen gcc -Wc -m32 -Wc --verbose -Wc -include -Wc some-header.h

Found this:

Code: Select all

-fpie
-fPIE

    These options are similar to -fpic and -fPIC, but the generated position-independent code can be only linked into executables. Usually these options are used to compile code that will be linked using the -pie GCC option.

    -fpie and -fPIE both define the macros __pie__ and __PIE__. The macros have the value 1 for -fpie and 2 for -fPIE.

but how do we get them to work with our gcc builds?

linked using the -pie GCC option.

So we should use -Wl for -pie but what should we use for -fpie, -Wc?

Tried this:
"-gen gcc -Wc -O2,-fpie -Wl -pie,-dynamicbase,-highentropyva" but Encrypternet closes down straight away.

Tried this:
"-gen gcc -Wc -O2 -Wl -fpie,-pie,-dynamicbase,-highentropyva" and got "-f may not be used without -shared"

Tried this:
"-gen gcc -Wc -O2 -Wl -shared,-fpie,-pie,-dynamicbase,-highentropyva" and got "-f may not be used without -shared"

Tried this:
"-gen gcc -Wc -O2,-shared -Wl -fpie,-pie,-dynamicbase,-highentropyva" and got "-f may not be used without -shared"

How the heck do we get position independent code? If we cannot do it then we won't get ASLR.

[jj2007]

Are you aware of the other FB ASLR thread? viewtopic.php?t=26560

[srvaldez]

from that thread I gather that FB should be built with (compiler options) -gen gcc -Wc -fPIE and (linker options) -Wl -dynamicbase,-pie
I will have a try at it later, and see if I get lucky

[deltarho[1859]]

Are you aware of the other FB ASLR thread?

Hi Jochen, well I wasn't.

FB should be built with (compiler options) -gen gcc -Wc -fPIE

I think -fPIE is a linker option. In my case, using -Wc, "Encrypternet closes down straight away." and cbruce got "... myapp.exe runs but immediately exits".

I will have a try at it later, and see if I get lucky

Problem is if we cannot get gcc to write PIEs how are you going to get it to write PI libs? Another question is, for libs should we use PIE or PIC?

Good luck on that, it is well above my pay grade.

[Josep Roca]

See: https://www.kb.cert.org/vuls/id/307144/

mingw-w64 produces a executable Windows files without a relocations table by default, which breaks compatibility with ASLR.

ASLR is an exploit mitigation technique used by modern Windows platforms. For ASLR to function, Windows executables must contain a relocations table. Despite containing the "Dynamic base" PE header, which indicates ASLR compatibility, Windows executables produced by mingw-w64 have the relocations table stripped from them by default. This means that executables produced by mingw-w64 are vulnerable to return-oriented programming (ROP) attacks.

See: https://insights.sei.cmu.edu/cert/2018/ ... aults.html

This situation is made worse by the fact that several tools that check for ASLR compatibility assume that the presence of the "Dynamic base" PE header is sufficient for ASLR compatibility. Because Process Explorer does not check that a relocation table is present, its indication of "ASLR" for a running process may be incorrect, and it may provide a false sense of security.

[deltarho[1859]]

Thanks José.

Since Microsoft introduced ASLR 12 years ago what we have here, in my opinion, is absolutely scandalous. Of course, it isn't gcc's fault - gcc is a project using mingw-w64.

It looks like writing PI libs is not possible.

Oh dear, I may have to rewrite Encrypternet using PowerBASIC.

@José

How does your Windows API Headers III v.1.07 compare with WinFBX?

[srvaldez]

Hi deltarho[1859]
please try FreeBASIC-1.07.1-win32 gcc-8.3 using the compiler and linker options that caused your app to crash
FreeBASIC-1.07.1-win64 gcc-8.3
[edit]
-gen gcc -Wc -fPIE,-pie -Wl -dynamicbase

[Josep Roca]

> How does your Windows API Headers III v.1.07 compare with WinFBX?

There are differences because PB does not support overloading and multiple constructors, among other things, but in general they are easier to use because of the lack of strict type checking and because out parameters are declared as byref instead of byval ptr.

[Josep Roca]

I have found this thread: https://github.com/msys2/MINGW-packages/issues/5719

It begins talking about an issue with gcc-9.2.0-1:

The binaries in the new gcc-9.2.0-1 packages have ASLR enabled in their PE headers. This breaks using precompiled headers, as they can no longer be mapped at a predictable address. The previous package had 'good' binaries, with ASLR disabled. (This isn't a change in the package itself. I rebuilt the 9.1.0-3 package, and the resulting binaries were 'bad'.)

and ends with

With the updated gcc-9.2.0-2 packages released on 20190829, this is now fixed, at least for my workload.

[srvaldez]

thanks for the info Josep Roca
I have the 9.2.0 toolchain which was releases about a month ago, not sure it's the good release that the person was referring to