{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
RELRO stands for Relocation Read-Only, and it's a security feature used in binaries to mitigate the risks associated with GOT (Global Offset Table) overwrites. There are two types of RELRO protections: (1) Partial RELRO and (2) Full RELRO. Both of them reorder the GOT and BSS from ELF files, but with different results and implications. Speciifically, they place the GOT section before the BSS. That is, GOT is at lower addresses than BSS, hence making it impossible to overwrite GOT entries by overflowing variables in the BSS (rembember writing into memory happens from lower toward higher addresses).
Let's break down the concept into its two distinct types for clarity.
Partial RELRO takes a simpler approach to enhance security without significantly impacting the binary's performance. Partial RELRO makes the .got read only (the non-PLT part of the GOT section). Bear in mind that the rest of the section (like the .got.plt) is still writeable and, therefore, subject to attacks. This doesn't prevent the GOT to be abused from arbitrary write vulnerabilities.
Note: By default, GCC compiles binaries with Partial RELRO.
Full RELRO steps up the protection by making the entire GOT (both .got and .got.plt) and .fini_array section completely read-only. Once the binary starts all the function addresses are resolved and loaded in the GOT, then, GOT is marked as read-only, effectively preventing any modifications to it during runtime.
However, the trade-off with Full RELRO is in terms of performance and startup time. Because it needs to resolve all dynamic symbols at startup before marking the GOT as read-only, binaries with Full RELRO enabled may experience longer load times. This additional startup overhead is why Full RELRO is not enabled by default in all binaries.
It's possible to see if Full RELRO is enabled in a binary with:
readelf -l /proc/ID_PROC/exe | grep BIND_NOW
If Full RELRO is enabled, the only way to bypass it is to find another way that doesn't need to write in the GOT table to get arbitrary execution.
Note that LIBC's GOT is usually Partial RELRO, so it can be modified with an arbitrary write. More information in Targetting libc GOT entries.
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.