WWW2Exec - .dtors & .fini_array
.dtors
Atualmente é muito estranho encontrar um binário com uma seção .dtors!
Os destrutores são funções que são executadas antes do programa terminar (após o retorno da função main
).
Os endereços dessas funções são armazenados dentro da seção .dtors
do binário e, portanto, se você conseguir escrever o endereço de um shellcode em __DTOR_END__
, isso será executado antes do programa terminar.
Obtenha o endereço desta seção com:
Normalmente você encontrará os marcadores DTOR entre os valores ffffffff
e 00000000
. Portanto, se você apenas ver esses valores, significa que não há nenhuma função registrada. Portanto, sobrescreva o 00000000
com o endereço do shellcode para executá-lo.
Claro, primeiro você precisa encontrar um local para armazenar o shellcode para depois chamá-lo.
.fini_array
Essencialmente, esta é uma estrutura com funções que serão chamadas antes do programa terminar, como .dtors
. Isso é interessante se você puder chamar seu shellcode apenas pulando para um endereço, ou em casos em que você precisa voltar para o main
novamente para explorar a vulnerabilidade uma segunda vez.
Note que quando uma função do .fini_array
é executada, ela passa para a próxima, então não será executada várias vezes (evitando loops eternos), mas também só lhe dará 1 execução da função colocada aqui.
Note que as entradas em .fini_array
são chamadas em ordem inversa, então provavelmente você quer começar a escrever a partir da última.
Loop eterno
Para abusar do .fini_array
e obter um loop eterno, você pode ver o que foi feito aqui: Se você tiver pelo menos 2 entradas em .fini_array
, você pode:
Usar sua primeira escrita para chamar a função de escrita arbitrária vulnerável novamente
Em seguida, calcular o endereço de retorno na pilha armazenado por
__libc_csu_fini
(a função que está chamando todas as funções.fini_array
) e colocar lá o endereço de__libc_csu_fini
Isso fará com que
__libc_csu_fini
chame a si mesmo novamente executando as funções do.fini_array
novamente, o que chamará a função WWW vulnerável 2 vezes: uma para a escrita arbitrária e outra para sobrescrever novamente o endereço de retorno de__libc_csu_fini
na pilha para chamar a si mesmo novamente.
Note que com Full RELRO, a seção .fini_array
é tornada somente leitura.
link_map
Como explicado neste post, se o programa sair usando return
ou exit()
, ele executará __run_exit_handlers()
que chamará os destruidores registrados.
Se o programa sair via função _exit()
, ele chamará a chamada de sistema exit
e os manipuladores de saída não serão executados. Portanto, para confirmar que __run_exit_handlers()
está sendo executado, você pode definir um breakpoint nele.
O código importante é (fonte):
Observe como map -> l_addr + fini_array -> d_un.d_ptr
é usado para calcular a posição do array de funções a serem chamadas.
Existem algumas opções:
Sobrescrever o valor de
map->l_addr
para fazê-lo apontar para umfini_array
falso com instruções para executar código arbitrárioSobrescrever as entradas
l_info[DT_FINI_ARRAY]
el_info[DT_FINI_ARRAYSZ]
(que são mais ou menos consecutivas na memória), para fazer com que elas apontem para uma estruturaElf64_Dyn
forjada que fará novamentearray
apontar para uma zona de memória controlada pelo atacante.Este relatório sobrescreve
l_info[DT_FINI_ARRAY]
com o endereço de uma memória controlada em.bss
contendo umfini_array
falso. Este array falso contém primeiro um endereço de one gadget que será executado e depois a diferença entre o endereço deste array falso e o valor demap->l_addr
para que*array
aponte para o array falso.De acordo com a postagem principal desta técnica e este relatório ld.so deixa um ponteiro na pilha que aponta para o
link_map
binário em ld.so. Com uma escrita arbitrária é possível sobrescrevê-lo e fazê-lo apontar para umfini_array
falso controlado pelo atacante com o endereço de um one gadget, por exemplo.
Seguindo o código anterior, você pode encontrar outra seção interessante com o código:
Neste caso, seria possível sobrescrever o valor de map->l_info[DT_FINI]
apontando para uma estrutura ElfW(Dyn)
forjada. Encontre mais informações aqui.
Sobrescrevendo a lista de dtor_list de TLS-Storage em __run_exit_handlers
__run_exit_handlers
Conforme explicado aqui, se um programa encerra via return
ou exit()
, ele executará __run_exit_handlers()
que chamará qualquer função de destruição registrada.
Código de _run_exit_handlers()
:
Código de __call_tls_dtors()
:
Para cada função registrada em tls_dtor_list
, ele irá desembaralhar o ponteiro de cur->func
e chamá-lo com o argumento cur->obj
.
Usando a função tls
deste fork do GEF, é possível ver que na verdade a dtor_list
está muito próxima do canário de pilha e do cookie PTR_MANGLE. Portanto, com um estouro nela, seria possível sobrescrever o cookie e o canário de pilha.
Sobrescrevendo o cookie PTR_MANGLE, seria possível burlar a função PTR_DEMANLE
ao defini-lo como 0x00, o que significa que o xor
usado para obter o endereço real é apenas o endereço configurado. Em seguida, escrevendo na dtor_list
, é possível encadear várias funções com o endereço da função e seu argumento.
Por fim, observe que o ponteiro armazenado não apenas será xorado com o cookie, mas também rotacionado 17 bits:
Portanto, você precisa levar isso em consideração antes de adicionar um novo endereço.
Encontre um exemplo no post original.
Outros ponteiros corrompidos em __run_exit_handlers
__run_exit_handlers
Essa técnica é explicada aqui e depende novamente do programa sair chamando return
ou exit()
para que __run_exit_handlers()
seja chamado.
Vamos verificar mais código desta função:
A variável f
aponta para a estrutura initial
e dependendo do valor de f->flavor
, diferentes funções serão chamadas.
Dependendo do valor, o endereço da função a ser chamada estará em um local diferente, mas sempre será desembaralhado.
Além disso, nas opções ef_on
e ef_cxa
, também é possível controlar um argumento.
É possível verificar a estrutura initial
em uma sessão de depuração com o GEF executando gef> p initial
.
Para abusar disso, você precisa vazar ou apagar o cookie PTR_MANGLE
e então sobrescrever uma entrada cxa
em initial com system('/bin/sh')
.
Você pode encontrar um exemplo disso no post original do blog sobre a técnica.
Last updated