tmxklab

Linux Memory Protection 본문

Security/01 System Hacking

Linux Memory Protection

tmxk4221 2020. 9. 15. 17:12

checksec스크립트나 peda-gdb, pwndbg를 이용하면 mitigation확인할 수 있음

 

1. ASLR(Address Space Layout Randomization)

메모리 상의 공격을 어렵게 하기 위해 스택이나 힙, 라이브러리 등의 주소를 랜덤으로 프로세스 주소 공간에 배치함으로써 실행할 때마다 데이터의 주소가 바뀌게 하는 기법

 

현재 실행되고 있는 프로세스 주소 매핑 확인

cat /proc/self/maps 

→ 주소가 랜덤하게 바뀌는 것 확인

 

ASLR 활성화 및 비활성화

echo [0, 1, 2] > /proc/sys/kernel/randomize_va_space

[0] : ASLR 비활성화

[1] : 랜덤 Stack, Library 활성화

[2] : 랜덤 Stack, Library, Heap 활성화

 


2. NX(Never eXecute bit), DEP(Data Execution Prevention)

데이터 영역에서 코드가 실행되는 것을 방지하는 기법으로 스택이나 힙에서 실행 권한을 없애 쉘 코드 실행을 막아주는 기법이다. 윈도우에서는 DEP라고 부르고 리눅스에서는 NX bit라고 불러서 결국 둘 다 동일한 말

 

NX 비활성화 옵션

gcc -z execstack 

 


3. Stack Canary

함수 진입 시 스택에 SFP와 return address값을 저장할 때, 이 값을 공격자로부터 덮어씌워지는 것을 보호하기 위해 스택 상의 변수들의 공간과 SFP사이에 특정한 값을 추가하는데 이 값을 Canary라고 부른다. 함수가 종료할 시점에 Canary값의 변조 유무로 bof를 탐지할 수 있으며 변조 시 프로그램이 종료된다. 보통 SFP앞에 카나리 있음.

 

Canary 종류

  • Terminator Canary : NULL(0x00), CR(0x0d), LF(0x0a), EOF(0xff)와 같은 Terminator 문자를 포함시키는 Canary로 종료 문자들 때문에 Canary값을 알고 있어도 똑같이 작성하여 공격이 불가능
  • Random Canary : Canary값이 랜덤으로 계속해서 생성하는 방법
  • Radom XOR Canary : Canary값을 모든 제어 데이터 또는 일부를 사용해 XOR-scramble하여 생성

canary 활성화 및 비활성화 옵션

[비활성화]
gcc -fno-stack-protector

[활성화]
gcc -fstack-protector-all

 


4. RELRO(Relocation Read-Only)

GOT Overwrite와 같은 공격에 대비해 ELF 바이너리 또는 프로세스의 데이터 섹션을 보호하는 기법이다. 바이너리 컴파일 시 Full-RELRO 옵션을 주면 .ctors, .dtors, .jcr, .dynamic, .got섹션이 Read-Only가 됨 → GOT Overwrite 불가능

 

Lazy Binding(Lazy Linking, on-demand symbol resolution)

모든 함수의 주소를 한 번에 로딩하지 않고 함수를 처음 호출한 시점에 공유 라이브러리에서 해당 함수의 주소를 알아오는 것을 Lazy Binding이라고 한다.

 

Now Binding

프로그램이 실행될 때 해당 프로그램에서 사용하는 모든 함수들의 주소를 읽어와 got영역에 저장

 

추가 설명)

Dynamic Linking 방식으로 컴파일된 바이너리에서 라이브러리 함수를 호출할 때 실제 함수의 주소를 모르기 때문에 동적으로 알아오기 위해 plt, got를 이용한다. 처음 함수를 호출할 때는 plt영역의 got를 참조하고 뭐 여러가지 과정을 거치고 dl_runtime_resolve()로 가서 dl_fixup()에서 드디어 실제 함수의 주소를 got에 넣어준다. 이후에 다시 함수를 호출할 때는 위와 같은 복잡한 과정을 거치지 않고 걍 got에 있는 함수를 호출한다.

 

[No-RELRO]

 

[Partial-RELRO]

 

[Full-RELRO]

 

추가 설명)

Full RELRO를 사용하면 GOT가 Read-Only인 상태여서 Partial RELRO보다 보안상 더 안전할 것 같은데 Full RELRO보다 Partial RELRO가 더 널리 사용되는 이유는 Full RELRO의 경우 프로세스가 시작될 때 링커에 의해 모든 메모리에 대해 재배치 작업이 일어나 실행이 느려지기 때문이다.

 


5. PIE(Position Independent Executable)

PIE는 위치 독립 코드로 이루어진 실행 가능한 바이너리이며 바이너리 주소가 상대적인 주소로 랜덤하게 매핑시키는 기법이다. 모든 심볼을 상대주소로 작성하므로 Base Address가 달라지게 함으로써 모든 심볼 주소가 실행할 때마다 달라져 ASLR과 같은 효과를 가질 수 있다.(Base Address + Relative offset, 참고로 Base Address는 매번 변경되지만 offset은 동일)

 

참고로 PIE는 OS의 ASLR기능에 의존하므로 OS의 ASLR이 dsiable되어 잇으면 randomize 불가하며 더 구체적으로는 OS loader의 영향을 받는다.

 

PIE 활성화 및 비활성화 옵션

[비활성화]
gcc -no-pie

[활성화]
gcc -fPIE -pie

 


6. ASCII-Armor

RTL공격에 대응하기 위한 방법으로 공유 라이브러리 영역의 상위 주소에 0x00을 포함시킨다. ASCII-Armor가 적용되면 라이브러리를 공유 라이브러리 영역에 할당하지 않고 텍스트 영역의 16MB아래의 주소에 할당된다. 따라서 라이브러리 영역의 주소 최상위 1byte가 NULL로 인식된다. bof공격을 위해 string관련 함수(strcpy, strcat, ...)를 사용하게 되면 문자열을 읽다가 NULL값이 나오면 중지되므로 라이브러리 함수를 호출하는 그 때 최상위 1byte가 NULL값이므로 동작이 끝나 버린다.

→ GOT Overwrite로 우회 쌉가능

 

 


Reference)

 

02.Protection Tech - TechNote - Lazenca.0x0

페이지 TechNote 02.TechNote 배너의 맨 끝으로 배너의 맨 처음으로 02.Protection Tech 메타 데이터의 끝으로 건너뛰기 Lazenca.0x0님이 작성, 10월 13, 2019에 최종 변경 메타 데이터의 시작으로 이동

 

 

Linux 환경에서의 메모리 보호기법을 알아보자

Researcher salen salen의 다른 글 더 보기 CONTENTS Linux 환경에서의 메모리 보호기법을 알아보자 1 ASLR, NX, ASCII-Armor, Stack canary 에 대해 알아보자 :) Linux 환경에서의 메모리 보호기법을 알아보자 2 RELRO에

bpsecblog.wordpress.com

 

'Security > 01 System Hacking' 카테고리의 다른 글

RTC(Return to csu)  (0) 2020.09.15
FSOP(File Stream Oriented Programming)  (0) 2020.09.15
FSOP를 위한 fclose()분석  (0) 2020.09.15
stdout flag를 이용한 libc leak  (6) 2020.08.26
heap(5) - tcache 정리  (0) 2020.08.24
Comments