mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
227 lines
13 KiB
Markdown
227 lines
13 KiB
Markdown
# WWW2Exec - atexit(), TLS Storage & Інші спотворені вказівники
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|
||
|
||
## **\_\_atexit Structures**
|
||
|
||
> [!CAUTION]
|
||
> Сьогодні дуже **незвично експлуатувати це!**
|
||
|
||
**`atexit()`** - це функція, до якої **передаються інші функції як параметри.** Ці **функції** будуть **виконані** під час виконання **`exit()`** або **повернення** з **main**.\
|
||
Якщо ви можете **модифікувати** **адресу** будь-якої з цих **функцій**, щоб вказувати на shellcode, наприклад, ви **отримаєте контроль** над **процесом**, але це наразі складніше.\
|
||
В даний час **адреси функцій**, які потрібно виконати, **сховані** за кількома структурами, і врешті-решт адреса, на яку вони вказують, не є адресами функцій, а **зашифрована за допомогою XOR** та зміщень з **випадковим ключем**. Тому наразі цей вектор атаки **не дуже корисний, принаймні на x86** та **x64_86**.\
|
||
**Функція шифрування** - це **`PTR_MANGLE`**. **Інші архітектури**, такі як m68k, mips32, mips64, aarch64, arm, hppa... **не реалізують функцію шифрування**, оскільки вона **повертає те ж саме**, що отримала на вхід. Тому ці архітектури можуть бути атаковані за цим вектором.
|
||
|
||
Ви можете знайти детальне пояснення того, як це працює, на [https://m101.github.io/binholic/2017/05/20/notes-on-abusing-exit-handlers.html](https://m101.github.io/binholic/2017/05/20/notes-on-abusing-exit-handlers.html)
|
||
|
||
## link_map
|
||
|
||
Як пояснено [**в цьому пості**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#2---targetting-ldso-link_map-structure), якщо програма завершується за допомогою `return` або `exit()`, вона виконає `__run_exit_handlers()`, яка викличе зареєстровані деструктори.
|
||
|
||
> [!CAUTION]
|
||
> Якщо програма завершується через **`_exit()`**, вона викличе **`exit` syscall** і обробники виходу не будуть виконані. Тому, щоб підтвердити, що `__run_exit_handlers()` виконується, ви можете встановити точку зупинки на ньому.
|
||
|
||
Важливий код - ([source](https://elixir.bootlin.com/glibc/glibc-2.32/source/elf/dl-fini.c#L131)):
|
||
```c
|
||
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
|
||
}
|
||
```
|
||
Зверніть увагу, як `map -> l_addr + fini_array -> d_un.d_ptr` використовується для **обчислення** позиції **масиву функцій для виклику**.
|
||
|
||
Є **кілька варіантів**:
|
||
|
||
- Перезаписати значення `map->l_addr`, щоб воно вказувало на **підроблений `fini_array`** з інструкціями для виконання довільного коду.
|
||
- Перезаписати записи `l_info[DT_FINI_ARRAY]` та `l_info[DT_FINI_ARRAYSZ]` (які більш-менш послідовні в пам'яті), щоб вони **вказували на підроблену структуру `Elf64_Dyn`**, яка знову зробить так, що **`array` вказуватиме на зону пам'яті**, контрольовану атакуючим.
|
||
- [**Цей звіт**](https://github.com/nobodyisnobody/write-ups/tree/main/DanteCTF.2023/pwn/Sentence.To.Hell) перезаписує `l_info[DT_FINI_ARRAY]` з адресою контрольованої пам'яті в `.bss`, що містить підроблений `fini_array`. Цей підроблений масив містить **спочатку** [**адресу одного гаджета**](../rop-return-oriented-programing/ret2lib/one-gadget.md), яка буде виконана, а потім **різницю** між адресою цього **підробленого масиву** та **значенням `map->l_addr`**, щоб `*array` вказував на підроблений масив.
|
||
- Згідно з основним постом цієї техніки та [**цим звітом**](https://activities.tjhsst.edu/csc/writeups/angstromctf-2021-wallstreet), ld.so залишає вказівник на стеку, який вказує на бінарний `link_map` в ld.so. З допомогою довільного запису можливо перезаписати його і зробити так, щоб він вказував на підроблений `fini_array`, контрольований атакуючим, з адресою до [**одного гаджета**](../rop-return-oriented-programing/ret2lib/one-gadget.md), наприклад.
|
||
|
||
Наступний код містить ще один цікавий розділ з кодом:
|
||
```c
|
||
/* 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));
|
||
}
|
||
```
|
||
У цьому випадку буде можливим перезаписати значення `map->l_info[DT_FINI]`, вказуючи на підроблену структуру `ElfW(Dyn)`. Знайдіть [**більше інформації тут**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#2---targetting-ldso-link_map-structure).
|
||
|
||
## Перезапис dtor_list TLS-Storage у **`__run_exit_handlers`**
|
||
|
||
Як [**пояснено тут**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite), якщо програма завершується через `return` або `exit()`, вона виконає **`__run_exit_handlers()`**, яка викличе будь-які функції деструкторів, що зареєстровані.
|
||
|
||
Код з `_run_exit_handlers()`:
|
||
```c
|
||
/* 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 ();
|
||
```
|
||
Код з **`__call_tls_dtors()`**:
|
||
```c
|
||
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);
|
||
[...]
|
||
}
|
||
}
|
||
```
|
||
Для кожної зареєстрованої функції в **`tls_dtor_list`** буде деманглити вказівник з **`cur->func`** і викликати його з аргументом **`cur->obj`**.
|
||
|
||
Використовуючи функцію **`tls`** з цього [**форку GEF**](https://github.com/bata24/gef), можна побачити, що насправді **`dtor_list`** дуже **близький** до **stack canary** і **PTR_MANGLE cookie**. Отже, з переповненням на ньому буде можливим **перезаписати** **cookie** і **stack canary**.\
|
||
Перезаписуючи PTR_MANGLE cookie, буде можливим **обійти функцію `PTR_DEMANLE`**, встановивши її в 0x00, що означатиме, що **`xor`**, використаний для отримання реальної адреси, є просто адресою, що налаштована. Потім, записуючи в **`dtor_list`**, можна **з'єднати кілька функцій** з адресою функції та її **аргументом.**
|
||
|
||
Нарешті, зверніть увагу, що збережений вказівник не тільки буде xored з cookie, але також буде обернений на 17 біт:
|
||
```armasm
|
||
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
|
||
```
|
||
Отже, вам потрібно врахувати це перед додаванням нової адреси.
|
||
|
||
Знайдіть приклад у [**оригінальному пості**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite).
|
||
|
||
## Інші спотворені вказівники в **`__run_exit_handlers`**
|
||
|
||
Цю техніку [**пояснено тут**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#5---code-execution-via-tls-storage-dtor_list-overwrite) і вона знову залежить від того, що програма **виходить, викликаючи `return` або `exit()`**, тому **`__run_exit_handlers()`** викликається.
|
||
|
||
Давайте перевіримо більше коду цієї функції:
|
||
```c
|
||
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);
|
||
```
|
||
Змінна `f` вказує на **`initial`** структуру, і в залежності від значення `f->flavor` будуть викликані різні функції.\
|
||
В залежності від значення, адреса функції, яку потрібно викликати, буде в іншому місці, але вона завжди буде **demangled**.
|
||
|
||
Більше того, в опціях **`ef_on`** та **`ef_cxa`** також можливо контролювати **аргумент**.
|
||
|
||
Можна перевірити **`initial` структуру** в сеансі налагодження з GEF, запустивши **`gef> p initial`**.
|
||
|
||
Щоб зловживати цим, вам потрібно або **leak або стерти `PTR_MANGLE`cookie**, а потім перезаписати запис `cxa` в initial з `system('/bin/sh')`.\
|
||
Ви можете знайти приклад цього в [**оригінальному блозі про техніку**](https://github.com/nobodyisnobody/docs/blob/main/code.execution.on.last.libc/README.md#6---code-execution-via-other-mangled-pointers-in-initial-structure).
|
||
|
||
{{#include ../../banners/hacktricks-training.md}}
|