Merge pull request #1870 from HackTricks-wiki/research_update_src_binary-exploitation_common-binary-protections-and-bypasses_libc-protections_20260207_130210

Research Update Enhanced src/binary-exploitation/common-bina...

Author: carlospolop

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

@@ -10,10 +10,12 @@
 
 The enforcement of chunk alignment in 64-bit systems significantly enhances Malloc's security by **limiting the placement of fake chunks to only 1 out of every 16 addresses**. This complicates exploitation efforts, especially in scenarios where the user has limited control over input values, making attacks more complex and harder to execute successfully.
 
-- **Fastbin Attack on \_\_malloc_hook**
+- **Fastbin Attack on `__malloc_hook`**
 
 The new alignment rules in Malloc also thwart a classic attack involving the `__malloc_hook`. Previously, attackers could manipulate chunk sizes to **overwrite this function pointer** and gain **code execution**. Now, the strict alignment requirement ensures that such manipulations are no longer viable, closing a common exploitation route and enhancing overall security.
 
+> **Note:** Since glibc **2.34** the legacy hooks (`__malloc_hook`, `__free_hook`, etc.) are removed from the exported ABI. Modern exploits now target other writable function pointers (e.g. tcache per-thread struct, vtable-style callbacks) or rely on `setcontext`, `_IO_list_all` primitives, etc.
+
 ## Pointer Mangling on fastbins and tcache
 
 **Pointer Mangling** is a security enhancement used to protect **fastbin and tcache Fd pointers** in memory management operations. This technique helps prevent certain types of memory exploit tactics, specifically those that do not require leaked memory information or that manipulate memory locations directly relative to known positions (relative **overwrites**).
@@ -40,6 +42,18 @@ Pointer mangling aims to **prevent partial and full pointer overwrites in heap**
 3. **Requirement for Heap Leaks in Non-Heap Locations**: Creating a fake chunk in non-heap areas (like the stack, .bss section, or PLT/GOT) now also **requires a heap leak** due to the need for pointer mangling. This extends the complexity of exploiting these areas, similar to the requirement for manipulating LibC addresses.
 4. **Leaking Heap Addresses Becomes More Challenging**: Pointer mangling restricts the usefulness of Fd pointers in fastbin and tcache bins as sources for heap address leaks. However, pointers in unsorted, small, and large bins remain unmangled, thus still usable for leaking addresses. This shift pushes attackers to explore these bins for exploitable information, though some techniques may still allow for demangling pointers before a leak, albeit with constraints.
 
+### **Safe-Linking Bypass (page-aligned leak scenario)**
+
+Even with safe-linking enabled (glibc ≥ 2.32), if you can leak the mangled pointer and both the corrupted chunk and victim chunk share the same 4KB page, the original pointer can be recovered with just the page offset:
+
+```c
+// leaked_fd is the mangled Fd read from the chunk on the same page
+uintptr_t l = (uintptr_t)&chunk->fd;           // storage location
+uintptr_t original = (leaked_fd ^ (l >> 12));  // demangle
+```
+
+This restores the Fd and permits classic tcache/fastbin poisoning. If the chunks sit on different pages, brute-forcing the 12-bit page offset (0x1000 possibilities) is often feasible when allocation patterns are deterministic or when crashes are acceptable (e.g., CTF-style exploits).
+
 ### **Demangling Pointers with a Heap Leak**
 
 > [!CAUTION]
@@ -76,12 +90,13 @@ Pointer guard is an exploit mitigation technique used in glibc to protect stored
 4. **Alternative Plaintexts:** The attacker can also experiment with mangling pointers with known values like 0 or -1 to see if these produce identifiable patterns in memory, potentially revealing the secret when these patterns are found in memory dumps.
 5. **Practical Application:** After computing the secret, an attacker can manipulate pointers in a controlled manner, essentially bypassing the Pointer Guard protection in a multithreaded application with knowledge of the libc base address and an ability to read arbitrary memory locations.
 
-## References
-
-- [https://maxwelldulin.com/BlogPost?post=5445977088](https://maxwelldulin.com/BlogPost?post=5445977088)
-- [https://blog.infosectcbr.com.au/2020/04/bypassing-pointer-guard-in-linuxs-glibc.html?m=1](https://blog.infosectcbr.com.au/2020/04/bypassing-pointer-guard-in-linuxs-glibc.html?m=1)
+## GLIBC Tunables & Recent Loader Bugs
 
-{{#include ../../banners/hacktricks-training.md}}
+The dynamic loader parses `GLIBC_TUNABLES` before program startup. Mis-parsing bugs here directly affect **libc** before most mitigations kick in. The 2023 "Looney Tunables" bug (CVE-2023-4911) is an example: an overlong `GLIBC_TUNABLES` value overflows internal buffers in `ld.so`, enabling **privilege escalation** on many distros when combined with SUID binaries. Exploitation requires only crafting the environment and repeatedly invoking the target binary; pointer guard or safe-linking do not prevent it because corruption happens in the loader prior to heap setup.
 
+## References
 
+- [Safe-Linking bypass explanation (shellphish/how2heap)](https://deepwiki.com/shellphish/how2heap/5.2-safe-linking-bypass)
+- [Looney Tunables (CVE-2023-4911) write-up](https://www.wiz.io/vulnerability-database/cve/cve-2023-4911)
 
+{{#include ../../banners/hacktricks-training.md}}