Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-20 01:55:46 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/binary-exploitation/common-binary-protections-and-bypasses/relro.md
Carlos Polop 6be43c15e9 Recreating repository history
2024-12-12 11:39:29 +01:00

4.6 KiB
Raw Blame History

Relro

{% 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
{% endhint %}

Relro

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

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

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

Bypass

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
{% endhint %}