Delphi has long had some support for ASLR and some of the other recommended Windows security flags. In the recent 11.1 release, Embarcadero made it easier to use those flags in both Delphi and C++Builder, by surfacing specific linker options, enabling them by default, and also building packages and applications that are part of
RAD Studio with those flags enabled.
More on these Windows*PE Flags
Data Execution Prevention (DEP)
Allows the system to mark one or more pages of memory as non-executable preventing code from running from these regions of memory, making it harder to exploit buffer overruns. You can read more about it in the
Microsoft documentation here.
Address Space Layout Randomization (ASLR)
Randomly arranges the address space positions of key data areas of a process, including the base of the executable and the positions of the stack, heap and libraries. Prevents exploitation of memory corruption vulnerabilities. You can read
more about ASLR on Wikipedia.
High-entropy 64-bit ASLR (Only in 64-bit applications)
Allows ASLR to use the entire 64-bit address space, as you can
read here.
Terminal Services
Create Terminal Server aware (TSAWARE) applications. This is not related with security and covered by Microsoft
here.
RAD Studio Improved Support
While
compiler flags existed before, the
RAD Studio
IDE now exposes these flags as linker options. You can see below the settings for Delphi and C++ Windows compilers (thanks for the images to Jim McKeeth)
A Couple*of Caveats
The*ASLR compiler configuration works as expected for Delphi applications that use runtime
package. For programs that link in libraries in the executable, there is a conflict with the way programs refer to delayed loaded
DLL functions, which is preventing the expected behavior. This is an issue Embarcadero found after the release and would provide a fix for in the (near) future.
As you can see below, for an app with runtime packages, you get the proper configuration, as shown by SysInternals Process Explorer:
In general notice that these flags enforce security and there is a chance that an application using low-level code might not work any more. For example, we discovered that some old
ActiveX control don't work in the
IDE any more, due to a conflict with the DEP flag.
If you see any issue in your applications, you can disable these flags, but we recommend looking into the underlying issue, as some companies as starting to require that all of the software they use is built with all of the Microsoft recommended security flags enabled.
Weiterlesen...