Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-18 17:16:10 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/binary-exploitation/arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md

15 KiB
Raw Blame History

WWW2Exec - .dtors & .fini_array

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

.dtors

{% hint style="danger" %} Atualmente é muito estranho encontrar um binário com uma seção .dtors! {% endhint %}

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:

objdump -s -j .dtors /exec
rabin -s /exec | grep “__DTOR”

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.

{% hint style="warning" %} Claro, primeiro você precisa encontrar um local para armazenar o shellcode para depois chamá-lo. {% endhint %}

.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.

objdump -s -j .fini_array ./greeting

./greeting:     file format elf32-i386

Contents of section .fini_array:
8049934 a0850408

#Put your address in 0x8049934

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.

{% hint style="danger" %} Note que com Full RELRO, a seção .fini_array é tornada somente leitura. {% endhint %}

link_map

Como explicado neste post, se o programa sair usando return ou exit(), ele executará __run_exit_handlers() que chamará os destruidores registrados.

{% hint style="danger" %} 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. {% endhint %}

O código importante é (fonte):

ElfW(Dyn) *fini_array = map->l_info[DT_FINI_ARRAY];
if (fini_array != NULL)
{
ElfW(Addr) *array = (ElfW(Addr) *) (map->l_addr + fini_array->d_un.d_ptr);
size_t sz = (map->l_info[DT_FINI_ARRAYSZ]->d_un.d_val / sizeof (ElfW(Addr)));

while (sz-- > 0)
((fini_t) array[sz]) ();
}
[...]




// This is the d_un structure
ptype l->l_info[DT_FINI_ARRAY]->d_un
type = union {
Elf64_Xword d_val;	// address of function that will be called, we put our onegadget here
Elf64_Addr d_ptr;	// offset from l->l_addr of our structure
}

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 um fini_array falso com instruções para executar código arbitrário
  • Sobrescrever as entradas l_info[DT_FINI_ARRAY] e l_info[DT_FINI_ARRAYSZ] (que são mais ou menos consecutivas na memória), para fazer com que elas apontem para uma estrutura Elf64_Dyn forjada que fará novamente array 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 um fini_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 de map->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 um fini_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:

/* Next try the old-style destructor.  */
ElfW(Dyn) *fini = map->l_info[DT_FINI];
if (fini != NULL)
DL_CALL_DT_FINI (map, ((void *) map->l_addr + fini->d_un.d_ptr));
}

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

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():

/* Call all functions registered with `atexit' and `on_exit',
in the reverse of the order in which they were registered
perform stdio cleanup, and terminate program execution with STATUS.  */
void
attribute_hidden
__run_exit_handlers (int status, struct exit_function_list **listp,
bool run_list_atexit, bool run_dtors)
{
/* First, call the TLS destructors.  */
#ifndef SHARED
if (&__call_tls_dtors != NULL)
#endif
if (run_dtors)
__call_tls_dtors ();

Código de __call_tls_dtors():

typedef void (*dtor_func) (void *);
struct dtor_list //struct added
{
dtor_func func;
void *obj;
struct link_map *map;
struct dtor_list *next;
};

[...]
/* Call the destructors.  This is called either when a thread returns from the
initial function or when the process exits via the exit function.  */
void
__call_tls_dtors (void)
{
while (tls_dtor_list)		// parse the dtor_list chained structures
{
struct dtor_list *cur = tls_dtor_list;		// cur point to tls-storage dtor_list
dtor_func func = cur->func;
PTR_DEMANGLE (func);						// demangle the function ptr

tls_dtor_list = tls_dtor_list->next;		// next dtor_list structure
func (cur->obj);
[...]
}
}

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:

0x00007fc390444dd4 <+36>:	mov    rax,QWORD PTR [rbx]      --> mangled ptr
0x00007fc390444dd7 <+39>:	ror    rax,0x11		        --> rotate of 17 bits
0x00007fc390444ddb <+43>:	xor    rax,QWORD PTR fs:0x30	--> xor with PTR_MANGLE

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

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:

while (true)
{
struct exit_function_list *cur;

restart:
cur = *listp;

if (cur == NULL)
{
/* Exit processing complete.  We will not allow any more
atexit/on_exit registrations.  */
__exit_funcs_done = true;
break;
}

while (cur->idx > 0)
{
struct exit_function *const f = &cur->fns[--cur->idx];
const uint64_t new_exitfn_called = __new_exitfn_called;

switch (f->flavor)
{
void (*atfct) (void);
void (*onfct) (int status, void *arg);
void (*cxafct) (void *arg, int status);
void *arg;

case ef_free:
case ef_us:
break;
case ef_on:
onfct = f->func.on.fn;
arg = f->func.on.arg;
PTR_DEMANGLE (onfct);

/* Unlock the list while we call a foreign function.  */
__libc_lock_unlock (__exit_funcs_lock);
onfct (status, arg);
__libc_lock_lock (__exit_funcs_lock);
break;
case ef_at:
atfct = f->func.at;
PTR_DEMANGLE (atfct);

/* Unlock the list while we call a foreign function.  */
__libc_lock_unlock (__exit_funcs_lock);
atfct ();
__libc_lock_lock (__exit_funcs_lock);
break;
case ef_cxa:
/* To avoid dlclose/exit race calling cxafct twice (BZ 22180),
we must mark this function as ef_free.  */
f->flavor = ef_free;
cxafct = f->func.cxa.fn;
arg = f->func.cxa.arg;
PTR_DEMANGLE (cxafct);

/* Unlock the list while we call a foreign function.  */
__libc_lock_unlock (__exit_funcs_lock);
cxafct (arg, status);
__libc_lock_lock (__exit_funcs_lock);
break;
}

if (__glibc_unlikely (new_exitfn_called != __new_exitfn_called))
/* The last exit function, or another thread, has registered
more exit functions.  Start the loop over.  */
goto restart;
}

*listp = cur->next;
if (*listp != NULL)
/* Don't free the last element in the chain, this is the statically
allocate element.  */
free (cur);
}

__libc_lock_unlock (__exit_funcs_lock);

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.

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks: