GITBOOK-4357: No subject

SUMMARY.md

@@ -740,7 +740,7 @@
   * [Tcache Bin Attack](binary-exploitation/heap/tcache-bin-attack.md)
   * [Off by one overflow](binary-exploitation/heap/off-by-one-overflow.md)
   * [House of Spirit](binary-exploitation/heap/house-of-spirit.md)
-  * [House of Lore](binary-exploitation/heap/house-of-lore.md)
+  * [House of Lore | Small bin Attack](binary-exploitation/heap/house-of-lore.md)
   * [House of Einherjar](binary-exploitation/heap/house-of-einherjar.md)
   * [House of Force](binary-exploitation/heap/house-of-force.md)
   * [House of Orange](binary-exploitation/heap/house-of-orange.md)

binary-exploitation/heap/house-of-einherjar.md

@@ -19,29 +19,35 @@ Other ways to support HackTricks:
 ### Code
 
 * Check the example from [https://github.com/shellphish/how2heap/blob/master/glibc\_2.35/house\_of\_einherjar.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.35/house\_of\_einherjar.c)
+* Or the one from [https://guyinatuxedo.github.io/42-house\_of\_einherjar/house\_einherjar\_exp/index.html#house-of-einherjar-explanation](https://guyinatuxedo.github.io/42-house\_of\_einherjar/house\_einherjar\_exp/index.html#house-of-einherjar-explanation) (you might need to fill the tcache)
 
 ### Goal
 
 * The goal is to allocate memory in almost any specific address.
 
 ### Requirements
 
-* Off by one over the header of the next chunk to modify the prev in use
-* Be able to modify the `prev_size` data, which is part of the current chunk (at the end)
-* Heap leak
+* Create a fake chunk when we want to allocate a chunk:
+  * Set pointers to point to itself to bypass sanity checks
+* Off by one over from one chunk to another to modify the prev in use
+* Indicate in the `prev_size` of the off-by-one abused chunk the difference between itself and the fake chunk
+  * The fake chunk size must also have been set the same size to bypass sanity checks
+* For constructing these chunks, you will need a heap leak.
 
 ### Attack
 
 * `A` fake chunk is created inside a chunk controlled by the attacker pointing with `fd` and `bk` to the original chunk to bypass protections
-* 2 other chunks (`B` and `C`) are created
+* 2 other chunks (`B` and `C`) are allocated
 * Abusing the off by one in the `B` one the `prev in use` bit is cleaned and the `prev_size` data is overwritten with the difference between the place where the `C` chunk is allocated, to the fake `A` chunk generated before
-  * This `prev_size` and the size of the fake chunk `A` must be the same to bypass checks.
+  * This `prev_size` and the size in the fake chunk `A` must be the same to bypass checks.
 * Then, the tcache is filled
 * Then, `C` is freed so it consolidates with the fake chunk `A`
 * Then, a new chunk `D` is created which will be starting in the fake `A` chunk and covering `B` chunk
-* Then, `B`'s `fd` is overwritten making it point to the target address abusing the `D` chunk (as it contains `B` inside) and `B` is freed to add the target to the fast bin
-  * This is the common fast bin attack
-* Then, 2 mallocs are done and the second one id going to be allocating the target address
+  * The house of Einherjar finishes here
+* This can be continued with a fast bin attack:
+  * Free `B` to add it to the fast bin
+  * `B`'s `fd` is overwritten making it point to the target address abusing the `D` chunk (as it contains `B` inside) 
+  * Then, 2 mallocs are done and the second one is going to be **allocating the target address**
 
 ## References and other examples
 

binary-exploitation/heap/house-of-lore.md

@@ -1,4 +1,4 @@
-# House of Lore
+# House of Lore | Small bin Attack
 
 <details>
 
@@ -21,34 +21,40 @@ Other ways to support HackTricks:
 * Check the one from [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_lore/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_lore/)
   * This isn't working
 * Or: [https://github.com/shellphish/how2heap/blob/master/glibc\_2.39/house\_of\_lore.c](https://github.com/shellphish/how2heap/blob/master/glibc\_2.39/house\_of\_lore.c)
-  * This isn't working even if tries to bypass the checks getting the error: `malloc(): unaligned tcache chunk detected` which might mean that the fake free list should be aligned
-  * This could be bypassed aligning properly that list of fixing the second fake chunk to point to the arena (need a leak). However, it looks like this attack have too many requisites and few benefits.
+  * This isn't working even if it tries to bypass some checks getting the error: `malloc(): unaligned tcache chunk detected`
+* This example is still working**:** [**https://guyinatuxedo.github.io/40-house\_of\_lore/house\_lore\_exp/index.html**](https://guyinatuxedo.github.io/40-house\_of\_lore/house\_lore\_exp/index.html)&#x20;
 
 ### Goal
 
-* Insert a fake small chunks in the small bin so then it's possible to allocate it.
+* Insert a **fake small chunk in the small bin so then it's possible to allocate it**.\
+  Note that the small chunk added is the fake one the attacker creates a not a fake one in a arbitrary position.
 
 ### Requirements
 
-* Create fake chunks
-* Know the address of the victim chunk and the fake chunks
-* Be able to modify the `bk` and `fd` pointers
+* Create 2 fake chunks and link them with them and with the legit chunk in the small bin:
+  * `fake0.bk` -> `fake1`
+  * `fake1.fd` -> `fake0`
+  * `fake0.fd` -> `legit` (you need to modify a pointer in the freed small bin chunk via some other vuln)
+  * `legit.bk` -> `fake0`
+
+The you will be able to allocate `fake0`.
 
 ### Attack
 
-* A victim small chunk is allocated
-* An attacker generates a couple of fake small chunks, and makes the first fake chunk `fd` point to a real chunk and the `bk` point to the second fake chunk. Also make the second fake chunk `bk` point the first one.
-  * The `bk` of the second should also point to the fake freelist to prevent a crash when small bin chunks are tried to be allocated in the tcache.
-* Then, a new large chunk is allocated to prevent the first one to being consolidate in the top chunk when freed
-* Then, the initial pointer is freed and a second pointer of a bigger size is allocated so the freed initial small chunk is placed in the small bin.
-* Vulnerability: The real small chunk freed is modified so it’s `bk` pointer points to the first fake chunk.
-* Then, when 2 chunks of this size are allocated they get the valid chunk first and then the invalid chunk somehow controlled by the attacker.
-  * In the how2heap example the fake chunks are inside the stack so we would be getting a chunk from the stack, where it might be possible to write a ROP or something.
+* A small chunk (`legit`) is allocated, then another one is allocated to prevent consolidating with top chunk. Then, legit is freed (moving it to the unsorted list) and the a larger chunk is allocated, **moving `legit` it to the small bin.**
+* An attacker generates a couple of fake small chunks, and makes the need linking to bypass sanity checks:
+  * `fake0.bk` -> `fake1`
+  * `fake1.fd` -> `fake0`
+  * `fake0.fd` -> `legit` (you need to modify a pointer in the freed small bin chunk via some other vuln)
+  * `legit.bk` -> `fake0`
+* A small chunk is allocated to get legit, making **`fake0`** into the top list of small bins
+* Another small chunk is allocated, getting fake0 as a chunk, allowing potentially to read/write pointers inside of it.
 
 ## References
 
 * [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_lore/](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_lore/)
 * [https://heap-exploitation.dhavalkapil.com/attacks/house\_of\_lore](https://heap-exploitation.dhavalkapil.com/attacks/house\_of\_lore)
+* [https://guyinatuxedo.github.io/40-house\_of\_lore/house\_lore\_exp/index.html](https://guyinatuxedo.github.io/40-house\_of\_lore/house\_lore\_exp/index.html)
 
 <details>
 

binary-exploitation/heap/house-of-spirit.md

@@ -71,16 +71,53 @@ int main() {
 
 ### Goal
 
-* Be able to add into the tcache / fast bin an arbitrary address so when calling malloc it gets used in a chunk
+* Be able to add into the tcache / fast bin an address so later it's possible to alloc it
 
 ### Requirements
 
-* This attack requires an attacker to be able to create a couple of fake fast chunks indicating correctly the size value of it and to overwrite a fast chunks of that size that it’s going to be freed, so the attackers chunk is actually the one that gets into the fast bin.
+* This attack requires an attacker to be able to create a couple of fake fast chunks indicating correctly the size value of it and then to be able to free the first fake chunk so it gets into the bin.
 
 ### Attack
 
-* Create a fake chunk that bypasses security checks (you will need 2 fake chunks)
-* Before a pointer is freed, overwrite it with the fake chunk so thats the one taht gets into the bin
+* Create fake chunks that bypasses security checks: you will need 2 fake chunks basically indicating in the correct positions the correct sizes
+* Somehow manage to free the first fake chunk so it gets into the fast or tcache bin and then it's allocate it to overwrite that address
+
+**The code from** [**guyinatuxedo**](https://guyinatuxedo.github.io/39-house\_of\_spirit/house\_spirit\_exp/index.html) **is great to understand the attack.** Although this schema from the code summarises it pretty good:
+
+```c
+/*
+    this will be the structure of our two fake chunks:
+    assuming that you compiled it for x64
+
+    +-------+---------------------+------+
+    | 0x00: | Chunk # 0 prev size | 0x00 |
+    +-------+---------------------+------+
+    | 0x08: | Chunk # 0 size      | 0x60 |
+    +-------+---------------------+------+
+    | 0x10: | Chunk # 0 content   | 0x00 |
+    +-------+---------------------+------+
+    | 0x60: | Chunk # 1 prev size | 0x00 |
+    +-------+---------------------+------+
+    | 0x68: | Chunk # 1 size      | 0x40 |
+    +-------+---------------------+------+
+    | 0x70: | Chunk # 1 content   | 0x00 |
+    +-------+---------------------+------+
+
+    for what we are doing the prev size values don't matter too much
+    the important thing is the size values of the heap headers for our fake chunks
+*/
+```
+
+{% hint style="info" %}
+Note that it's necessary to create the second chunk in order to bypass some sanity checks.
+{% endhint %}
+
+## Examples
+
+* CTF [https://guyinatuxedo.github.io/39-house\_of\_spirit/hacklu14\_oreo/index.html](https://guyinatuxedo.github.io/39-house\_of\_spirit/hacklu14\_oreo/index.html)
+  * **Libc infoleak**: Via an overflow it's possible to change a pointer to point to a GOT address in order to leak a libc address via the read action of the CTF
+  * **House of Spirit**: Abusing a counter that counts the number of "rifles" it's possible to generate a fake size of the first fake chunk, then abusing a "message" it's possible to fake the second size of a chunk and finally abusing an overflow it's possible to change a pointer that is going to be freed so our first fake chunk is freed. Then, we can allocate it and inside of it there is going to be the address to where "message" is stored. Then, it's possible to make this point to the `scanf` entry inside the GOT table, so we can overwrite it with the address to system.\
+    Next time `scanf` is called, we can send the input `"/bin/sh"` and get a shell.
 
 ## References
 

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

@@ -42,8 +42,14 @@ Usually it's possible to find at the beginning of the heap a chunk containing th
   * **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.
+  * The main vuln here is the capacity to `free` any address in the heap by indicating its offset
+  * **Tcache indexes attack**: It's possible to allocate and free a chunk of a size that when stored inside the tcache chunk (the chunk with the info of the tcache bins) will generate an **address with the value 0x100**. This is because the tcache stores the amount of chunks on each bin in different bytes, therefore one chunk in one specific index generates the value 0x100.
+  * Then, this value looks like there is a chunk of size 0x100. Allowing to abuse it by `free` this address. This will **add that address to the index of chunks of size 0x100 in the tcache**.
+  * Then, **allocating** a chunk of size **0x100**, the previous address will be returned as a chunk, allowing to overwrite 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 writing a one gadget to get a s shell.
+* CTF [https://guyinatuxedo.github.io/44-more\_tcache/csaw19\_popping\_caps1/index.html](https://guyinatuxedo.github.io/44-more\_tcache/csaw19\_popping\_caps1/index.html)
+  * Same vulnerability as before with one extra restriction
+  * **Tcache indexes attack**: Similar attack to the previous one but using less steps by **freeing the chunk that contains the tcache info** so it's address is added to the tcache index of its size so it's possible to allocate that size and get the tcache chunk info as a chunk, which allows to add free hook as the address of one index, alloc it, and write a one gadget on it.
 
 <details>