Support of DEP/ASLR

[arko]

Greetings,

I have tried "Googling" this question, but was unable to find a definite answer that is specific to FP/Lazarus stack.

Is it possible to leverage ASLR (/DYNAMICBASE in Windows world) and DEP (aka /NXCOMPAT) for x86_64 applications built in Lazarus IDE? Former would mean that resulting binary has .reloc intact in addition to the relevant flag.

Relevant links:

• https://docs.microsoft.com/en-us/cpp/build/reference/dynamicbase-use-address-space-layout-randomization
• https://docs.microsoft.com/en-us/cpp/build/reference/nxcompat-compatible-with-data-execution-prevention

Thank you 

[440bx]

Is it possible to leverage ASLR (/DYNAMICBASE in Windows world)

In the project options "Compilation and linking" make sure "Relocatable" is checked.  That will cause the compiler to produce an exe that the loader can load anywhere it wants (it causes relocation entries to be added to the executable.)

DEP (aka /NXCOMPAT) for x86_64 applications built in Lazarus IDE?

The compiler has no control over that.  It is a Windows option.  If DEP is enabled and a program tries to execute data then it will cause an exception.  It's not much of a protection, it's easy to get around it.

HTH.

ETA:
While you're developing, testing and debugging the program, you're better off _not_ setting that option (relocatable -WR) because that way most everything stays at the same memory address from one execution to another (of course, that depends on any changes/additions that went into the data segment.)

[ASerge]

Is it possible to leverage ASLR (/DYNAMICBASE in Windows world) and DEP (aka /NXCOMPAT) for x86_64 applications built in Lazarus IDE? Former would mean that resulting binary has .reloc intact in addition to the relevant flag.

From Microsoft: On 64-bit versions of Windows, if hardware-enforced DEP is available it is always applied to 64-bit processes and kernel memory spaces and there are no system configuration settings to disable it. So, it's always On.
For ASLR add to project:

Code: Pascal  [Select][+][-]

1. const
2.   IMAGE_FILE_ADDRESS_SPACE_LAYOUT_RANDOMIZATION = $40;
3.  
4. {$SetPEOptFlags IMAGE_FILE_ADDRESS_SPACE_LAYOUT_RANDOMIZATION}

[PascalDragon]

Even if it's always on it's best to enable the NXCOMPAT flag as well:

Code: Pascal  [Select][+][-]

1. const
2.   // these are the names used in the Windows headers
3.   IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE = $0040;
4.   IMAGE_DLLCHARACTERISTICS_NX_COMPAT = $0100;
5.  
6.   // the directive does not support constant calculations :'(
7.   IMAGE_DLLCHARACTERISTICS_FLAGS = IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE or IMAGE_DLLCHARACTERISTICS_NX_COMPAT;
8.  
9. // set this in the main program file
10. {$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_FLAGS}

[marcov]

(I added the some extra flags to unit windows, to be merged to 3.2)

[arko]

Thank you, All! 

I have forwarded link to the forum of one particularly famous application: https://www.ghisler.ch/board/viewtopic.php?f=14&t=67728

Hopefully it will all work out well.

[marcov]

If I check with dumpbin and procxp as in the article for a 64-bit FPC 3.3.1 exe. , it seems the same thing is the case for FPC as for VLC.  (with Pascaldragon's code in a simple EXE)

dumpbin shows Relocs stripped, and while older versions of procxp says that aslr is enabled, newer ones don't.

Image base seems to be 0x1000000000

I also tried with the external (LD) linker (2.20, afaik from fpcbuild), and then it misses the "dynamic" bit, and image base is a more legacy 0x400000.

The article seems to suggest declaring the "main" as __declspec(dllexport) can force gld to generate the table, but I don't know how to do that in FPC.

I tried adding an "exports" clause with main, winmain or pascalmain, but that leads only to IE 2019050532's.

[arko]

dumpbin shows Relocs stripped, and while older versions of procxp says that aslr is enabled, newer ones don't.

Image base seems to be 0x1000000000

I also tried with the external (LD) linker (2.20, afaik from fpcbuild), and then it misses the "dynamic" bit, and image base is a more legacy 0x400000.

This makes me think of another Delphi-based application — TheBat! I have reported the issue to RitLabs, as the .reloc is present in binary, but image base is at  0x400000 no matter what.

Looking at PE signatures, they seem to use fairly modern Embarcadero Delphi v10.3 (Rio). I wonder why thoroughly commercial Embarcadero does not provide a solution, proper support of ASLR/DEP mitigations is rather important for business applications. Especially for one that is processing unknown content obtained from the Internet on daily basis.

Nevertheless, RitLabs has replied:

As a test we have checked the latest The Bat! v9.1.12 with the tool ASLR Process Scanner and got the confirmation that ASLR is enabled.

...Tried to gently call for common sense, pending further feedback...


Attached some relevant screenshots.