WWW2Exec - .dtors & .fini_array

AWSハッキングをゼロからヒーローまで学ぶ htARTE(HackTricks AWS Red Team Expert)

HackTricksをサポートする他の方法:

.dtors

現在、.dtorsセクションを持つバイナリを見つけるのは非常に珍しいです!

デストラクタは、プログラムが終了する前に実行される関数です(main関数が返された後)。 これらの関数のアドレスは、バイナリの**.dtorsセクションに格納されており、したがって、__DTOR_END__シェルコードアドレス書き込むことができれば、それはプログラムが終了する前に実行**されます。

このセクションのアドレスを取得するには、次のコマンドを使用します:

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

通常、DTOR マーカーは値 ffffffff00000000 の間にあります。したがって、これらの値だけを見ると、登録された関数がないことを意味します。したがって、00000000シェルコードのアドレス で上書きして、それを実行します。

もちろん、後でそれを呼び出すために シェルコードを保存する場所を見つける 必要があります。

.fini_array

基本的に、これはプログラムが終了する前に呼び出される関数の集まりです。これは .dtors のようなものです。これは、アドレスにジャンプしてシェルコードを呼び出すことができる場合や、脆弱性を2回目に悪用するために再び main に戻る必要がある場合に興味深いです。

objdump -s -j .fini_array ./greeting

./greeting:     file format elf32-i386

Contents of section .fini_array:
8049934 a0850408

#Put your address in 0x8049934

注意:.fini_array からの関数の実行時、次の関数に移動するため、複数回実行されることはありません(無限ループを防ぎます)、ただし、ここに配置された関数の実行は1回のみ行われます。

.fini_array のエントリは逆順で呼び出されるため、おそらく最後のエントリから書き始めたいと思うでしょう。

無限ループ

.fini_array を悪用して無限ループを作成するには、ここで行われた内容を確認してください: .fini_array に少なくとも2つのエントリがある場合、次の手順を実行できます:

  • 最初の書き込みを使用して、再び脆弱な任意の書き込み関数を呼び出す

  • 次に、__libc_csu_fini によって保存されたスタック内のリターンアドレスを計算し、__libc_csu_fini のアドレスをそこに配置する

  • これにより、__libc_csu_fini が自身を再度呼び出し、.fini_array 関数が再度実行され、脆弱なWWW関数が2回呼び出されます:任意の書き込み用に1回、そして再度**__libc_csu_fini** のリターンアドレスを上書きして自身を再度呼び出すためのもう1回。

Full RELRO****を使用すると、.fini_array セクションは読み取り専用になります。

この投稿で説明されているように、プログラムがreturnまたはexit()を使用して終了すると、__run_exit_handlers() が実行され、登録されたデストラクタが呼び出されます。

プログラムが**_exit()関数を介して終了する場合、exit システムコール**が呼び出され、終了ハンドラは実行されません。したがって、__run_exit_handlers() が実行されることを確認するには、それにブレークポイントを設定できます。

重要なコードは(ソース):

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**構造体を指すようにします。

  • この解説では、.bssにある制御されたメモリのアドレスを含むl_info[DT_FINI_ARRAY]を上書きして、偽のfini_arrayを含む最初にone gadget アドレスが実行され、その後、この偽の配列のアドレスとmap->l_addrの値の*arrayが偽の配列を指すようにします。

  • この技術のメインポストとこの解説によると、ld.soはスタックにバイナリlink_mapを指すポインタを残します。任意の書き込みで上書きし、攻撃者が制御する偽のfini_arrayを指すようにし、例えばone gadgetのアドレスを指定します。

前のコードに続いて、別の興味深いセクションが見つかります。

/* 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) 構造体を指すことが可能になります。こちらで詳細情報を見る

__run_exit_handlers における TLS-Storage dtor_list 上書き

こちらで説明されているように、プログラムが return または exit() を介して終了すると、登録されたデストラクタ関数が呼び出される __run_exit_handlers() が実行されます。

_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 ();

**__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);
[...]
}
}

**tls_dtor_listに登録された各関数について、cur->funcからポインタをデマングルし、引数cur->obj**を使用して呼び出します。

このGEFのフォークから**tls関数を使用すると、実際にdtor_listスタックキャナリPTR_MANGLEクッキーに非常に近いことがわかります。したがって、それにオーバーフローが発生すると、クッキーとスタックキャナリ上書きすることが可能になります。 PTR_MANGLEクッキーを上書きすると、それを0x00に設定してPTR_DEMANLE関数をバイパスすることが可能になります。これにより、実際のアドレスを取得するために使用されるxorが構成されたアドレスだけになります。その後、dtor_listに書き込むことで、関数アドレスとその引数を使用して複数の関数を連鎖**することが可能です。

最後に、格納されたポインタがクッキーと17ビット回転されることに注意してください。

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

新しいアドレスを追加する前に、これを考慮する必要があります。

元の投稿 で例を見つけてください。

__run_exit_handlers での他の書き換えられたポインタ

このテクニックはこちらで説明されています 、プログラムがreturnまたはexit()を呼び出して終了するために再び依存するので、__run_exit_handlers() が呼び出されます。

この関数のさらなるコードをチェックしましょう:

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_onef_cxaのオプションでは引数を制御することも可能です。

デバッグセッション中に**gef> p initialを実行してinitial構造体**を確認することができます。

これを悪用するには、PTR_MANGLEクッキーを漏洩または消去し、その後にinitial内のcxaエントリをsystem('/bin/sh')で上書きする必要があります。 このテクニックに関する元のブログ投稿には、この例があります。

Last updated