hacktricks/binary-exploitation/arbitrary-write-2-exec/www2exec-atexit.md

241 lines
13 KiB
Markdown
Raw Permalink Normal View History

# WWW2Exec - atexit(), TLS Storage & その他の乱れたポインタ
{% hint style="success" %}
AWSハッキングの学習と実践:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
GCPハッキングの学習と実践: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
<details>
<summary>HackTricksのサポート</summary>
* [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)をチェック!
* 💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または [**telegramグループ**](https://t.me/peass)に**参加**するか、**Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**をフォロー**してください。
* **HackTricks**と**HackTricks Cloud**のgithubリポジトリにPRを提出して**ハッキングテクニックを共有**してください。
</details>
{% endhint %}
## **\_\_atexit構造体**
{% hint style="danger" %}
現在はこれを悪用するのは**非常に珍しいです!**
{% endhint %}
**`atexit()`**は、**他の関数がパラメータとして渡される関数**であり、これらの**関数**は**`exit()`の実行**または**mainの戻り**時に**実行**されます。\
これらの**関数**の**アドレス**を任意に**変更**して、例えばシェルコードを指すようにすることができれば、**プロセスを制御**することができますが、現在はこれがより複雑になっています。\
現在、**実行される関数へのアドレス**はいくつかの構造体の背後に隠されており、最終的にそれが指すアドレスは関数のアドレスではなく、**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()`**が実行されます。
{% hint style="danger" %}
プログラムが**`_exit()`**関数を使用して終了する場合、**`exit`シスコール**が呼び出され、終了ハンドラは実行されません。したがって、`__run_exit_handlers()`が実行されることを確認するには、その上にブレークポイントを設定できます。
{% endhint %}
重要なコードは([ソース](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]` のエントリを上書きして、再び **`array` が攻撃者が制御するメモリ領域を指す** ようにするために、**偽の `Elf64_Dyn`** 構造体を指すようにします。
* [**この解説**](https://github.com/nobodyisnobody/write-ups/tree/main/DanteCTF.2023/pwn/Sentence.To.Hell) では、`.bss` にある制御されたメモリのアドレスを持つ `l_info[DT_FINI_ARRAY]` を上書きして、偽の `fini_array` を含むものを指します。この偽の配列には、最初に実行される [**one gadget**](../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` を指すポインタを残します。任意の書き込みでこれを上書きし、攻撃者が制御する偽の `fini_array` を指すようにし、例えば [**one gadget**](../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)。
## **`__run_exit_handlers`** における TLS-Storage dtor\_list 上書き
[**こちらで説明されている通り**](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`**を使用して呼び出します。
この[**GEFのフォーク**](https://github.com/bata24/gef)から**`tls`**関数を使用すると、実際に**`dtor_list`**が**スタックキャナリ**と**PTR\_MANGLEクッキー**に非常に**近い**ことがわかります。したがって、それにオーバーフローが発生すると、**クッキー**と**スタックキャナリ**を**上書き**することが可能になります。\
PTR\_MANGLEクッキーを上書きすると、それを0x00に設定して**`PTR_DEMANLE`関数をバイパス**することが可能になります。これは、実際のアドレスを取得するために使用される**`xor`**が構成されたアドレスだけであることを意味します。その後、**`dtor_list`**に書き込むことで、関数**アドレス**とその**引数**を持つ**複数の関数を連鎖**することが可能です。
最後に、格納されたポインタがクッキーと**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`の値に応じて異なる関数が呼び出されます。
値に応じて、呼び出す関数のアドレスは異なる場所にありますが、常に**デマングル**されます。
さらに、**`ef_on`**と**`ef_cxa`**のオプションでは、**引数**を制御することも可能です。
デバッグセッション中に**`gef> p initial`**を実行して、**`initial`構造体**を確認することができます。
これを悪用するには、**`PTR_MANGLE`クッキーを漏洩または消去**し、その後に`initial`内の`cxa`エントリを`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)には、この例があります。