GITBOOK-4355: No subject

SUMMARY.md

@@ -731,6 +731,7 @@
   * [Use After Free](binary-exploitation/heap/use-after-free/README.md)
     * [First Fit](binary-exploitation/heap/use-after-free/first-fit.md)
   * [Double Free](binary-exploitation/heap/double-free.md)
+  * [Overwriting a freed chunk](binary-exploitation/heap/overwriting-a-freed-chunk.md)
   * [Heap Overflow](binary-exploitation/heap/heap-overflow.md)
   * [Unlink Attack](binary-exploitation/heap/unlink-attack.md)
   * [Fast Bin Attack](binary-exploitation/heap/fast-bin-attack.md)

binary-exploitation/heap/bins-and-memory-allocations.md

@@ -167,6 +167,10 @@ tcache_init(void)
 
 </details>
 
+#### Tcache Indexes
+
+The tcache have several bins depending on the size an the initial pointers to the **first chunk of each index and the amount of chunks per index are located inside a chunk**. This means that locating the chunk with this information (usually the first), it's possible to find all the tcache initial points and the amount of Tcache chunks.
+
 ### Fast bins
 
 Fast bins are designed to **speed up memory allocation for small chunks** by keeping recently freed chunks in a quick-access structure. These bins use a Last-In, First-Out (LIFO) approach, which means that the **most recently freed chunk is the first** to be reused when there's a new allocation request. This behaviour is advantageous for speed, as it's faster to insert and remove from the top of a stack (LIFO) compared to a queue (FIFO).

binary-exploitation/heap/overwriting-a-freed-chunk.md

@@ -0,0 +1,47 @@
+# Overwriting a freed chunk
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>
+
+Several of the proposed heap exploitation techniques need to be able to overwrite pointers inside freed chunks. The goal of this page is to summarise the potential vulnerabilities that could grant this access:
+
+### Simple Use After Free
+
+If it's possible for the attacker to **write info in a free chunk**, he could abuse this to overwrite the needed pointers.
+
+### Double Free
+
+If the attacker can **`free` two times the same chunk** (free other chunks in between potentially) and make it be **2 times in the same bin**, it would be possible for the user to **allocate the chunk later**, **write the needed pointers** and then **allocate it again** triggering the actions of the chunk being allocated (e.g. fast bin attack, tcache attack...)
+
+### Heap Overflow
+
+It might be possible to **overflow an allocated chunk having next a freed chunk** and modify some headers/pointers of it.
+
+### Off by 1 Overflow
+
+In this case it would be possible to **modify the size** of the following chunk in memory. An attacker could abuse this to **make an allocated chunk have a bigger size**, then **`free`** it, making the chunk been **added to a bin of a different** size (bigger), then allocate the **fake size**, and the attack will have access to a **chunk with a size which is bigger** than it really is, **granting therefore a heap overflow** (check previous section).
+
+<details>
+
+<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
+
+Other ways to support HackTricks:
+
+* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
+* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
+* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
+* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
+* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
+
+</details>

binary-exploitation/heap/tcache-bin-attack.md

@@ -28,6 +28,23 @@ The **Tcache** attack proposed in the [**guyinatuxido page**](https://guyinatuxe
 
 However, nowadays, if you run the mentioned code you will get the error: **`malloc(): unaligned tcache chunk detected`**. So, it's needed to write as address in the new pointer an aligned address (or execute enough times the binary so the written address is actually aligned).
 
+### Tcache indexes attack
+
+Usually it's possible to find at the beginning of the heap a chunk containing the **amount of chunks per index** inside the tcache and the address to the **head chunk of each tcache index**. If for some reason it's possible to modify this information, it would be possible to **make the head chunk of some index point to a desired address** (like malloc hook) to then allocated a chunk of the size of the index and overwrite the contents of malloc hook in this case.
+
+## Examples
+
+* CTF [https://guyinatuxedo.github.io/29-tcache/dcquals19\_babyheap/index.html](https://guyinatuxedo.github.io/29-tcache/dcquals19\_babyheap/index.html)
+  * **Libc info leak**: It's possible to fill the tcaches, add a chunk into the unsorted list, empty the tcache and **re-allocate the chunk from the unsorted bin** only overwriting the first 8B, leaving the **second address to libc from the chunk intact so we can read it**.
+  * **Tcache attack**: The binary is vulnerable a 1B heap overflow. This will be abuse to change the **size header** of an allocated chunk making it bigger. Then, this chunk will be **freed**, adding it to the tcache of chunks of the fake size. Then, we will allocate a chunk with the faked size, and the previous chunk will be **returned knowing that this chunk was actually smaller** and this grants up the opportunity to **overwrite the next chunk in memory**.\
+    We will abuse this to **overwrite the next chunk's FD pointer** to point to **`malloc_hook`**, so then its possible to alloc 2 pointers: first the legit pointer we just modified, and then the second allocation will return a chunk in **`malloc_hook`** that it's possible to abuse to write a **one gadget**.
+* CTF [https://guyinatuxedo.github.io/29-tcache/plaid19\_cpp/index.html](https://guyinatuxedo.github.io/29-tcache/plaid19\_cpp/index.html)
+  * **Libc info leak**: There is a use after free and a double free. In this writeup the author leaked an address of libc by readnig the address of a chunk placed in a small bin (like leaking it from the unsorted bin but from the small one)
+  * **Tcache attack**: A Tcache is performed via a **double free**. The same chunk is freed twice, so inside the Tcache the chunk will point to itself. Then, it's allocated, its FD pointer is modified to point to the **free hook** and then it's allocated again so the next chunk in the list is going to be in the free hook. Then, this is also allocated and it's possible to write a the address of `system` here so when a malloc containing `"/bin/sh"` is freed we get a shell.
+* CTF [https://guyinatuxedo.github.io/44-more\_tcache/csaw19\_popping\_caps0/index.html](https://guyinatuxedo.github.io/44-more\_tcache/csaw19\_popping\_caps0/index.html)
+  * **Tcache indexes attack**: It's possible to allocate and free a chunk of a size that when stored inside the tcache info will generate a **position having the value 0x100** (because that the byte indicating how many chunks in that index are stored). Then, abusing this value it's possible to `free` this address as it looks like its a chunk of size 0x100. This will add taht address to the index of chunks of size 0x100 in the tcache.\
+    Then, allocating a chunk of size 0x100, it's possible to overwrite the initial chunk address of other tcache indexes. For example putting the address of malloc hook in one of them and allocating a chunk of the size of that index will grant a chunk in calloc hook, which allows for writting a one gadget to get a s shell.
+
 <details>
 
 <summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

binary-exploitation/heap/unsorted-bin-attack.md

@@ -40,6 +40,11 @@ Note that making **`global_max_fast`** might help in this case trusting that the
 
 The code from [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin\_attack/unsorted\_explanation/index.html) explains it very well, although if you modify the mallocs to allocate memory big enough so don't end in a tcache you can see that the previously mentioned error appears preventing this technique: **`malloc(): unsorted double linked list corrupted`**
 
+## Unsorted Bin Infoleak Attack
+
+This is actually a very basic concept. The chunks in the unsorted bin are going to be having pointers double pointers to create the bin. The first chunk in the unsorted bin will actually have the **FD** and the **BK** links **pointing to a part of the main arena (libc)**.\
+Therefore, if you can **put a chunk inside a unsorted bin and read it** (use after free) or **allocate it again without overwriting at least 1 of the pointers** to then **read** it, you can have a **libc info leak**.
+
 ## References & Other examples
 
 * [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted\_bin\_attack/#hitcon-training-lab14-magic-heap)