2편을 보지 않았다면 보고 오시는걸 추천합니다.
Remind
환경
일단 glibc 2.39 버전의 source code를 분석할 것이기 때문에 아래의 사이트에서 소스코드를 다운받았다.
glibc 분석을 진행하는 것이 처음이라 실수가 많을 수 있으며, 엉뚱한 이야기가 있을 수도 있습니다. 그 부분을 감안해서 너그러이 봐주시면 감사하겠습니다.
Example code
//gcc -o foepn fopen.c
#include <stdio.h>
int main(){
FILE *fp = 0;
fp = fopen("flag", "w");
fwrite("JANGJONGMIN", 1, 11, fp);
fclose(fp);
return 1;
}
C
복사
ASM
gef➤ disas main
Dump of assembler code for function main:
0x00005a2e23631189 <+0>: endbr64
0x00005a2e2363118d <+4>: push rbp
0x00005a2e2363118e <+5>: mov rbp,rsp
0x00005a2e23631191 <+8>: sub rsp,0x10
0x00005a2e23631195 <+12>: mov QWORD PTR [rbp-0x8],0x0
0x00005a2e2363119d <+20>: lea rax,[rip+0xe60] # 0x5a2e23632004
0x00005a2e236311a4 <+27>: mov rsi,rax
0x00005a2e236311a7 <+30>: lea rax,[rip+0xe58] # 0x5a2e23632006
0x00005a2e236311ae <+37>: mov rdi,rax
0x00005a2e236311b1 <+40>: call 0x5a2e23631080 <fopen@plt>
0x00005a2e236311b6 <+45>: mov QWORD PTR [rbp-0x8],rax
0x00005a2e236311ba <+49>: mov rax,QWORD PTR [rbp-0x8]
0x00005a2e236311be <+53>: mov rcx,rax
0x00005a2e236311c1 <+56>: mov edx,0xb
0x00005a2e236311c6 <+61>: mov esi,0x1
0x00005a2e236311cb <+66>: lea rax,[rip+0xe39] # 0x5a2e2363200b
0x00005a2e236311d2 <+73>: mov rdi,rax
0x00005a2e236311d5 <+76>: call 0x5a2e23631090 <fwrite@plt>
0x00005a2e236311da <+81>: mov rax,QWORD PTR [rbp-0x8]
0x00005a2e236311de <+85>: mov rdi,rax
0x00005a2e236311e1 <+88>: call 0x5a2e23631070 <fclose@plt>
0x00005a2e236311e6 <+93>: mov eax,0x1
0x00005a2e236311eb <+98>: leave
0x00005a2e236311ec <+99>: ret
End of assembler dump.
Assembly
복사
_IO_FILE_plus Struct
fopen을 분석하면서 _IO_FILE_plus의 구조체를 반환한다는 것을 알아냈다. 해당 구조체를 보면 아래와 같다.
FILE 구조체는 넘어가고 vtable을 먼저 보자
/* We always allocate an extra word following an _IO_FILE.
This contains a pointer to the function jump table used.
This is for compatibility with C++ streambuf; the word can
be used to smash to a pointer to a virtual function table. */
struct _IO_FILE_plus
{
FILE file;
const struct _IO_jump_t *vtable;
};
C
복사
_IO_jump_t Struct
JUMP_FIELD 매크로를 이용하여 함수의 주소를 전달한다.
struct _IO_jump_t
{
JUMP_FIELD(size_t, __dummy);
JUMP_FIELD(size_t, __dummy2);
JUMP_FIELD(_IO_finish_t, __finish);
JUMP_FIELD(_IO_overflow_t, __overflow);
JUMP_FIELD(_IO_underflow_t, __underflow);
JUMP_FIELD(_IO_underflow_t, __uflow);
JUMP_FIELD(_IO_pbackfail_t, __pbackfail);
/* showmany */
JUMP_FIELD(_IO_xsputn_t, __xsputn);
JUMP_FIELD(_IO_xsgetn_t, __xsgetn);
JUMP_FIELD(_IO_seekoff_t, __seekoff);
JUMP_FIELD(_IO_seekpos_t, __seekpos);
JUMP_FIELD(_IO_setbuf_t, __setbuf);
JUMP_FIELD(_IO_sync_t, __sync);
JUMP_FIELD(_IO_doallocate_t, __doallocate);
JUMP_FIELD(_IO_read_t, __read);
JUMP_FIELD(_IO_write_t, __write);
JUMP_FIELD(_IO_seek_t, __seek);
JUMP_FIELD(_IO_close_t, __close);
JUMP_FIELD(_IO_stat_t, __stat);
JUMP_FIELD(_IO_showmanyc_t, __showmanyc);
JUMP_FIELD(_IO_imbue_t, __imbue);
};
C
복사
JUMP_FIELD Macro
타입을 맵핑 해주는 단순 매크로다
#define JUMP_FIELD(TYPE, NAME) TYPE NAME
C
복사
fopen return 분석
이전 글에서 분석한 것과 동일하게 vtable 안에 _IO_file_jumps가 들어가 있는 것을 볼 수 있다.
gef➤ p (struct _IO_FILE_plus)$rax
$1 = {
file = {
_flags = 0xfbad2484,
_IO_read_ptr = 0x0,
_IO_read_end = 0x0,
_IO_read_base = 0x0,
_IO_write_base = 0x0,
_IO_write_ptr = 0x0,
_IO_write_end = 0x0,
_IO_buf_base = 0x0,
_IO_buf_end = 0x0,
_IO_save_base = 0x0,
_IO_backup_base = 0x0,
_IO_save_end = 0x0,
_markers = 0x0,
_chain = 0x76f9e12044e0 <IO_2_1_stderr>,
_fileno = 0x3,
_flags2 = 0x0,
_old_offset = 0x0,
_cur_column = 0x0,
_vtable_offset = 0x0,
_shortbuf = "",
_lock = 0x617f795fa380,
_offset = 0xffffffffffffffff,
_codecvt = 0x0,
_wide_data = 0x617f795fa390,
_freeres_list = 0x0,
_freeres_buf = 0x0,
__pad5 = 0x0,
_mode = 0x0,
_unused2 = '\000' <repeats 19 times>
},
vtable = 0x76f9e1202030 <_IO_file_jumps>
}
Bash
복사
_IO_file_jumps의 내부를 보면 함수들이 맵핑되어 있다.
gef➤ p *(*(struct _IO_FILE_plus*)$rax)->vtable
$5 = {
__dummy = 0x0,
__dummy2 = 0x0,
__finish = 0x76f9e1091a40 <_IO_new_file_finish>,
__overflow = 0x76f9e1092df0 <_IO_new_file_overflow>,
__underflow = 0x76f9e1092640 <_IO_new_file_underflow>,
__uflow = 0x76f9e10955a0 <__GI__IO_default_uflow>,
__pbackfail = 0x76f9e1096de0 <__GI__IO_default_pbackfail>,
__xsputn = 0x76f9e10939e0 <_IO_new_file_xsputn>,
__xsgetn = 0x76f9e1093d20 <__GI__IO_file_xsgetn>,
__seekoff = 0x76f9e1093160 <_IO_new_file_seekoff>,
__seekpos = 0x76f9e1095cc0 <_IO_default_seekpos>,
__setbuf = 0x76f9e1092400 <_IO_new_file_setbuf>,
__sync = 0x76f9e1093010 <_IO_new_file_sync>,
__doallocate = 0x76f9e1085120 <__GI__IO_file_doallocate>,
__read = 0x76f9e10938b0 <__GI__IO_file_read>,
__write = 0x76f9e1093940 <_IO_new_file_write>,
__seek = 0x76f9e10938d0 <__GI__IO_file_seek>,
__close = 0x76f9e1093930 <__GI__IO_file_close>,
__stat = 0x76f9e10938e0 <__GI__IO_file_stat>,
__showmanyc = 0x76f9e1096f90 <_IO_default_showmanyc>,
__imbue = 0x76f9e1096fa0 <_IO_default_imbue>
}
Bash
복사
그럼 여기서 생각을 할 수 있는 것이 만약 해당 함수포인터를 조작할 수 있다면? 원하는 함수를 원하는 시점에 호출할 수 있겠다고 생각할 수 있다.
fclose를 분석하면서 vtable에 있는 함수를 호출하는 것을 분석해보자.
fclose Function
어느정도 분석하는 내용은 이전 글에 넣었으니 빠르게 분석을 진행해보겠다.
fclose를 호출하면 _IO_new_fclose가 호출된다.
# define fclose(fp) _IO_new_fclose (fp)
C
복사
아래의 코드에서 조각 조각 분석을 진행하겠다.
_IO_new_fclose Code
if (fp->_flags & _IO_IS_FILEBUF)
_IO_un_link ((struct _IO_FILE_plus *) fp);
C
복사
_IO_un_link Function
간단하게 말하면 _IO_list_all의 _chain을 끊어주고 _IO_list_all에서 뺀 뒤 _flags &= ~_IO_LINKED을 수행하여 리스트에 연결을 끊어줬다는 표시를 한다.
void
_IO_un_link (struct _IO_FILE_plus *fp)
{
if (fp->file._flags & _IO_LINKED)
{
FILE **f;
#ifdef _IO_MTSAFE_IO
_IO_cleanup_region_start_noarg (flush_cleanup);
_IO_lock_lock (list_all_lock);
run_fp = (FILE *) fp;
_IO_flockfile ((FILE *) fp);
#endif
if (_IO_list_all == NULL)
;
else if (fp == _IO_list_all)
_IO_list_all = (struct _IO_FILE_plus *) _IO_list_all->file._chain;
else
for (f = &_IO_list_all->file._chain; *f; f = &(*f)->_chain)
if (*f == (FILE *) fp)
{
*f = fp->file._chain;
break;
}
fp->file._flags &= ~_IO_LINKED;
#ifdef _IO_MTSAFE_IO
_IO_funlockfile ((FILE *) fp);
run_fp = NULL;
_IO_lock_unlock (list_all_lock);
_IO_cleanup_region_end (0);
#endif
}
}
libc_hidden_def (_IO_un_link)
C
복사
if (fp->_flags & _IO_IS_FILEBUF)
status = _IO_file_close_it (fp);
C
복사
_IO_file_close_it Function
다른 코드는 일단 넘기고 _IO_do_flush 먼저 보자
int
_IO_new_file_close_it (FILE *fp)
{
int write_status;
if (!_IO_file_is_open (fp))
return EOF;
if ((fp->_flags & _IO_NO_WRITES) == 0
&& (fp->_flags & _IO_CURRENTLY_PUTTING) != 0)
write_status = _IO_do_flush (fp);
else
write_status = 0;
_IO_unsave_markers (fp);
int close_status = ((fp->_flags2 & _IO_FLAGS2_NOCLOSE) == 0
? _IO_SYSCLOSE (fp) : 0);
/* Free buffer. */
if (fp->_mode > 0)
{
if (_IO_have_wbackup (fp))
_IO_free_wbackup_area (fp);
_IO_wsetb (fp, NULL, NULL, 0);
_IO_wsetg (fp, NULL, NULL, NULL);
_IO_wsetp (fp, NULL, NULL);
}
_IO_setb (fp, NULL, NULL, 0);
_IO_setg (fp, NULL, NULL, NULL);
_IO_setp (fp, NULL, NULL);
_IO_un_link ((struct _IO_FILE_plus *) fp);
fp->_flags = _IO_MAGIC|CLOSED_FILEBUF_FLAGS;
fp->_fileno = -1;
fp->_offset = _IO_pos_BAD;
return close_status ? close_status : write_status;
}
libc_hidden_ver (_IO_new_file_close_it, _IO_file_close_it)
C
복사
_IO_do_flush Macro
_mode에 따라서 함수를 호출하는데 지금은 _IO_do_write 함수를 호출한다.
#define _IO_do_flush(_f) \
((_f)->_mode <= 0 \
? _IO_do_write(_f, (_f)->_IO_write_base, \
(_f)->_IO_write_ptr-(_f)->_IO_write_base) \
: _IO_wdo_write(_f, (_f)->_wide_data->_IO_write_base, \
((_f)->_wide_data->_IO_write_ptr \
- (_f)->_wide_data->_IO_write_base)))
C
복사
_IO_new_do_write Function
new_do_write 함수를 호출한다.
int
_IO_new_do_write (FILE *fp, const char *data, size_t to_do)
{
return (to_do == 0
|| (size_t) new_do_write (fp, data, to_do) == to_do) ? 0 : EOF;
}
libc_hidden_ver (_IO_new_do_write, _IO_do_write)
C
복사
new_do_write Function
여기서 핵심은 노란줄을 친 _IO_SYSWRITE 부분이다. 저기서 vtable을 호출한다.
static size_t
new_do_write (FILE *fp, const char *data, size_t to_do)
{
size_t count;
if (fp->_flags & _IO_IS_APPENDING)
/* On a system without a proper O_APPEND implementation,
you would need to sys_seek(0, SEEK_END) here, but is
not needed nor desirable for Unix- or Posix-like systems.
Instead, just indicate that offset (before and after) is
unpredictable. */
fp->_offset = _IO_pos_BAD;
else if (fp->_IO_read_end != fp->_IO_write_base)
{
off64_t new_pos
= _IO_SYSSEEK (fp, fp->_IO_write_base - fp->_IO_read_end, 1);
if (new_pos == _IO_pos_BAD)
return 0;
fp->_offset = new_pos;
}
count = _IO_SYSWRITE (fp, data, to_do);
if (fp->_cur_column && count)
fp->_cur_column = _IO_adjust_column (fp->_cur_column - 1, data, count) + 1;
_IO_setg (fp, fp->_IO_buf_base, fp->_IO_buf_base, fp->_IO_buf_base);
fp->_IO_write_base = fp->_IO_write_ptr = fp->_IO_buf_base;
fp->_IO_write_end = (fp->_mode <= 0
&& (fp->_flags & (_IO_LINE_BUF | _IO_UNBUFFERED))
? fp->_IO_buf_base : fp->_IO_buf_end);
return count;
}
C
복사
_IO_SYSWRITE Macro
JUMP2로 랩핑했으며 __write를 전달한다.
#define _IO_SYSWRITE(FP, DATA, LEN) JUMP2 (__write, FP, DATA, LEN)
C
복사
JMP2 Macro
_IO_JUMPS_FUNC Macro로 vtable에 있는 함수를 호출할 준비를 한다.
#define JUMP2(FUNC, THIS, X1, X2) (_IO_JUMPS_FUNC(THIS)->FUNC) (THIS, X1, X2)
C
복사
_IO_JUMPS_FUNC Macro
_IO_JUMPS_FILE_plus로 랩핑한 값으로 IO_validate_vtable을 호출한다.
먼저 _IO_JUMPS_FILE_plus을 분석해보자
# define _IO_JUMPS_FUNC(THIS) (IO_validate_vtable (_IO_JUMPS_FILE_plus (THIS)))
C
복사
_IO_JUMPS_FILE_plus Macro
_IO_CAST_FIELD_ACCESS의 분석을 먼저 진행하자.
#define _IO_JUMPS_FILE_plus(THIS) \
_IO_CAST_FIELD_ACCESS ((THIS), struct _IO_FILE_plus, vtable)
C
복사
_IO_CAST_FIELD_ACCESS Macro
•
_IO_MEMBER_TYPE
TYPE 구조체의 MEMBER 멤버가 어떤 자료형인지 추출하는 Macro
•
_IO_CAST_FIELD_ACCESS
THIS(fp)의 _IO_FILE_plus 구조체의 vtable 위치 즉 해당 offset 만큼 이동한다.
즉 _IO_JUMPS_FILE_plus의 결과는 fp→vtable이 나온다. 다음으로 중요한 IO_validate_vtable을 보자
/* Type of MEMBER in struct type TYPE. */
#define _IO_MEMBER_TYPE(TYPE, MEMBER) __typeof__ (((TYPE){}).MEMBER)
/* Essentially ((TYPE *) THIS)->MEMBER, but avoiding the aliasing
violation in case THIS has a different pointer type. */
#define _IO_CAST_FIELD_ACCESS(THIS, TYPE, MEMBER) \
(*(_IO_MEMBER_TYPE (TYPE, MEMBER) *)(((char *) (THIS)) \
+ offsetof(TYPE, MEMBER)))
C
복사
IO_validate_vtable Function
여기서 인자로 전달된 vtable은 위에서 분석했으니 넘어가고, _IO_jump_t 구조체만 한번 다시보겠다.
_IO_jump_t struct
#define IO_VTABLES_LEN (IO_VTABLES_NUM * sizeof (struct _IO_jump_t))
...
static inline const struct _IO_jump_t *
IO_validate_vtable (const struct _IO_jump_t *vtable)
{
uintptr_t ptr = (uintptr_t) vtable;
uintptr_t offset = ptr - (uintptr_t) &__io_vtables;
if (__glibc_unlikely (offset >= IO_VTABLES_LEN))
/* The vtable pointer is not in the expected section. Use the
slow path, which will terminate the process if necessary. */
_IO_vtable_check ();
return vtable;
}
C
복사
기능을 보면 아래와 같다
1.
vtable의 주소를 가져옴
2.
__io_vtables의 주소를 가져옴
3.
vtable - __io_vtables 계산(__io_vtables에서 얼마나 떨어져 있는지 알 수 있음)
4.
IO_VTABLES_LEN(IO_VTABLES_NUM * sizeof(_IO_jump_t))의 크기랑 비교
옛날 버전
즉 해당 코드에서 offset이 IO_VTABLES_LEN 보다 크면 vtable에서 호출하는 함수가 아닌 다른 함수를 호출한다고 보고 _IO_vtable_check 함수를 호출하여 프로그램을 종료한다.
실제로 asm으로 확인해보면 rax에 offset이 담겨 0x92f와 비교한다. 즉 vtable~vtable+0x92f 범위가 아니라면 프로그램을 종료한다.
<_IO_do_write+0098> cmp rax, 0x92f
Assembly
복사
Debugging
실제로 _IO_do_write를 실행하면서 보면 아래와 같이 실행된다. call [r14+0x78]을 한다.
r14에 어떤 값이 들어있는지 확인하면 _IO_file_jumps가 들어가 있고, 이는 fclose(fd)에서 fd.vtable에 있는 값이다.
r14+0x78의 값을 확인하면 아래와 같다
자 이제 vtable에서 함수를 호출하는 방식과 vtable 공격을 통해 이상한 함수를 호출하는 것을 막는 메커니즘에 대해서 배웠다.
다음 글에서 해당 IO_validate_vtable 우회 방법에 대해서 설명하겠다.
