Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 04:33:28 +00:00
Code Issues Projects Releases Packages Wiki Activity

Update relro.md

Browse source
This commit is contained in:
RazviOverflow 2024-08-04 19:03:17 +02:00 committed by GitHub
parent 495183ab52
commit fb86216e8c
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 6 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
binary-exploitation/common-binary-protections-and-bypasses/relro.md
View file

@ -17,17 +17,19 @@ Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-s
## Relro ## 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. Let's break down the concept into its two distinct types for clarity: **Partial RELRO** and **Full 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**
**Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. By **positioning the GOT above the program's variables in memory, Partial RELRO aims to prevent buffer overflows from reaching and corrupting the GOT**.&#x20; **Partial RELRO** takes a simpler approach to enhance security without significantly impacting the binary's performance. Partial RELRO makes **the non-PLT part of the GOT section (usually referred to as .got from readelf output) read only**. Bear in mind that other sections like the .got.plt are still writeable and, therefore, subject to attacks. This **doesn't prevent the GOT** to be abused **from arbitrary write** vulnerabilities.
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**
**Full RELRO** steps up the protection by **making the GOT 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. **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. 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.