Background: RELRO

---

RELRO(RELocation Read-Only)

등장배경

- ELF는 GOT를 활용해 반복되는 lib의 함수의 호출 비용 ↓
- GOT의 값을 채우는 방식은 여러가지 그중에 우린 Lazy Binding으로 취약점 우회
: 함수가 처음 호출될 때 함수의 주소를 구하고, 이를 GOT적는 방식
- Lazy binding 하는 바이너리는 실행 중 계속 업데이트를 해야해 GOT에 쓰기 ○
: RTL, Chain RTL, ROP로 이어짐

또한 ELF의 데이터 세그먼트에는 프로세스의 초기화 및 종료와 관련된
.init_array .fini_array 로써, 이 영역들은 프로세스의 시작과 종료에 실행할 함수들의 주소 저장
여기에 공격자가 임의로 값을 쓸 수 있다면, 프로세스의 실행 흐름이 조작될 수 있습니다.

이를 방지하고자, 프로세스의 데이터 세그먼트를 보호하는 RELRO을 개발하였습니다.
RELRO는 쓰기 권한이 불필요한 데이터 세그먼트에 쓰기 권한을 제거합니다(영문 그대로죠)

RELRO는 적용 범위에 따라  3가지로 구별됩니다.

No RELRO

• ELF 기본헤더, 코드영역를 제외한 거의 모든 부분에 RW 권한 부여

Ex) 이전까지의 활동들에서 다 No RELRO로 걸려있는 모습을 생각하시면 됩니다.
$ gcc -o ./code ./code.c -z norelro

Partial RELRO

• No RELRO와 매우 비슷하나 _DYNAMIC 섹션에 쓰기 권한 X

$ gcc -o ./partial_relro partial_relro.c -W -z relro

full relro

• bss 영역을 제외한 모든 부분에서 write 권한을 없어짐

$ gcc -o ./full_relro full_relro.c -W -z relro -z now

---

Partial RELRO

Full과 Partial의 차이를 확인하기 우해 아래의 예제 코드를 사용하겠습니다.
예제는 자신의 메모리 맵을 출력하는 바이너리의 소스 코드입니다.

참고로 저는 -fno-PIE의 명령어가 안 먹어서 대체로 -z relro로 하였습니다.

// Name: relro.c
// Compile: gcc -o prelro relro.c -no-pie -fno-PIE
 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
int main() {
  FILE *fp;
  char ch;
 
  fp = fopen("/proc/self/maps", "r");
 
  while (1) {
    ch = fgetc(fp);
    if (ch == EOF) break;
    putchar(ch);
  }  return 0;
}

Full로 하고 싶으면 보호 기법을 사용하지 않고 해도 되곘죠
저는 Kali라서 안되는 경우가 가끔 있는데.. 상황에 맞추어 컴파일 해줍시다.

---

Partial RELRO 권한

실행하면, 0x601000부터 ...20000까지의 주소에는 쓰기 권한이 있는 것을 확인할 수 있습니다.
.init_array와 .fini_array는 각각 0x600e10과 0x600e18에 할당되어 쓰기가 불가능

그러나 아래 부분을 참조해보면 해당 영역에는 .got.plt, .data, .bss가 할당되어 있습니다.
따라서 이 섹션들에는 쓰기가 가능합니다.(해당 wirte의 권한이 있는 주소에 있기에)

💡.got와 got.plt

- Partial PELRO가 적용된 바이너리는 got와 관련 섹션이 .got와 .got.plt로 두 개가 존재

- 전역 변수 중에서 실행되는 시점에 바인딩(now binding)되는 변수는 .got에 위치함
: 바이너리가 실행될 때는 이미 바인딩이 완료되어있으므로 이 영역에 쓰기 권한 X

- 실행 중에 바인딩(lazy binding)되는 변수는 .got.pit에 위치함
- 실행 중에 값이 써져야 하므로 쓰기 권한이 부여됨
: Partial RELRO가 적용된 바이너리에서 대부분 함수들의 GOT 엔트리 위와 같이 저장

---

※이해하면 좋은 용어

바인딩(Binding)

• 프로그램에 사용된 구성 요소의 실제 값 또는 프로퍼티를 결정짓는 행위를 의미
• 함수를 호출하는 부분에서 실제 함수가 위치한 메모리를 연결하는 것도 바로 바인딩

GOT(Global Offset Table)

• GOT 엔트리 주소라고도 지칭됨
• ELF(구현을 위한 lib 모음) 파일의 고정된 위치에 있음
  - 결과적으로 모든 실행 프로세스 이미지들에게 공통적인 주소에 있게 됨

---

Full RELRO

이번엔 제거하고 넣어봅시다

실행하고 메모리 맵을 확인 이를 섹션 헤더 정보와 종합하면..
got에는 쓰기 권한이 제거되며, data와 bss에만 쓰기 권한이 있습니다.

Full RELRO가 적용되면 라이브러리 함수들의 주소가 바이너리의 로딩 시점으로 모두 바인딩
따라서 GOT에는 쓰기 권한이 부여 X

---

RELRO 기법 우회

Partial PELRO, Full RELRO의 적용 방식과 효과를 확인해 봤습니다.
Partial RELRO의 경우는 .init_array와 .fini_array 대한 쓰기권한이 제거로 두 영역을 덮는건 힘듬
하지만, .got.plt 영역에 대한 쓰기 권한이 존재하므로 GOT overwrite 공격을 활용

Full RELRO의 경우, .init_array .fini_array 뿐만 아니라 .got 영역에도 쓰기 권한이 제거되었습니다.
그래서 공격자들은 덮어쓸 수 있는 다른 함수 포인터를 찾다가 lib에 위치한 hook를 찾아냈습니다.
라이브러리 함수의 대표적인 hook이 malloc hook과 free hook입니다.

원래 이 함수 포인터는 동적 메모리의 할당과 해제 과정에서 발생하는 버그를 디버깅하기 쉽게 만듬
그러나 현재 우리에게는 hook을 이용하여 hooking 하여 exploit을 할 수 있게 됩니다.

malloc 함수의 코드를 살펴보면, 함수 시작 부분에서 __malloc_hook이 존재 여부 검사 및 호출
__malloc_hook은 libc.so에서 쓰기 가능한 영역에 위치합니다.

따라서 공격자는 libc가 매핑된 주소를 알 때, 이 변수를 조작해 malloc을 호출, 실행 흐름 조작 가능!
이와 같은 공격 기법을 통틀어 Hook Overwrite라고 부릅니다.

---

마무리

Hook : 함수 호출, 이벤트 또는 메시지 등을 처리하는 코드
Hooking : OS나 SW 등 각종 프로그램의 구성 요소 간의 발생하는 Hook 변조

• RELocation Read-Only(RELRO)
  : 불필요한 데이터 영역에 쓰기 권한 제거
• Partial RELRO
  : init array, fini array 등 여러 섹션에 쓰기 권한 제거
  -  _DYNAMIC 섹션에 쓰기 권한 X
  - Lazy binding을 사용하므로 libc func들의 GOT EP(Entry Pointer)는 쓰기 가능
  - GOT Overwrite 등의 공격으로 우회 가능
• Full RELRO
  : Partial RELRO 뿐만 아닌 GOT에 쓰기 권한 제거
  - now binding을 사용하여 libc func들의 주소는 바이너리가 로드되는 시점에 바인딩됨
  - libc의 malloc hook, free hook과 같은 함수 포인터를 조작하는 공격으로 우회 가능

•  

---

참고 자료

Background: RELRO

 

RELRO를 파헤치자 1!

 

참고 이미지

 

Move free icons designed by Freepik