Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**Treinamento HackTricks AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**Treinamento HackTricks GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
* Esta técnica foi corrigida ([**aqui**](https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=30a17d8c95fbfb15c52d1115803b63aaa73a285c)) e produz este erro: `malloc(): corrupted top size`
Se um atacante deseja alocar um chunk no endereço P para sobrescrever um valor aqui. Ele começa sobrescrevendo o tamanho do chunk superior com `-1` (talvez com um estouro). Isso garante que o malloc não usará mmap para nenhuma alocação, pois o Top chunk sempre terá espaço suficiente.
Em seguida, calcule a distância entre o endereço do chunk superior e o espaço-alvo para alocar. Isso ocorre porque um malloc com esse tamanho será realizado para mover o chunk superior para essa posição. É assim que a diferença/tamanho pode ser facilmente calculada:
Portanto, alocar um tamanho de `target - old_top - 4*sizeof(long)` (os 4 longs são devido aos metadados do chunk superior e do novo chunk quando alocado) moverá o chunk superior para o endereço que queremos sobrescrever.\
* O binário tem um overflow que pode ser explorado para modificar o tamanho do top chunk, que é modificado para -1 ou p64(0xffffffffffffffff)
* Em seguida, é calculado o endereço do local onde o ponteiro a ser sobrescrito existe, e a diferença da posição atual do top chunk até lá é alocada com `malloc`
* Em seguida, nas funcionalidades `Org:` e `Host:`, é possível preencher os 64B do ponteiro `s` quando solicitado pelo **nome da organização**, que na pilha é seguido pelo endereço de v2, que é então seguido pelo **nome do host** indicado. Como então, strcpy vai copiar o conteúdo de s para um chunk de tamanho 64B, é possível **sobrescrever o tamanho do top chunk** com os dados inseridos no **nome do host**.
* Agora que a escrita arbitrária é possível, o GOT do `atoi` foi sobrescrito para o endereço do printf. Então foi possível vazar o endereço de `IO_2_1_stderr`_com_`%24$p`. E com esse vazamento do libc foi possível sobrescrever novamente o GOT do `atoi` com o endereço do `system` e chamá-lo passando como parâmetro `/bin/sh`
* Um método alternativo [proposto neste outro writeup](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/house\_of\_force/#2016-bctf-bcloud), é sobrescrever `free` com `puts`, e então adicionar o endereço de `atoi@got`, no ponteiro que será posteriormente liberado para que seja vazado e com esse vazamento sobrescrever novamente `atoi@got` com `system` e chamá-lo com `/bin/sh`.
* Existe um UAF que permite reutilizar um chunk que foi liberado sem limpar o ponteiro. Como existem alguns métodos de leitura, é possível vazar um endereço do libc escrevendo um ponteiro para a função free no GOT aqui e então chamando a função de leitura.
* Em seguida, House of force foi usado (abusando do UAF) para sobrescrever o tamanho do espaço à esquerda com um -1, alocar um chunk grande o suficiente para chegar ao hook de free e, em seguida, alocar outro chunk que conterá o hook de free. Em seguida, escreva no hook o endereço do `system`, escreva em um chunk `"/bin/sh"` e finalmente libere o chunk com esse conteúdo de string.
