Add content from: Research Update: Enhanced src/binary-exploitation/common-bin...

src/binary-exploitation/common-binary-protections-and-bypasses/relro.md

@@ -4,35 +4,106 @@
 
 ## 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).
+**RELRO** stands for **Relocation Read-Only** and it is a mitigation implemented by the linker (`ld`) that turns a subset of the ELF’s data segments **read-only after all relocations have been applied**.  The goal is to stop an attacker from overwriting entries in the **GOT (Global Offset Table)** or other relocation-related tables that are dereferenced during program execution (e.g. `__fini_array`).
 
-Let's break down the concept into its two distinct types for clarity.
+Modern linkers implement RELRO by **re–ordering** the **GOT** (and a few other sections) so they live **before** the **.bss** and – most importantly – by creating a dedicated `PT_GNU_RELRO` segment that is remapped `R–X` right after the dynamic loader finishes applying relocations.  Consequently, typical buffer overflows in the **.bss** can no longer reach the GOT and arbitrary‐write primitives cannot be used to overwrite function pointers that sit inside a RELRO-protected page.
 
-### **Partial RELRO**
+There are **two levels** of protection that the linker can emit:
 
-**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.
+### Partial RELRO
 
-Note: By default, GCC compiles binaries with Partial RELRO.
+* Produced with the flag `-Wl,-z,relro` (or just `-z relro` when invoking `ld` directly).
+* Only the **non-PLT** part of the **GOT** (the part used for data relocations) is put into the read-only segment.  Sections that need to be modified at run-time – most importantly **.got.plt** which supports **lazy binding** – remain writable.
+* Because of that, an **arbitrary write** primitive can still redirect execution flow by overwriting a PLT entry (or by performing **ret2dlresolve**).
+* The performance impact is negligible and therefore **almost every distribution has been shipping packages with at least Partial RELRO for years (it is the GCC/Binutils default as of 2016)**.
 
-### **Full 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.
+* Produced with **both** flags `-Wl,-z,relro,-z,now` (a.k.a. `-z relro -z now`).  `-z now` forces the dynamic loader to resolve **all** symbols up-front (eager binding) so that **.got.plt** never needs to be written again and can safely be mapped read-only.
+* The entire **GOT**, **.got.plt**, **.fini_array**, **.init_array**, **.preinit_array** and a few additional internal glibc tables end up inside a read-only `PT_GNU_RELRO` segment.
+* Adds measurable start-up overhead (all dynamic relocations are processed at launch) but **no run-time overhead**.
 
-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.
+Since 2023 several mainstream distributions have switched to compiling the **system tool-chain** (and most packages) with **Full RELRO by default** – e.g. **Debian 12 “bookworm” (dpkg-buildflags 13.0.0)** and **Fedora 35+**.  As a pentester you should therefore expect to encounter binaries where **every GOT entry is read-only**.
 
-It's possible to see if Full RELRO is **enabled** in a binary with:
+---
+
+## How to Check the RELRO status of a binary
 
 ```bash
-readelf -l /proc/ID_PROC/exe | grep BIND_NOW
+$ checksec --file ./vuln
+[*] '/tmp/vuln'
+    Arch:     amd64-64-little
+    RELRO:    Full
+    Stack:    Canary found
+    NX:       NX enabled
+    PIE:      No PIE (0x400000)
 ```
 
