In this blog, we’ll cover some of the essential binary protections, that help keep our applications secure from various types of attacks. These protections include ASLR, DEP, SafeSEH, Strong Naming, Authenticode, Control Flow Guard, and High Entropy Virtual Address Space (VA). We will also see whether they apply to x64 or x32 systems.
1. ASLR (Address Space Layout Randomization)
ASLR randomizes the location of memory segments, such as the stack, heap, and libraries, to make it difficult for attackers to predict memory addresses and exploit buffer overflows or other memory-based vulnerabilities.
Imagine you have a program with a buffer overflow vulnerability. Without ASLR, an attacker can predict the memory address where the buffer will overflow and overwrite it with malicious code, which can then be executed. With ASLR enabled, the memory locations are randomized each time the program runs, making it much harder for the attacker to predict where their malicious code will go.
No specific code changes are required to enable ASLR; it’s more about the system configuration. On Windows, you enable ASLR by checking the corresponding option in the control panel or using a command.
Does it apply to x32 or x64? It applies to both x32 and x64, but with differences in effectiveness. For x64, it is fully supported and highly effective. On the other hand, for x32, it is supported, but its effectiveness is reduced due to the smaller address spaces.
2. DEP (Data Execution Prevention)
DEP prevents code from running in certain memory regions (like the stack or heap), protecting against attacks like buffer overflows, where attackers inject code into these regions to execute it.
Consider a buffer overflow vulnerability in a web server. Without DEP, an attacker could inject shellcode into the stack or heap and execute it. With DEP enabled, even if they manage to inject code into those regions, it won’t be executed because DEP blocks execution in non-executable regions.
No specific code is needed to implement DEP, but when compiling programs, you can ensure it’s enabled with the /NXCOMPAT flag (in Visual Studio, for example).
It works for both x32 and x64, but in different ways. For x64, it is fully supported and works well. For x32, it is supported, but it doesn’t work as well because of limitations in older hardware.
3. SafeSEH (Safe Structured Exception Handling)
SafeSEH is a Windows feature that prevents attackers from hijacking the exception handler table, a common method for exploiting structured exception handling (SEH) vulnerabilities.
When an attacker tries to exploit a vulnerable exception handler (such as in SEH overflows), SafeSEH prevents their payload from taking control by ensuring the exception handler table is properly validated.
Enable SafeSEH when linking the program by using the /SAFESEH flag in Visual Studio.
For x64, it is fully supported and enabled by default. However, for x32, it needs to be manually enabled using the /SAFESEH flag during the linking process.
4. Strong Naming
Strong naming is a technique in .NET to uniquely identify assemblies, preventing conflicts or tampering by attaching a cryptographic signature.
Imagine deploying multiple versions of a shared .NET library in your application. Without strong naming, attackers could replace the assembly with a malicious version that doesn’t match the expected signature. Strong naming ensures only the intended assembly is loaded, preventing tampering.
No code changes are needed to enable strong naming, but you can use the sn tool to generate a strong name key file and sign your assemblies.
Strong Naming works for both 32-bit and 64-bit .NET assemblies.
5. Authenticode
Authenticode is a digital signature standard for signing executables to ensure authenticity and integrity. It’s used to verify that the code is from a trusted publisher and hasn’t been altered.
Suppose you download an executable from the internet. Without Authenticode, an attacker could modify the executable, making it malicious. With Authenticode, the modified executable won’t pass the signature check, and the user will be warned about potential tampering.
You can sign executables by using tools like signtool or third-party tools. The code itself doesn’t require changes, only the signing step during deployment. And In Visual Studio, You can set up automatic code signing during builds.
Authenticode works for both 32-bit and 64-bit executables.
6. Control Flow Guard (CFG)
CFG is a security feature introduced by Microsoft to protect against control-flow hijacking attacks, such as Return-Oriented Programming (ROP), by validating indirect function calls.
Consider a program with a function pointer vulnerability. Without CFG, an attacker could change the function pointer to redirect the program’s flow. With CFG enabled, such modifications are blocked because CFG checks the validity of the function pointer before it’s executed.
CFG is enabled by default in Visual Studio for both x64 and x32 architectures, but you can ensure it’s turned on with the /guard option:
cl /GS /guard:cf my_program.cFor x64, it is fully supported and enabled by default. In contrast, for x32, it requires manual enabling using the /guard:cf flag.
7. High Entropy VA (Virtual Address Space)
High Entropy VA increases the randomness of virtual memory addresses, making it harder for attackers to predict the location of important memory regions (such as buffers). This adds a layer of protection against buffer overflow exploits.
Buffer overflow exploits often rely on predictable memory layouts. With High Entropy VA enabled, memory layouts are more randomized, making it extremely difficult for attackers to guess where the vulnerable code or buffers are located.
No code changes required for applications. You need to ensure High Entropy VA is enabled on the system. High Entropy VA is available on Windows 8 and later (for x64 systems). You can enable it by using the bcdedit command: bcdedit /set {current} nx AlwaysOn
bcdedit /set {current} nx AlwaysOnHigh Entropy VA is fully supported and effective on x64. However, it does not apply to x32 bit systems.
If you need to check if a Windows binary (EXE/DLL) has been compiled with ASLR, DEP, SafeSEH, StrongNaming, Authenticode, Control Flow Guard, and HighEntropyVA, use this GitHub power shell script by NETSPI - https://github.com/NetSPI/PESecurity
A very well-written and useful article. Thanks for sharing such valuable insights!