Background: PIE

---

서론

ASLR이 적용되면 바이너리가 실행될 때마다 스택, 힙, 공유 라이브러리 등이 무작위 주소에 매핑되므로,
공격자가 이 영역들을 공격에 활용하기 어렵습니다. 그러나 지난 코스의 실습 addr을 떠올려 보면,
다른 영역의 주소는 계속 변화하는데 main함수의 주소는 매번 같았습니다.

Mitigation: NX & ASLR

이런 특징을 이용해 공격자는 고정된 주소의 코드 가젯을 활용한 ROP를 수행할 수 있습니다.
Position-Independent Executable(PIE)은 ASLR이 코드 영역에도 적용되게 해주는 기술!!
이 기술은 보안성 향상을 위해 도입된 것은 아니라 엄밀히 말하면 보호 기법 X

그러나 실제론 ASLR과 맞물려 공격을 더욱 어렵게 만들기에 여러 곳에서 보호기법으로 소개됩니다.
저희 로드맵에선 기술로 소개하겠습니다.

// Name: addr.c
// Compile: gcc addr.c -o addr -ldl -no-pie -fno-PIE
 
#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
 
int main() {
  char buf_stack[0x10];                   // 스택 버퍼
  char *buf_heap = (char *)malloc(0x10);  // 힙 버퍼
 
  printf("buf_stack addr: %p\n", buf_stack);
  printf("buf_heap addr: %p\n", buf_heap);
  printf("libc_base addr: %p\n",
         *(void **)dlopen("libc.so.6", RTLD_LAZY));  // 라이브러리 주소
 
  printf("printf addr: %p\n",
         dlsym(dlopen("libc.so.6", RTLD_LAZY),
               "printf"));  // 라이브러리 함수의 주소
 
  printf("main addr: %p\n", main);  // 코드 영역의 함수 주소
}

PIE가 적용되지 않은 addr의 실행 결과

---

PIC와 PIE

리눅스에서 ELF는 실행파일(Executable)과 공유 오브젝트(Shared object; SO)로 두가지로 존재합니다.
실행파일은 ./addr과 같으며 공유 오브젝트 파일은 libc.so라고 할 수 있습니다.

공유 오브젝트는 기본적으로 재배치(Relocation)가 가능하도록 설계되어 있습니다.
재배치가 가능하다는 것은 메모리의 어느 주소에 적재되어도 코드의 의미가 훼손 X를 의미

CS에선 이런 성질을 만족하는 코드를 Position-Independent Code(PIC)라고 부릅니다.

addr과 libc-2.27.so의 파일 형식

gcc는 PIC 컴파일을 지원합니다.

PIC가 적용된 바이너리와 아닌 바이너리를 비교하기 위해 다음 예제를 컴파일하고,
어셈블리 코드를 비교하겠습니다.

// Name: pic.c
// Compile: gcc -o pic pic.c
//            : gcc -o no_pic pic.c -fno-pic -no-pie
 
#include <stdio.h>
 
char *data = "Hello World!";
 
int main() {
  printf("%s", data);
  return 0;
}
 

---

PIC 코드 분석

no_pic와 pic의 main함수를 비교해보면, main+14에서 "%p" 문자열을 printf에 전달 방식과 다릅니다.

left : no_pic & right : pic

no_pic에서는 0x404018라는 절대 주소에서 문자열을 참조받고 있습니다. 반면에..
pic는 문자열의 주소를 rip+0xec3(0x55..6011)에서 참조받는 모습입니다.

바이너리가 매핑되는 주소가 바뀌면 no_pic에서는 함께 있던 데이터를 담은 주소도 이동하므로
참조가 불가능하나, pic는 rip를 통한 상대 참조(Relative Addressing)로써 데이터를 제공받기에 문제 X

---

PIE(Position-Independent Executable)

무작위 주소에 매핑되어도 실행 가능한 실행 파일

ASLR이 도입 전, 실행 파일을 무작위 주소에 매핑할 필요가 없었기에 초기 리눅스 실행 파일 형식은
재배치를 고려하지 않고 설계 및 구현되었습니다.

이후 ASLR이 도입 후, 실행 파일도 무작위 주소에 매핑되게 하기 위해 이전에 있는
실행 파일의 형식도 변경하면 호환성 문제가 발생할 수 있기에
원래 재배치가 가능한 공유 오프젝트를 실행 파일로 사용하기로 했습니다.

실제로 리눅스의 기본 실행 파일 중 하나인 /bin/sh는 공유 오브젝트 형식을 띄고 있습니다.

dynamically가 shared object랍니다.

---

 PIE on ASLR

PIE는 재배치가 가능하므로, ASLR이 적용된 시스템에선 실행 파일도 무작위 주소에 적재됩니다.
위에 add.c 를 사용하여 이번엔 PIE를 적용한 컴파일을 하고 실행해봅시다!

참고로 현대의 gcc는 PIE가 기본적으로 적용하므로 이전에 걸었던 모든옵션을 제거한다면..
PIE가 적용되며, 실행하면 main함수의 주소가 매 실행마다 바뀌고 있습니다

---

PIE 우회

code base found

ASLR 환경에서 PIE가 적용된 바이너리는 실행될 때 마다 다른 주소에 적재됩니다.
그래서 코드 영역의 가젯을 사용하거나, 데이터 영역에 접근할려면
바이너리가 적재된 주소를 알아야 합니다.

이 주소를 PIE 베이스, 또는 코드 베이스라고 부르며, 구할려면 libc의 베이스 주소를 구할 때처럼
코드 영역의 임의 주소를 읽고, 그 주소에서 오프셋을 빼야합니다.
이 과정은 아래 링크에서 쉽게 다시 실습할 수 있으므로 설명은 넘어가겠습니다.

Exploit Tech: Return Oriented Programming

---

Partial Overwrite

 반환 주소의 일부 바이트만 덮는 공격

일반적으로 함수의 반환 주소는 호출 함수(Caller)의 내부를 가리킵니다.
특정 함수의 호출 관계는 정적 분석 또는 동적 분석을 쉽게 확인하며,
이를 통해 공격자는 반환 주소를 예측할 수 있습니다.

ASLR의 특성 상, 코드 영역의 주소도 하위 12비트 값은 항상 같습니다.
따라서 사용하는 코드 가젯의 주소가 ret와 하위 한 바이트만 다르면, 이 값만 덮어 조작 가능합니다.
그러나 만약 두 바이트 이상이 다른 주소로 실행 흐름을 옮기고자 하면 brute force이 요구되죠

---

마무리

PIE는 자체적인 보호 기법은 아니지만 ASLR과 맞물려 시스템을 한 층 더 안전한 보호 효과로써,
이를 우회하려면 코드 베이스를 구하거나 Partial Overwrite의 방식이 존재합니다.

• 상대 참조(Relative Addressing)
  : 어떤 값을 기준으로 다른 주소를 지정하는 방식
• Position Independent Code(PIC)
  : 어떤 주소에 매핑되어도 실행 가능한 코드
  - 절대 주소 사용 X
  - 일반적으론 rip를 기준으로 상대 주소를 사용함
• Partial Overwrite
  : 어떤 값을 일부분만 덮는 공격 기법
  - PIE를 우회하기 위해 사용되기도 함

---

참고 자료

 

 

참고 이미지