-## Bypass
+`checksec` (part of [pwntools](https://github.com/pwncollege/pwntools) and many distributions) parses `ELF` headers and prints the protection level.  If you cannot use `checksec`, rely on `readelf`:
 
-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.
+```bash
+# Partial RELRO → PT_GNU_RELRO is present but BIND_NOW is *absent*
+$ readelf -l ./vuln | grep -E "GNU_RELRO|BIND_NOW"
+    GNU_RELRO      0x0000000000600e20 0x0000000000600e20
+```
 
-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](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#1---targetting-libc-got-entries)**.**
+```bash
+# Full RELRO → PT_GNU_RELRO *and* the DF_BIND_NOW flag
+$ readelf -d ./vuln | grep BIND_NOW
+ 0x0000000000000010 (FLAGS)              FLAGS: BIND_NOW
+```
+
+If the binary is running (e.g. a set-uid root helper), you can still inspect the executable **via `/proc/$PID/exe`**:
+
+```bash
+readelf -l /proc/$(pgrep helper)/exe | grep GNU_RELRO
+```
+
+---
+
+## Enabling RELRO when compiling your own code
+
+```bash
+# GCC example – create a PIE with Full RELRO and other common hardenings
+$ gcc -fPIE -pie -z relro -z now -Wl,--as-needed -D_FORTIFY_SOURCE=2 main.c -o secure
+```
+
+`-z relro -z now` works for both **GCC/clang** (passed after `-Wl,`) and **ld** directly.  When using **CMake 3.18+** you can request Full RELRO with the built-in preset:
+
+```cmake
+set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) # LTO
+set(CMAKE_ENABLE_EXPORTS OFF)
+set(CMAKE_BUILD_RPATH_USE_ORIGIN ON)
+set(CMAKE_EXE_LINKER_FLAGS "-Wl,-z,relro,-z,now")
+```
+
+---
+
+## Bypass Techniques
+
+| RELRO level | Typical primitive | Possible exploitation techniques |
+|-------------|-------------------|----------------------------------|
+| None / Partial | Arbitrary write | 1. Overwrite **.got.plt** entry and pivot execution.<br>2. **ret2dlresolve** – craft fake `Elf64_Rela` & `Elf64_Sym` in a writable segment and call `_dl_runtime_resolve`.<br>3. Overwrite function pointers in **.fini_array** / **atexit()** list. |
+| Full | GOT is read-only | 1. Look for **other writable code pointers** (C++ vtables, `__malloc_hook` < glibc 2.34, `__free_hook`, callbacks in custom `.data` sections, JIT pages).<br>2. Abuse *relative read* primitives to leak libc and perform **SROP/ROP into libc**.<br>3. Inject a rogue shared object via **DT_RPATH**/`LD_PRELOAD` (if environment is attacker-controlled) or **`ld_audit`**.<br>4. Exploit **format-string** or partial pointer overwrite to divert control-flow without touching the GOT. |
+
+> 💡 Even with Full RELRO the **GOT of loaded shared libraries (e.g. libc itself)** is **only Partial RELRO** because those objects are already mapped when the loader applies relocations.  If you gain an **arbitrary write** primitive that can target another shared object’s pages you can still pivot execution by overwriting libc’s GOT entries or the `__rtld_global` stack, a technique regularly exploited in modern CTF challenges.
+
+### Real-world bypass example (2024 CTF – *pwn.college “enlightened”*)
+
+The challenge shipped with Full RELRO.  The exploit used an **off-by-one** to corrupt the size of a heap chunk, leaked libc with `tcache poisoning`, and finally overwrote `__free_hook` (outside of the RELRO segment) with a one-gadget to get code execution.  No GOT write was required.
+
+---
+
+## Recent research & vulnerabilities (2022-2025)
+
+* **glibc 2.40 de-precates `__malloc_hook` / `__free_hook` (2025)** – Most modern heap exploits that abused these symbols must now pivot to alternative vectors such as **`rtld_global._dl_load_jump`** or C++ exception tables.  Because hooks live **outside** of RELRO their removal increases the difficulty of Full-RELRO bypasses.
+* **Binutils 2.41 “max-page-size” fix (2024)** – A bug allowed the last few bytes of the RELRO segment to share a page with writable data on some ARM64 builds, leaving a tiny **RELRO gap** that could be written after `mprotect`.  Upstream now aligns `PT_GNU_RELRO` to page boundaries, eliminating that edge-case.
+
+---
+
+## References
+
+* Binutils documentation – *`-z relro`, `-z now` and `PT_GNU_RELRO`*  
+* *“RELRO – Full, Partial and Bypass Techniques”* – blog post @ wolfslittlered 2023
 
 {{#include ../../banners/hacktricks-training.md}}
-
-
-