Application build-time techniques

RELRO prevents attackers from overwriting the Global Offset Table (GOT) and Procedure Linkage Table (PLT), which are used by dynamically linked binaries to resolve function addresses. Without RELRO, attackers who achieve arbitrary write can redirect library calls to malicious code.

Stack buffer overflow vulnerabilities (CWE-121)⁴ allow attackers to overwrite return addresses on the stack, redirecting execution when a function returns. Stack canaries place a random value on the stack between local variables and the saved return address. Before returning, the function verifies the canary is intact. If an overflow corrupts the canary, the program terminates before the attacker gains control.

GCC implements stack canaries with the -fstack-protector family of flags:

ARMORRED uses -fstack-protector-strong to balance security and performance:

Stack canaries are effective against classic stack overflow exploits but do not protect against heap overflows, format string vulnerabilities, or attacks that leak the canary value.

The NX bit marks memory regions as non-executable, preventing attackers from executing injected shellcode on the stack or heap. Without NX, stack overflow exploits can place machine code in a buffer and redirect execution to it. With NX enabled, attempting to execute code from these regions triggers a segmentation fault.

NX is implemented through hardware support (AMD NX bit, Intel XD bit) and enabled by the compiler by default on modern systems. The GNU linker marks the stack as non-executable using the -z noexecstack flag.

NX forces attackers to use return-oriented programming (ROP) or jump-oriented programming (JOP) instead of direct code injection. These techniques are significantly more complex and can be mitigated by additional protections such as CFI and SafeStack.

Address Space Layout Randomization (ASLR) randomizes the base addresses of the stack, heap, and libraries each time a program executes. This makes it difficult for attackers to predict the location of code or data, breaking exploits that rely on hardcoded addresses.

ASLR only works effectively if the executable itself can be loaded at a random address. This requires compiling the binary as a Position Independent Executable (PIE) using -fPIE -pie:

With PIE enabled, the entire address space is randomized:

ASLR is enabled at the kernel level. On Linux, check with:

A value of 2 indicates full ASLR is enabled. PIE combined with ASLR makes exploit development significantly more difficult by eliminating reliable addresses for ROP gadgets and data structures.

-D_FORTIFY_SOURCE replaces dangerous libc functions with bounds-checked variants that validate buffer sizes at runtime. When enabled, functions such as memcpy, strcpy, sprintf, and read are replaced with __memcpy_chk, __strcpy_chk, __sprintf_chk, and __read_chk.

These fortified functions validate that the destination buffer is large enough for the operation. If a buffer overflow is detected, the program aborts before memory corruption occurs.

FORTIFY_SOURCE requires optimization (-O1 or higher) because the compiler must determine buffer sizes at compile time. ARMORRED uses -D_FORTIFY_SOURCE=2 which enables additional checks:

ARMORRED achieves 50% fortification coverage in nginx. The unfortified functions are typically those where the compiler cannot statically determine buffer sizes. FORTIFY_SOURCE protects against:

• CWE-120: Buffer Copy without Checking Size of Input⁵
• CWE-126: Buffer Over-read⁶
• CWE-787: Out-of-bounds Write⁷

SafeStack is a Clang feature that separates the stack into two regions: a safe stack for return addresses and register spills, and an unsafe stack for everything else. This prevents stack buffer overflows in local variables from corrupting return addresses, even without stack canaries.

SafeStack is enabled with -fsanitize=safe-stack and requires the Clang compiler:

SafeStack provides protection even when stack canaries are bypassed through information disclosure attacks. It is enabled in both hardened and locked tiers.

Control Flow Integrity validates that indirect function calls and returns target legitimate destinations according to the program's control flow graph. This prevents ROP attacks and vtable hijacking by ensuring that control flow transfers only occur to valid locations.

Clang implements CFI with -fsanitize=cfi, which requires Link-Time Optimization (-flto) to analyze the entire program's control flow. CFI adds runtime checks before indirect calls, terminating the program if a violation is detected.

CFI has a performance cost and can break compatibility with certain dynamic linking patterns. Whether CFI is enabled depends on the specific image and tier. In the current nginx 1.26 build, CFI is enabled in the locked tier:

The following table summarizes binary hardening features for nginx 1.26. These specific values are for this image and version; other images may differ:

Consult the Images section for the checksec analysis of each specific image.

Users can verify hardening features in running containers using checksec:

Compare against the upstream image:

The presence of SafeStack and CFI in ARMORRED images demonstrates measurably stronger protection against memory corruption exploits.