_____ _______ .~. / __ \ |___ (_) /V\ | / \/ ___ _ __ ___ / / _ _ __ ___ // \\ | | / _ \| '__/ _ \ / / | | '_ \ / _ \ /( )\ | \__/\ (_) | | | __/./ /__| | | | | __/ ^`~'^ \____/\___/|_| \___|\_____/_|_| |_|\___| ------[ Corezine volume 02 - August 1999 Corezine #02 ================== 번역 : truefinder , seo@igrus.inha.ac.kr Last update : 2002/02/18 RUNTIME KERNEL KMEM PATCHING - Silvio Cesare - November 1998 INTRODUCTION 이 문서는 커널 메모리에 다이렉트로 접근하는 방식을 통한 runtime kernel patching기법을 기술한다. 공격자에의해 사용되는 커널 패칭의 예는 lsmod에 lkm의 visuality를 제거하는 기법이 보여진다. 그리고 참고로 loadable kernel modules이 native lkm을 서포트 하지 않는 시스템에서조차 runtime으로 수행된다는 것이다. 우리의 논의는 system symbol map을 적절하게 재구성하는 것까지 다루어진다. 이 문서에서 목적하는 바를 위해 linux kernel programming skills이 필요하다. ELF를 사용해서 object code를 linking하는 섹션을 위해서는, ... 흥미있는 독자들은 ELF의 spec을 찾아보기를 강력히 추천한다. 구현된 것을 모두 이해했다면 이것은 특별히 당신에게는 진실이다. THE KERNEL SYMBOL LIST Linux는 symbol들이 export 되었던지 그렇지 않았던지 간에 kernel에 의해 쓰이는 모든 symbol을 위치시키기 위한 수단을 제공한다. 이것은 System.map에 의해 가능하다. 이것은 커널 컴파일을 위해 쓰이는 object file에서 symbol 정보를 추출함으로써 컴파일시에 만들어 지게 된다. # cat /System.map 00100000 T _stext 00100000 T stext 00100000 t startup_32 001000bc t isnew 00100118 t is486x 00100183 t n6x86 . . . 그래서 우리는 symbol들을 이름으로 identify한다는 것을 볼 수 있다. 우리가 직접 사용할수 있는 address는 /dev/kmem을 통한 커널 메모리를 참조한다. exported된 Kernel symbol들은 global하게 visible하며, 커널내에서 유지된다. 그리고 이것은 이미 설명했듯이 System.map을 필요로하지 않는 /proc/ksysm과 get-kernel_syms() 을 통해 user-land에 유효하다. 그러나 이것은 lkm support가 커널에 컴파일되었을때만 유효하다. DIRECT KERNEL MEMORY ACCESS IN LINUX 리눅스상에서의 메모리 direct access는 두개의 device file에 의해서 제공된다. /dev/mem 은 선형메모리의 매핑화일이다. /dev/kmem은 사용가능한 모든 가상메모리의 매핑화일이다. 이것은 선형 메모리가 swap공간을 더한다는 것이다. device화일들을 메모리로 사용하기 위해 그것을 열어서 그것을 평범하게 쓰는 것이 요구된다. 랜덤 access는 그것을 읽거나 쓰기전에 적절한 위치를 찾는 것이 필요하다. BUILDING SYMBOL INFORMATION FROM KMEM System.map 은 Linux를 돌리는데 꼭 필요하지 않다. 만약 lkm이 원천적으로 kernel에서 지원 되지 않는다면 /proc/ksyms도 마찮가지이다. 그러나, symbol 정보는 kmem을 사용해서 kernel 을 patching하는데 유용하다. kmem을 이용해서 running kernel로 부터 symbol정보를 재 구성 하는 것에 대한 다양한 접근이 유효하다. 가장 쉬운 방법은 symbol의 주소에서 몇바이트를 copy하는 것이다. 그리고 이것을 문자열 검색에 의해 kmem에 symbol을 위치시키기 위한 key로써 활용하는 것이다. 이러한 접근은 예를 들어 , 함수같은 것이 나타나는 symbol들을 위치시키기 위해 아주 이상적이다. 기계어 코드 instruction들은 key로 활용될것이다. 그러나 이것은 아마도 architecture들과 커널 버젼들사이를 변화시킬 것이다. 그래서 함수들을 위한 key list들은 각각의 커널버젼과 각 구조에 의해 유지되어야 한다. 이와 유사하게, 만약 함수들이 컴파일 타임 configuration 코드를 사용한다면, 우리가 특별한 configuration을 위한 key을 사용한다 할지라도 이러한 접근은 실패할 것이다. 그러나 일반적으로 이것은 아주 그나마 성공적이라고 할 수 있다. 그리고 key list의 구성과 검색은 많은 수의 symbol들을 찾기에 자동화되기가 용이하다. 이 접근방식은 key list가 구성된 곳의 머신상에서 유효한 symbol 정보를 요한다. 이 정보는 System.map이나 /proc/ksyms를 쓸수 있다, 보통 많은 시스템에서는 System.map이 없고, 커널의 컴파일중 copy되지 않는다. 따라서 후자의 (/proc/ksyms)쪽이 더 나은 소스라고 할수 있다. key lists를 구성하는 implementation은 build-ksyms-keys.sh이다. 이것은 key 길이로 최저 15bytes를 사용한다. 그러나 이 길이로 각 symbol들의 key가 구별되지 않을 경우 현재 키 길이를 늘여야 한다. 그러나 이러한 method에는 문제가 있다. 이것은 보통 알려지지 않은 다른 심볼을 참조하는 수많은 함수들을 위한것이다. 이러한 문제를 풀기위해 필요한것 은 우리가 어느부분의 key list가 random한지를 알아서 안전하게 무시할 수있어야 한다. 이렇게 하기 위해 , 우리는 key list를 만들수 있다. 어떤키가 전체적으로 사용될 것인가를 가정해야 하고, 그때 우리는 우리의 키 list를 커널에 새로이 update해야 한다. 커널사이에 어떠한 것이 바뀌었나를 살펴봄는 것은,이를 통해 우리가 무엇을 무시살것인가로 사용할 수 있다. 역시 , 이것은 우리의 키가 얼마나 유용한거에 대한 타당한 추측을 주고, 만약 key가 전혀 stable이 아니면 discard되어야 한다. 자료구조를 메모리에 올리는 것 역시 이러한 serch key 기법을 사용해서 접근이 가능하다. 이것을 위해 우리는 가능한한 자료구조에서 많은 정보를 알아야 한다. 그래서 우리는 그러한 일을 위해 신뢰할수 있는 key를 가져야 한다. key가 문자열일 필요는 없다. 그러나, 우리는 그것안에 감춰진 필드를 앎으로 인해, 구조를 탐색할수 있다. 실제 예제는 소스에 구현되어 있다. From /usr/include/linux/module.h struct module { struct module *next; struct module_ref *ref; /* the list of modules that refer to me */ struct symbol_table *symtab; const char *name; int size; /* size of module in pages */ void* addr; /* address of module */ int state; void (*cleanup)(void); /* cleanup routine */ }; 역) /* 2.2.5-22 실제 /usr/include/linux/module.h */ struct module { unsigned long size_of_struct; /* == sizeof(module) */ struct module *next; const char *name; unsigned long size; union { atomic_t usecount; long pad; } uc; /* Needs to keep its size - so says rth */ unsigned long flags; /* AUTOCLEAN et al */ unsigned nsyms; unsigned ndeps; struct module_symbol *syms; struct module_ref *deps; struct module_ref *refs; int (*init)(void); void (*cleanup)(void); const struct exception_table_entry *ex_table_start; const struct exception_table_entry *ex_table_end; #ifdef __alpha__ unsigned long gp; #endif /* Members past this point are extensions to the basic module support and are optional. Use mod_opt_member() to examine them. */ const struct module_persist *persist_start; const struct module_persist *persist_end; int (*can_unload)(void); }; 모듈에서 name은 문자열을 가르키는 pointer이다. 이러한 모듈 자료구조를 메모리에 올리기 위해 우리는 두가지 경로를 가진다. 첫번째, 우리는 string과 match되는 것을 모두 찾는 것이다. 이 string은 물론 module의 이름이다. 그리고 두번째 경로에서 , 우리는 모듈 자료구조에서 name의 값로서 이 문자열의 주소를 사용할수 있다. 이 탐색을 실제적인 것으로 하기위해, 우리는 serch key를 벗어난 부분적으로 완전한 모듈 구조에 가능한한 많이 채워넣는 시도를 해야 한다. 모듈의 size는 module을 리스팅하는데 사용된다. 그리고 우리는 이것을 우리의 key를 더욱 유용하게 한다. # lsmod Module Pages Used by ppp 5 1 (autoclean) slhc 2 [ppp] 1 (autoclean) serial 8 1 ipx 4 0 rarp 1 0 smbfs 7 0 nfs 13 4 # 페이지 숫자들은 페이지 상의 모듈 사이즈를 말한다. 그래서 우리는 모듈 자료구조를 사용하는 데 쓸수 있다. 모듈의 state는 MOD_RUNNING으로 가정되고, 이것은 모듈이 현재 작동되고 있다는 것이다. ( 이것은 지워지려고 하는것과, 초기화 된것과는 다르다.) ref는 NULL로 가정된다. 이것은 어떠한 module들도 이것을 참조하지 않을 것이라는 것이다. 따라서 cleanup은 NULL로 간주되지 않는다. symbol을 위치시키기위한 다른 방법은 만약 이것이 알려진 symbol과 정적인 거리를 갖는다고 할때, 알려지지 않는 symbol은 알려지지 않는 symbol은 알려진 symbol의 함수로 발견된다는 것이다. From /usr/src/linux-2.0.35/kernel/sched.c . . . struct task_struct * task[NR_TASKS] = {&init_task, }; struct kernel_stat kstat = { 0 }; . . . task는 우리가 위치시킬 symbol이다. 이것은 /proc/ksyms에 있지 않다. 그러나 kstat에는 있다. 그래서 우리는 다음과 같은 열을 볼수 있다. ADDR(task) == ADDR(kstat) - NR_TASKS * sizeof(struct task_struct *) 이것은 가능하다. 그러나 우리는 각 structure를 구별하는데 사용할 어떠한 정보도 가지고 있지 못하다. 그것은 structure가 우리의 임이의 위치에서 혹은 unknown data에서부터 나오기 때문이다. 또한 알려진 심볼을 참조 포인트로써 쓸수도 없다. 만약 이런일이 발생하면 , 우리는 structure를 간접적으로 우리가 찾는 자료구조를 참조하는 코드를 찾음으로써 위치시킬수 있다. From /usr/src/linux-2.0.35/arch/i386/kernel/entry.S . . . * Stack layout in 'ret_from_system_call': * ptrace needs to have all regs on the stack. * if the order here is changed, it needs to be * updated in fork.c:copy_process, signal.c:do_signal, * ptrace.c and ptrace.h * * 0(%esp) - %ebx * 4(%esp) - %ecx * 8(%esp) - %edx * C(%esp) - %esi * 10(%esp) - %edi * 14(%esp) - %ebp * 18(%esp) - %eax * 1C(%esp) - %ds * 20(%esp) - %es * 24(%esp) - %fs * 28(%esp) - %gs * 2C(%esp) - orig_eax * 30(%esp) - %eip * 34(%esp) - %cs * 38(%esp) - %eflags * 3C(%esp) - %oldesp * 40(%esp) - %oldss */ . . . ALIGN 1: call SYMBOL_NAME(syscall_trace) movl ORIG_EAX(%esp),%eax call *SYMBOL_NAME(sys_call_table)(,%eax,4) movl %eax,EAX(%esp) # save the return value #ifdef __SMP__ GET_PROCESSOR_OFFSET(%eax) movl SYMBOL_NAME(current_set)(,%eax),%eax 코드안에서 sys_call_table이 참조되는 것으로 보인다. 만약 우리가 이것을 부분적으로 위치시킬수 있다면, 우리는 sys_call_table의 위치를 끌어낼수 있다. 그리고 이것이 key의 효율성을 증가시키기위해 가능한한 많은 instruction들을 사용할수 있게 준비 한다. 이것은 작은 key를 이용한 pointless searching이다. 그래서 이것들은 많은가능한 match들을 구분해 준다. sys_call_table을 참조하는 적당한 instruction들을 사용함으로써 우리는 우리 자신에게 좋은 key를 제공할수 있다. 이러한 instructions들은 알려지지 않은 것들은 사용하지 않는다. 따라서 적절히 사용될수 있다. 이와 비슷하게 __SMP__ 에 의존한 코드는 사용하지 않을것이다. 결국 우리가 사용할 코드는 다음과 같다. movl ORIG_EAX(%esp),%eax call *SYMBOL_NAME(sys_call_table)(,%eax,4) movl %eax,EAX(%esp) # save the return value 우리가 이 코드를 dummy 프로그램에 컴파일하고, 이것은 objdump로 떠보면서 우리는 우리의 search key를 뽑아낼수 있다. 이 search key는 부분적으로는 완전치않은 문자열로 생각된다. entry.S 코드는 자주 바뀌지 않으며 이것은 또한 많은 kernel에서 보여진다. 그래서 우리는 각 커널마다 다른 search key를 사용할 필요는 없다. 즉 이것은 이러한 특별한 아키텍쳐에 사용될수 있지만, 그러나 같은 법칙이 다른 것에도 적용된다는 말이다. 첫번째 예는 kenel structure를 어떻게 바꾸는가에 대한 간단한 예제 application이다. kroot는 수퍼유저가 되기위한 process의 uid를 바꾸는 프로그램으로 제공된다. 이것은 실제 mem device가 insecure하지 않은 이상 현실적이지 못하다. - 원래 이것은 예전에 kernel bug로 알려져 있다. 그러나 이것은 우리에게 좋은 example을 준다. algorithm 은 다음과 같다. * /dev/kmem을 open하고 * task symbol의 address를 찾는다. * task table을 메모리에 잃어오고 * 우리가 변형하고자 하는 task를 적절히 위치시킨다. * task를 superuser uid에 상충하게 수정하고 * 화일안에서 특정 task를 찾는다. * 그후, 변형된 task를 쓴다. 'task' symbol의 address를 위치시키기 위해 우리는 위에서 말한 방법을 써야 한다. 더 실제적인 에제가 주어져 있다. 모듈 커널 구조를 module listing에서 제거하기 위한 패칭기법 이다. From /usr/src/linux-2.0.35/kernel/module.c . . . /* * Called by the /proc file system to return a current list of modules. */ int get_module_list(char *buf) { . . . q = mp->name; if (*q == '\0' && mp->size == 0 && mp->ref == NULL) continue; /* don't list modules for kernel syms */ . . . 이것은 이름이 list되지 않은 lkm이 비어있는 것으로 보여진다. size는 0이고 ref또한 NULL이다. lkm 'zapper'의 구현은 이러한 정보를 module 구조의 size와 ref 멤버들을 패치하기 위해 사용 된다. 그리고 이것은 name을 empty string으로 패치할 것이다. 이 반대도 가능하다. zapping 프로세스상에 siz와 ref 포인터를 가지고 있다면 이것은 가능하다. PATCHING THE KERNEL TO RUN INSERTED KERNEL CODE 리눅스는 sys_call_table이라고 나타나는 system call table을 제공한다. 이 table은 fixed size array이고, 각 array의 요소들은 각 system call을 지시하는 pointer이다, 각 숫자들이 가지는 의미는 그 array의 intex이다. 만약 , 어떤 system call도 그 syscall 숫자를 위해 구현되지 않았다면 , 그 element는 NULL pointer이다. 보통 syscall table의 많은 element들이 syscall slot 에서 사용가능한 null을 나타내고 있다. 새로운 커널코드의 주소를 알고있음으로 해서, 우리는 syscall table을 패칭할수 있고 empty slot을 우리의 코드로 가르키게 할수 있다. kernel code를 동작시키기위해서는 , 우리는 어떤 call을 새로운 user-land syscall을 리눅스가 도입한 int 0x80 메커니즘을 통해 부를수 있다. 이로써 우리의 코드가 동작하게 되는것이다. PATCHING THE KERNEL TO INSERT NEW CODE /dev/kmem은 우리에게 직접 kernel memory에 접근할수 있도록 해준다. 그래서 우리가 새로운 코드를 쉽게 삽입한다는 것은 memory부분을 overwrite한다는 말이 된다. 한가지 중요한것은 우리가 kernel 을 stable한 상태로 놓아두기 위해 우리는 이미 할당되거나 사용되고 있는 internal kernel 구조를 overwrite할 수는 없다는 것이다. 커널 공간에서 kmalloc pool을 사용하는 것은 가능한 일이다. 그러나 우리는 그것이 이미 kmalloc에 의해 사용되어지고 있는지 확신할수가 없다. 비슷하게 , 우리가 비록 free memory를 찾기위해 할당된 black header들을 찾는다고 할지라도, operation들은 atomic이 아니고 따라서 이것은 kernel과의 race 할수 있는 상태를 만들수 있다. kernel memory의 선형 layout은 다음과 같다. [compile time kernel memory reserve] [kmalloc pool] kmalloc pool의 한계는 이미 memory_start , memory_end라는 symbol에 의해 정의되어 있다. [compile time kernel memory reserve] memory_start: [kmalloc pool] memory_end: kmalloc pool은 그러나 memory_start의 page border에 정렬되어 있고, 그래서 아래와 같은 모양이 된다. Key: [..] a complete page K kmalloc pool P padding R reserve (compile time kernel text/data etc) [RRRRRRRRRRRR] ... [RRRRRRRRRRRR] [RRRR memory_start: PPPPPPPP] [KKKKKKKKKKKK] ... [KKKKKKKKKKKK] memory_end: padding들은 우리에게 새로운 커널코드에 대한 이상적인 위치를 제공해 준다, as it is totally safe to use as the kernel is not allowed to use this memory. 우리가 memory_start를 위치시키기 위해 System.map이나 다른 technique을 사용하는 것은 아주 이상적인 상황이다. It is preferable however if we can not to use a symbol who's address is not known at runtime without location. From /usr/src/linux-2.0.35/arch/i386/mm/init.c . . . /* * BAD_PAGE is the page that is used for page faults when linux * is out-of-memory. Older versions of linux just did a * do_exit(), but using this instead means there is less risk * for a process dying in kernel mode, possibly leaving a inode * unused etc.. * * BAD_PAGETABLE is the accompanying page-table: it is initialized * to point to BAD_PAGE entries. . . . From /usr/src/linux-2.0.35/arc/i386/kernel/head.S . . . .org 0x3000 ENTRY(empty_bad_page) .org 0x4000 ENTRY(empty_bad_page_table) .org 0x5000 ENTRY(empty_zero_page) . . . 이것들은 압축된 kernel image를 위해 모두 0x100000 에서 시작하고 있다. 그래서 empty_bad_page는 0x100300이고, 사이즈는 4097 bytes이다. 메모리의 고갈은 보통 일어나지 않는다. 그리고 우리는 empty_bad_page를 그렇게 두려워 하지 않고도 우리 자신의 코드로 사용할 수 있다. PATCHING NEW CODE INTO THE LINUX KERNEL 새로운 코드를 커널에 patching하는 데는 두 가지가 필요하다. 코드가 kernel space에 있어야 하며 그것을 부를수 잇는 calling method가 필요하다. 위의 text는 이것을 충족시킬만한 충분한 언급을 하고 있다. algorithm은 다음과 같다. * 새로운 코드를 이미 기술한 방법을 사용하여 memory에 넣는다. * sys_call_table을 patch한다. 그래서 syscall이 새로운 코드를 가르키게 한다. * syscall이 우리의 새로운 코드로 가르키게한다. OBJECT CODE (LKM) INSERTING OF KERNEL CODE object code를 넣는 것은 code를 직접적으로 넣는 같은 원칙을 따른다. 그러나 이전에 언급했듯이 kernel symbol reference들은 kernel symbol table을 봄으로써 사용되는 정확한 주소를 요구한다. symbol을 주소에 binding하는것은 우리가 매뉴얼을 따라서 하는 것과는 거리가 먼 linking이다. non trivial code메뉴얼 링킹은 우리가 볼수 있는 솔루션이 아니다. 그리고 linking 은 우리가 사용하는 ㅏ알고리듬에 추가되어야 한다. OBJECT CODE (LKM) LINKING TO KERNEL ELF는 Linux상에서 object code를 표현하는데 아주 전형적인 표준이다. 이 문서는 ELF object를 사용해서 링킹하는 것을 참조할 것이다. object code 화일은 ELF를 사용할 때 재배치 가능 코드로 참조된다. 그것이 무엇인지를 summarize하기 때문이다. 이것은 어느 메모리 위치에도 fix되지 않는다. 재배치화일을 실해가능한 이미지로 만들어 내는 것과 심볼들을 주소로 바인딩하는것은 링킹의 책임이다. 코드를 링킹하는것은 fix된 위치에 코드를 재배치하는 것에 의해 수행된다. 대부분 , object code는 많이 바뀌지는 않는다. 다음과 같은 C code를 참조해 보자. { char s[] = "I wonder where I'm located..."); printk(KERN_INFO "%s\n", s); } 문자열 's'는 컴파일시 절대적인 위치를 가지고 있지 않은 object코드안의 재배치 text section의 부분으로 존재한다. 비슷하게 printk는 전역적인 symbol로 선언되어있다. 그리고 이것의 address는 역시 컴파일시에 알지 못한다. ELF object안의 재배치 section들은 object안에서 어떤것이 수정되어야 하는지 기술하고 있다. 위의 경우, 재배치 엔트리들은 printk와 string의 reference를 위해 만들어 진다. ELF 재배치 object의 format 은 다음과 같다. ELF header Program header table Section 1 Section n Section header table From /usr/include/elf.h /* The ELF file header. This appears at the start of every ELF file. */ #define EI_NIDENT (16) typedef struct { unsigned char e_ident[EI_NIDENT]; /* Magic number and other info */ Elf32_Half e_type; /* Object file type */ Elf32_Half e_machine; /* Architecture */ Elf32_Word e_version; /* Object file version */ Elf32_Addr e_entry; /* Entry point virtual address */ Elf32_Off e_phoff; /* Program header table file offset */ Elf32_Off e_shoff; /* Section header table file offset */ Elf32_Word e_flags; /* Processor-specific flags */ Elf32_Half e_ehsize; /* ELF header size in bytes */ Elf32_Half e_phentsize; /* Program header table entry size */ Elf32_Half e_phnum; /* Program header table entry count */ Elf32_Half e_shentsize; /* Section header table entry size */ Elf32_Half e_shnum; /* Section header table entry count */ Elf32_Half e_shstrndx; /* Section header string table index */ } Elf32_Ehdr; /* Conglomeration of the identification bytes, for easy testing as a word. */ #define ELFMAG "\177ELF" #define SELFMAG 4 /* Legal values for e_machine (architecture). */ #define EM_386 3 /* Intel 80386 */ #define EM_486 6 /* Intel 80486 */ /* Legal values for e_version (version). */ #define EV_NONE 0 /* Invalid ELF version */ #define EV_CURRENT 1 /* Current version */ From the ELF specifications. "String Table String table 섹션들은 null-terminated 문자 sequence를 갖는다. 보통 문자열이라고 불리운다. object file은 이러한 문자열을 심볼과 섹션이름을 나타내는데 쓴다. string table section안 에서 인덱스로써 참고가 된다. 첫번째 byte는 index 0이고, 이것은 null 문자를 가지고 있게 정의된다. 비슷하게, 문자 table들의 마지막 byte는 null로 정의된다, 모든 문자들이 null로 끝나게 된다. index가 0인 string은 이름을 가지고 있지도 않거나 null 이름으로 특정지워진다. 이것은 context에 의존적이다. empty 문자열 테이블 section은 허용된다. 그것의 secton header의 sh_size멤버가 zero를 가르킬 것이다. Non-zero인덱스들은 empty문자열 테이블에 대해 유용하지 않다. . . . Sections object file의 section header table은 모든 화일의 section들을 위치시키게 한다. section header table은 아래에서 설명하는 것과 같이 Elf32_Shdr 구조의 배열이다. section header table index는 이 배열의 subscript이다. ELF header들의 e_shoff 멤버는 file의 시작부터 section header table까지의 byte offset을 준다; e_shnum은 얼마나 많은 entry들을 section header가 가지고 있는가를 말해준다. ;그리고 e_shentsize는 각 엔트리의 size를 말해준다. From /usr/include/elf.h /* Section header. */ typedef struct { Elf32_Word sh_name; /* Section name (string tbl index) */ Elf32_Word sh_type; /* Section type */ Elf32_Word sh_flags; /* Section flags */ Elf32_Addr sh_addr; /* Section virtual addr at execution */ Elf32_Off sh_offset; /* Section file offset */ Elf32_Word sh_size; /* Section size in bytes */ Elf32_Word sh_link; /* Link to another section */ Elf32_Word sh_info; /* Additional section information */ Elf32_Word sh_addralign; /* Section alignment */ Elf32_Word sh_entsize; /* Entry size if section holds table */ } Elf32_Shdr; From the ELF specifications. "Symbol Table object file의 symbol table은 프로그램을 제배치하고 위치시키기위한 symbolic 정의들과 참조를 위한 정보들을 가지고 있다. symbol table인덱스는 이 array에 subscript 이다. index 0는 역시 테이블상에서 첫번째 entry로 디자인되어있고 정의되지 않은 symbol index로 제공되어 진다. 초기의 내용물은 이 섹션상에서 나중에 정해진다. /* Symbol table entry. */ typedef struct { Elf32_Word st_name; /* Symbol name (string tbl index) */ Elf32_Addr st_value; /* Symbol value */ Elf32_Word st_size; /* Symbol size */ unsigned char st_info; /* Symbol type and binding */ unsigned char st_other; /* No defined meaning, 0 */ Elf32_Section st_shndx; /* Section index */ } Elf32_Sym; #define SHN_UNDEF 0 /* No section, undefined symbol. */ /* How to extract and insert information held in the st_info field. */ #define ELF32_ST_BIND(val) (((unsigned char) (val)) >> 4) #define ELF32_ST_TYPE(val) ((val) & 0xf) #define ELF32_ST_INFO(bind, type) (((bind) << 4) + ((type) & 0xf)) /* Legal values for ST_BIND subfield of st_info (symbol binding). */ #define STB_LOCAL 0 /* Local symbol */ #define STB_GLOBAL 1 /* Global symbol */ #define STB_WEAK 2 /* Weak symbol */ #define STB_NUM 3 /* Number of defined types. */ #define STB_LOPROC 13 /* Start of processor-specific */ #define STB_HIPROC 15 /* End of processor-specific */ From the ELF specifications. "재배치 섹션은 다른 두 섹션들을 참조한다 : 심볼 table과 수정하기 위한 또 다른 section이 그것이다. 여기서 section header의 sh_info와 sh_link필드들은, 앞에서 말한 Section에서 이러한 관계를 지정해 주게된다. 서로 다른 object화일들을 위한 재배치 엔트리들은 r_offset을 위한 해석에서 상당히 다르다. 재배치 화일들에서, r_offset은 section offset을 가지고, 재배치 섹션 자신은 어떻게 다른 섹션을 ㅋ 화일에서 고쳐야 하는지를 기술한다. 재배치 offset은 두번째 섹션안의 저장 unit을 디자인한다. From /usr/include/elf.h /* Relocation table entry without addend (in section of type SHT_REL). */ typedef struct { Elf32_Addr r_offset; /* Address */ Elf32_Word r_info; /* Relocation type and symbol index */ } Elf32_Rel; /* How to extract and insert information held in the r_info field. */ #define ELF32_R_SYM(val) ((val) >> 8) #define ELF32_R_TYPE(val) ((val) & 0xff) #define ELF32_R_INFO(sym, type) (((sym) << 8) + ((type) & 0xff)) 이러한 선택되어진 ELF spec과 header화일로부터의 패러그래프들과 섹션들은 우리에게 상위 레벨의 개념 즉, 어떻게 재배치 ELF 화일이 실행되기에 충분한 이미지를 만들기 위해 링크 되는지에 대한 개념을 준다. lkm을 링킹하는 과정은 다음과 같다. * 재배치 가능한 ELF포맷에서 처럼 화일을 구분짓는다. * 각 relevant section들을 메모리에 로드한다. * 각 PROGBIT 섹션들을 위해 메모리에 section 주소를 세팅한다. * 각 REL section을 위해 relocation을 carry out한다. * 실행가능한 이미지를 sections들을 예상되는 위치의 메모리에 copy해 넣으면서 분리한다. lkm의 cleanup코드와 초기화코드가 어디에 위치하는지 안다면, 다른 추가의 step을 수행해 줘야한다. * 재배치 가능한 ELF포맷에서 처럼 화일을 구분짓는다. * 각 relevant section들을 메모리에 로드한다. * 각 PROGBIT 섹션들을 위해 메모리에 section 주소를 세팅한다. * 각 REL section을 위해 relocation을 carry out한다. * 실행가능한 이미지를 sections들을 예상되는 위치의 메모리에 copy해 넣으면서 분리한다. * init_module이나 clean_module의 주소를 프린트하고, 위치시킨다. 재배치 스텝은 다음의 알고리즘을 확장해야 할 것이다. * 재배치 엔트리의 목적 섹션을 구한다. * 재배치 엔트리의 심볼테이블을 구한다. * 재배치가 적용될 섹션상에서의 위치를 구한다. * 재배치에 사용되는 심볼의 주소를 구한다. * 재배치를 적용한다. 실제적인 재배치는 소스에 나타나있다. 재배치에 대한 더 많은 정보는 ELF 스펙을 참조하라. 그리고 우리는 global offset table과 온전한 재배치 타입을 철저히 무시했다는 것을 알아둬라. switch (ELF32_R_TYPE(rel->r_info)) { case R_386_NONE: break; case R_386_PLT32: case R_386_PC32: *loc -= dot; /* *loc += addr - dot */ case R_386_32: *loc += addr; break; 재배치에 사용되는 심볼의 주소를 계산하는 것은 확장될수도 있다. 만약에 심볼이 local이라면 그것은 STB_LOCAL이다.따라서 심볼은 현재 object 심볼테이블에 위치해 있을 것이다. ,그리고 그것이 현재의 object에서만 보여진다는것도 유의하라. 만약 symbol이 STB_GLOBAL이라고 한다면, 심볼은 object에대해 전역이고, 그 심볼의 주소는 이 인스턴스에서 커널 심볼이 되기 위해 알려져 있다. 그래서 우리는 System.map을 사용함으로써 혹은, 심볼의 주소를 결정하는 기술을 통해 이것을 사용할수 있다. 이 경우는, 제공되는 소스를 참고하는 것이 가장 좋은 길이다. BOOTSTRAP LOADING OF OBJECT CODE (LKM) 사실상, 실제 lkm은 kmalloc pool 패딩에 맞지 않을것이다. 비슷하게 우리가 empty_bad_page를 쓴다면, single page보다 클것이리라. 그것에 대한 솔루션은 bootstrap이 lkm을 로드하게 하는것이다. kmalloc의 일반적인 커널 method를 사용하여 할당된 메모리의 padding안에 부트스트랩 로더를 삽입하므로써 할 수 있다. 그리고 그것을 실제의 lkm에 넣고 메모리을 할당하여 실행시킨다. bootstrap 로더는 충분하게 작아질수 있고 우리의 lkm들은 어느 사이즈로든 맞추어질수 있다. 실제로, 커널이 bootstraping을 enable시키기위해 커널속에 넣어야할 우리가 필요로하는 코드는 우리가 로드해서 실행시키고자하는 실제 모듈을 충족시킬만한 메모리블럭을 할당한 return 주소일것이다. THE PROVIDED IMPLEMENTATION 첨부된 소스는 위에서 언급한 모든 알고리즘을 포함한다. front end 쉘 스크립트는 유저에게 알려지지 않은 내부 세부사항에서 벗어나게 해주기 위해 제공된다. CONCLUSION 알고리즘과 구현에 따른 토른은 커널의 nativer 서포트를 통해 명확히 나타날수 있는 어떤 것을 제공하기 위해 메모리에 직접적으로 접근하는 것이 가능하다는 것을 데모로 제공한다. 다른 유저의 배열을 사용하는 공격자를 위한 실제적인 예을 제공할 수 있는, 또한 커널 메모리에 대한 접근을 실제 보여주는 제공되는 프로그램들은 공허한 생각만이 아니라 실제적으로 구현된 매우 유용한 개념이다. --