Relocation Read-Only (RELRO)

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.

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.

Related resources from NHI Mgmt Group

• Why do read-only AI agents still create serious security risk?
• What breaks when AI coding agents can read project setup metadata?
• What breaks when an AI browser can read local files inside a user session?
• What breaks when a workload role can read too many secrets?