ELF Memory Protection - RELRO

codegate 2013 문제를 풀이하려고 보호기법을 확인해 보니 partial RELRO가 걸려있었다.

이 보호기법에 대해 공부를 해본적이 없어서 정리를 해본다.

---

먼저 RELRO를 이해하기 위해 배경지식이 필요한데

Lazy Binding 이라는 개념에 대해 정리를 하겠다.

Lazy Binding 이란?

-> 모든 외부 함수의 주소를 한 번에 로딩하지 않고, 함수 호출 시점에 해당 함수의 주소만 공유 라이브러리로부터 알아오는 것을 의미한다.

Dynamic Linking 방식으로 컴파일된 ELF 바이너리는 공유 라이브러리 내에 위치한 함수의 주소를 동적으로 알아오기 위해 GOT(Global Offset Table)를 이용한다.

Dynamic Link 방식은 공유 라이브러리를 하나의 메모리 공간에 매핑하고 여러 프로그램에서 공유하여 사용하는 방식이다.

실행파일 내에 라이브러리 코드를 포함하지 않으므로 PLT와 GOT를 사용하게 되는 이유이기도 하다.

PLT 와 GOT를 이용하여 공유 라이브러리 내의 함수 주소를 알아오는 과정을 요약하면 이러하다.

.plt 영역의 .got를 참조 -> .got내의 주소 값으로 jmp => 다시 plt로 이동하게 됨 -> dl_runtime_resolve()로 분기 -> _dl_fixup()에서 got에 함수 주소를 넣어줌

▶ 어떤 함수의 호출이 처음일 때는 위와 같은 과정을 거치고, 처음이 아닐때는 GOT에 그 함수의 주소가 적혀있어 그 함수의 주소를 알아오는 과정 없이 바로 함수를 호출한다.

---

RELRO 란?

-> Relocation Read-Only의 줄임말로 ELF 바이너라 or 프로세스의 데이터 섹션을 보호하는 기술이다.

즉, 메모리가 변경되는 것을 보호하는 기법이다.

바이너리 컴파일 시 Full - RELRO 옵션을 주면

.ctor , .dtors , .jrc , .dynamic, .got section이 읽기 전용상태가 된다. (Read-Only)

No RELRO는 RELRO 기법을 적용하지 않는다는것이니 넘어가고

Partial RELRO 와 Full RELRO의 차이에 대해 알아보자

---

구분	Partial RELRO	Full RELRO
GOT	writable	Read-Only
특징	함수 호출 시 해당 함수의 주소를 알아옴	ELF 실행 시 GOT에 모든 라이브러리 주소 바인딩

이런 차이가 있다.

GOT는 특이하게도 partial RELRO 와 Full RELRO일때 차이가 있는데

이외에 다른 섹션은 partial 이나 full 이나 동일하다.

---

좀 더 자세하게 알아보자.

[No RELRO]

먼저 No RELRO 일때에는 간단하다.

.ctors, .dtors, .jcr, .dynamic, .got 섹션에 데이터를 쓸 수 있다.

[Partial RELRO]

위 섹션에 모두 데이터 쓰기를 했을때 segmentation fault이 발생하는데

원인은 바로 write 권한이 없기 때문이다.

하지만 .got 섹션은 위 4개의 섹션과는 다르게 write 권한이 주어진다.

만약 .got 섹션에 데이터를 넣었을 때 segmentation fault가 발생한다면

원인은 해당 got에 저장되어있는 값을 가진 주소가 없기 때문이다.

[Full RELRO]

모든 세션에 읽기 권한만 있기 때문에 쓰기를 시도한다면 segmentation fault 가 발생할 것이다.

got도 마찬가지다.

따라서 Full RELRO가 적용된 바이너리는 GOT Overwrite가 불가능하다.

---

Full RELRO가 이 처럼 보안상 더 안전할 것 같은데 Partial RELRO가 더 많이 사용되는 이유는 Full RELRO의 경우 프로세스가 시작될 때

링커에 의해 모든 메모리에 대해 재배치 작업이 일어나기 때문에 실행이 느려지기 때문이다.