Relocation Read-Only (RELRO) is a binary hardening feature that makes relocation tables read-only after program startup. It reduces the chance that attackers can overwrite dynamic linking structures to hijack execution. Defenders should build with RELRO enabled and treat missing or partial RELRO as a weaker memory corruption defence.
What RELRO Changes in a Binary
Relocation Read-Only, or RELRO, is a binary hardening measure that changes the memory protection of relocation data after startup. That matters because relocation tables are part of the dynamic linking machinery, and writable relocation state can become a target when memory corruption is present.
RELRO is not an exploit fix by itself. It reduces one class of post-load tampering, so it is best understood as a defence-in-depth control that complements compiler, linker, and memory-safety protections rather than replacing them.
Why RELRO Matters for Exploitation Resistance
In a vulnerable process, attackers often look for writable control data that can redirect execution without needing a full code overwrite. RELRO narrows that path by making specific relocation structures read-only after the loader finishes its work, which helps block GOT and related linkage tampering.
This is especially relevant in binaries that use dynamic linking heavily, because the attacker does not need to defeat the whole program, only to alter a small but influential part of its runtime metadata. RELRO therefore raises the bar for reliable code-reuse and hijack attempts.
Defenders should think of RELRO as a hardening signal, not a binary assurance of safety. A process can still be exploitable through other corruption paths, but missing or partial RELRO leaves a more permissive target surface for exploitation.
How RELRO Is Commonly Interpreted
Tooling typically reports RELRO in three practical states: absent, partial, or full. That classification is useful because it tells you whether relocation-related protections were applied only partially or whether the relevant relocation data was fully sealed after startup.
Security teams often use this as a build and audit check in software assurance workflows. It is a small signal, but it is an actionable one: if a release is expected to use stronger linker hardening and does not, that gap is worth investigating before deployment.
RELRO is also easy to misread as a general “safe binary” indicator. It is not. It only addresses a specific class of runtime mutation around dynamic linking structures, so it should be evaluated alongside other hardening choices such as stack protections, PIE, NX, and memory-safe coding practices.
Where RELRO Fits in Secure Build and Deployment Practice
RELRO belongs in the same practical conversation as compiler and linker hardening, secure build defaults, and release verification. A team that cares about exploit resistance should treat it as part of its baseline build posture, not as an optional optimization for security-sensitive components only.
It is most valuable when organisations verify binary properties before shipping, especially for internet-facing services, privileged utilities, and software that handles untrusted input. In those environments, small hardening gaps can materially change how far an attacker can progress after initial corruption.
For broader secure coding discipline, the same principle applies across the release pipeline: hardening features should be enabled consistently, checked automatically, and documented as part of the build standard. NHIMG’s Secure Coding Guide covers the wider secure-coding practices that RELRO sits alongside.
Risk and Threat Considerations
When RELRO is missing or only partially applied, writable relocation metadata can remain a useful target for memory-corruption exploitation. That increases the chance that an attacker can redirect control flow by tampering with dynamic linking structures instead of needing a more complex overwrite.
Failure mechanism: The linker leaves relocation-related state writable for longer than intended, so a corruption bug can mutate pointers or dispatch targets that should have been sealed after startup.
Impact: The process becomes easier to hijack through code-reuse or GOT-style redirection, which can turn a memory-safety bug into reliable execution control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | RELRO is a binary hardening measure that strengthens software build security against exploitation. |
| Recommendation — Enable hardened build defaults and verify binaries include exploit-mitigation flags before release. | ||
| NIST SP 800-53 Rev 5 | SI-16 — Memory Protection | RELRO reduces writable relocation attack surface in memory-corruption scenarios. |
| Recommendation — Apply memory-protection controls to reduce opportunities for runtime code hijacking. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | RELRO is a secure-coding and build-hardening measure for shipped binaries. |
| Recommendation — Require compiler and linker hardening checks as part of secure software architecture reviews. | ||
Practitioner Guidance
What to watch for: Treat RELRO as a release-quality check, not just a compiler flag. If a binary is expected to be hardened and the build or inspection output shows no RELRO or only partial RELRO, that is a meaningful security finding.
Governance implication: Organisations should make RELRO part of their standard binary-hardening baseline for software that executes with elevated trust, especially where exploitation of a single memory bug would be costly. The key decision is consistency, because hardening only helps when it is present across the relevant build estate.
Practitioner takeaway: Use RELRO as one layer in a broader hardening standard, and verify it continuously in build and release checks rather than relying on developers to remember it manually.