시스템 보안 정리

프로그램 로드

섹션은 어떻게 실제 메모리에 매핑되는가?

페이징, 페이지드 세그멘테이션

ELF

Executable and Linkable Format

실행 가능하거나, 링크할 수 있는 파일들의 사전 정의된 구조(Format)

ex) .o, .so, .out(실행파일)

ELF 구조

프로그램은 메모리에 올라가기 전, 디스크에 있는 바이너리를 말함.

(참고) 섹션 vs 세그먼트

프로그램의 영역 구분 - 섹션 → 잘게 쪼개져있음
프로세스의 영역 구분 - 세그먼트 → 4개(큰 단위) — 프로그램의 영역 구분 - 섹션 → 잘게 쪼개져있음 프로세스의 영역 구분 - 세그먼트 → 4개(큰 단위)

링킹하는 관점이냐?, 실행하는 관점이냐? 에 따라 이름이 다름.

→ 따라서 ‘readelf 를 한다’ → 단위는 ‘섹션’ → readelf -S

프로세스 ELF 구조 (Segments)

ELF 헤더

타입 - 얘가 EXEC(.out)인지, REL(.o, .a)인지, DYN(.so)인지…

.text

사용자 작성 부분이 컴파일(.c→.o→asm→0101010)되어 담김

.rodata

문자열 등 상수

.data

‘초기화 된’ 전역 변수, 정적 변수

💡

정적 변수가 왜 data에 담김?

static int a = 123;은 .data에 담기는가?

그렇다. 함수 호출을 반복해도 유지해야 하기 때문이다. (전역변수와 생명주기가 비슷)

.bss (’Block Started by’ Symbol)

‘초기화 되지 않은’ 전역 변수, 정적 변수

💡

.data와 .bss의 분리 기준

‘프로그램이 0으로 초기화를 하고 시작해야 하는가?’ 가 기준.

bss영역은 프로그램이 시작할 때 초기화하고 시작함.

.symtab

심볼 테이블: 함수, 변수의 심볼을 심볼 이름(str)과 매핑할 수 있는 정보가 있음

num: 일종의 id인듯?
value: 실제 함수가 있는 주소

.strtab

스트링 테이블: 함수 이름이 있는 테이블

💡

1, 9, e는 뭐예요?

0x1부터 다음 null까지 → “hello.c\0” (+8 bytes)

0x9부터 다음 null까지 → “main\0” (+5 bytes)

0xE(014)부터 다음 null까지 → “puts\0” (+ 5bytes)

총 18 bytes → 0x13 bytes

제거(strip)

.symtab과 .strtab은 정적 링크가 완료된 이후에는 필요없는 내용.

따라서 공유 라이브러리나 실행 파일에서는 직접 제거하곤 한다.

참고

참고) 위와 같은 파일의 심볼 테이블 — 참고) 위와 같은 파일의 **심볼 테이블**

정의하기

정적 링킹 & 로딩이 무엇인가?

정적 링킹

= 심볼테이블 병합 및 재구성

링킹 시 참조 대상을 모두 resolve(symbol resolution) 후, 바이너리에 탑재.

정적 로딩

별거없고, 실행 시 메모리에 올림(로드)

동적 로딩 & 동적 링킹이 무엇인가?

정적 링킹 시 참조 대상의 링크 정보만을 탑재,

load-time에 필요한 라이브러리를 메모리에 로드 및 재배치,

실제 함수 호출시 다이나믹 링커가 라이브러리의 함수로 링크한다.

💡

링크 및 로드 과정

정적 링킹 →

(symbol resolution 과정을 통해) 바이너리에 함수 및 그 주소가 내장된다. (링킹)

결과적으로 .text 부분에 해당 함수 주소로 바로 점프하도록 박혀있어 함수 호출에 별도 symbol resolution이 필요없다.

ex) 정적 링킹을 한 경우, 다른 목적 파일 의 함수 기계어는 .text에, 정적 변수는 .data/.bss에 이미 내장되어있다.

정적 로딩 →

로드 시 메모리에 그대로 적재한다. (일부 section 제외)

동적 로딩 →

*여기서부터는 동적 링킹을 사용한 경우에만 해당한다.
(정적 링킹한다면, 이미 symbol resolution이 끝나있다)

(참고) ‘동적 링킹을 사용할 때’의 정적 링킹

정적 링킹 시에 함수를 특정할 수 있는 정보만 삽입

동적 링킹이 필요한 경우 정적 링킹 과정에서 심볼들이 삽입된다.

→ .dynsym, .dynstr에 symbol resolution을 위한 정보 삽입

(참고)

💡

부분 동적 링킹은 gcc의 기본 동작이다

gcc는 별도로 옵션 (-static)을 지정하지 않으면 동적 링킹 방식을 사용한다.

그러나 이 때에도 지정한 목적 파일 (gcc add.o sub.o)는 정적 링킹된다.

(공유 라이브러리 .so가 아니므로, 동적 로드가 불가하기 때문이다)

라이브러리 로드

커널이 .interp를 참고해 ld.so를 로드한다(프로세스 실행 과정의 일부)

참고

ld.so의 dl_start() → dl_map_object() n회 호출 (라이브러리 갯수만큼)

.dynamic 세그먼트를 참고해 .so 로드

참고

재배치

세그먼트(로드된 섹션)에서 Read-only 세그먼트 할당

ld.so의 dl_relocate_object() n회 호출 (라이브러리 갯수만큼)

동적 링킹(lazy-binding)

함수 호출 시 → 정적 링킹에서 삽입된 정보를 통해 함수 호출로 lazy binding한다.

이어서 함수 호출이 일어남.

두번째 호출 부터는 바인딩이 필요 없음

💡

정적 링킹을 명시한 경우 동적 링킹이 일어나지 않는다(gcc -static)

이미 symbol resolution이 종료되었기 때문이다.

→ libc.so 등 외부 라이브러리도 이미 정적 링킹되었다. (자동임)

동적 링킹 과정(Detailed)

위의 내용 중 동적 로딩은 완료되었다고 보고, 그 이후 동적 링킹이 실제로 어떻게 수행되는지 살펴본다.

동적 링킹이 완료되지 않은 경우(첫 실행)

💡

6/12 다시 간단 정리

함수 호출하면 먼저 .plt의 해당 함수 영역으로 감

해당 영역은 .got.plt를 참조해 점프하도록 함

그러나 첫 호출시 .got.plt에는 함수@.plt 아래의 [ reloc offset 푸시 + dl_runtime_resolve@.plt로 점프] 인스트럭션 부분 주소가 있음.

이걸 카운터 기준으로 정리하자면 함수@.plt에서 →(.got.plt 참조해서) 함수@.plt+6으로 갔다가 → .plt+0(dl_runtime_resolve@.plt)으로 갔다가 → (.got.plt 참조해서) 실제 라이브러리의 dl_runtime_resolve 호출함

그러면 dl_runtime_resolve는 .rel.plt 참고해서 .got.plt의 해당 함수 주소를 실제 라이브러리의 주소로 수정하겠죠?

그러면 마침내 링킹이 끝나고, dl_runtime_resolve에서 .got.plt의 바뀐 주소 참조해서 점프시킴

외부에서 보면 알아서 링킹하고 함수 실행까지 한 것으로 보이겠죠?