Mitigation: Stack Canary

---

스택 카나리(Stack Canary)

스택 버퍼 오버플로우로부터 반환 주소를 보호하는 기법

함수의 프롤로그에서 스택 버퍼와 반환 주소 사이에 임의의 값을 삽입하고, 함수의 에필로그에서
해당 값의 변조를 확인하는 보호 기법입니다. 카나리 값의 변조가 확인되면 프로세스 강제 종료!

 

BOF로 RET를 덮으려면 반드시 카나리를 먼저 덮어야하므로 카나리 값을 모르는 공격자는
반환 주소를 덮을 때 카나리 값을 변조하게 됩니다. 그러하다면 변조가 확인되어
공격자는 실행 흐름을 획득하지 못하게됩니다.

TMI. 카나리라는 이름의 유래

 카나리 보호 기법의 이름은 카나리아(Canary)라는 새에서 유래되었습니다. 19세기, 20세기에는 일산화탄소 농도의 측정 기술이 부족했고, 탄광에서 유출된 일산화탄소에 광부가 중독사하는 사건이 빈번하게 발생하였습니다. 그래서 광부들은 사람보다 일산화탄소의 농도에 민감하게 반응하는 카나리아와 함께 탄광에 들어갔습니다. 카나리아가 일산화탄소에 반응하기 시작하면 광부들은 일산화탄소의 농도가 위험 수준에 다다랐다고 판단하고 대피할 수 있었습니다.

 이런 역사적 배경으로 인해 카나리아는 “위험을 알려주는 새”라는 상징적 의미를 갖게 되었습니다. 소프트웨어를 출시하거나 업데이트할 때, 베타 테스트 용도로 공개하는 버전을 카나리 버전이라고 부르는 것도 이런 의미가 반영된 것입니다. 마찬가지로 카나리 보호 기법도 반환 주소가 덮인 것을 알려준다는 의미에서 “카나리”로 이름 붙여졌습니다

[잠깐과학]광부를 구한 생명의 지저귐 탄광의 카나리아

---

카나리 작동 원리

// Name: canary.c
 
#include <unistd.h>
 
int main() {
  char buf[8];
  read(0, buf, 32);
  return 0;
}

위 코드를 바탕으로 보호 기법의 적용에 대한 차이점과 특징을 알아봅시다!

---

카나리 비활성화

실습 환경인 Ubuntu 18.04의 gcc는 자동으로 스택 카나리를 적용하기에 컴파일 옵션으로
-fno-stack-protector 옵션을 추가해야 합니다.

쉽게 예상했던 거처럼 core file이 생성된 모습이죠
참고로 환경마다 경고문 띠우는 경우가 있는데 -w 사용하시면 무시할 수 있어요

 

자 그럼 segmentation fault를 띄웠으니까 분석은 좀 있다가 하고 다음으로는..

카나리 활성화

보시면.. Segmentation fault가 아니라 
stack smashing detected와 Aborted라는 에러가 발생해야 하는데..

 

칼리리눅스라서.. 그런가요? 공부를 할수록 의문만 늘어가는게.. 힘드네요ㅠ
쨋든 저 에러들을 분석하면 Stack BOF가 탐지되어 프로세스 강제 종료!라는 이야기

canary & no_canary

적용된 모습가 안된 모습의 차이가 이렇게 명확하게 보입니다
음.. 그럼 추가된 코드를 확인해볼까요

 

아.. 근데 참고로 kali는 canary가 적용이 안되더라고요..
그래서 위 명령어를 쳐서 보호 기법을 적용하였습니다.

gcc -fstack-protector canary.c

dreamhack Good!!

---

카나리 동적 분석

카나리 저장(canary보호기법 적용)

추가된 프롤로그의 코드에 중단점을 설정 후 바이너리를 실행

중단점(main+8)의 데이터를 읽어서 rax에 저장
fs는 세그먼트 레지스터의 일종으로, 리눅스는 프로세스가 시작될 때 fs:0x28에 랜덤 값으로 저장

 

따라서 중단점(main+8)의 결과로 rax에는 리눅스가 생성한 랜덤 값이 저장됨!!
근데 이 환경에선 커스텀마이징이 잘 안돼서.. 다시 칼리로

---

코드 실행 시 rax에 다음과 같이 첫 바이트가 null인 8byte 데이터가 저장됨

---

생성된 랜덤 값은 main+17에서 reb-0x8에 저장됨

---

🚨fs란?

 이전 정리 자료에서 CPU에는 다양한 세그먼트 레지스터를 알아봤습니다.
초기엔 세그먼트 레지스터로 code, data, extra(cs/ds/es)가 있습니다.
그런데 CPU개발자들은 여기에 두 개 더 추가하고 싶어서 이름 고민하다 알파벳 순서대로..


 이전 cs, ds, es는 CPU가 사용 목적을 명시한 레지스터인 반면, fs와 gs는 목적 지정 X
즉, OS가 임의대로 사용할 수 있는 레지스터입니다. 리눅스는 fs를 TLS를 가리키는 포인터!

Thread Local Storage(TLS)는 카나리 비롯한 프로세스 실행에 필요한 여러 데이터 저장
즉, 스레드별 저장공간..

---

카나리 검사

이제 추가된 에필로그의 코드에 중단점을 설정하고 바이너리를 계속 실행시킵니다.

 

여기서는 16개의 H를 입력으로 카나리를 변조하고, 실행 흐름이 어떻게 되는지 살펴보겠습니다.

main+50은 rbp-8에 저장한 카나리를 rcx로 옮깁니다.
그 뒤, main+54에서 rcx를 fs:0x28에 저장된 카나리와 xor두 값이 동일하면 연산 결과가 0이 되면서
je의 조건을 만족하게 되고, main함수는 정상적으로 반환됩니다.

그러나 두 값이 동일하지 않으면 __stack_chk_fail이 호출되면서 프로그램이 강제로 종료됩니다.

---

코드를 한 줄 실행시키면, rbp-0x8에 저장된 카나리 값이 버퍼 오버플로우로 인해
“0x4848484848484848”이 된 것을 확인할 수 있습니다.

 

근데 전 저렇게 안 나와서.. 대체 이미지로 넣을게요 수정은 귀찮아서 ㅎ
밑에 이미지도 비슷한 이유로 대체 이미지로.. ㅠ

---

main+54의 연산 결과가 0이 아니므로 main+63에서 main+70으로 분기하지 않고 
main+65의 __stack_chk_fail을 실행하게 됩니다.

---

이 함수를 실행하면 다음과 같은 메시지를 출력합니다.

---

카나리 생성 과정🔬

카나리 값은 프로세스가 시작될 때, TLS에 전역 변수로 저장되고, 각 함수마다
프롤로그와 에필로그에서 이 값을 참조하며, 좀 깊이 들어가 TLS에 카나리 값 저장을 알아보죠

• 프롤로그 : 함수가 호출 시, 스택 프레임을 설정하는 과정
• 에필로그 : 스택 프레임을 소멸시키는 과정, leave 명령어와 ret 명령어를 사용함

---

TLS 주소 파악

fs는 TLS를 가리키므로 fs의 값을 알면 TLS의 주소를 알 수 있음
그러나 리눅스에서 fs의 값은 특정 시스템 콜을 사용해야 한 조회나 설정이 가능하죠
gdb에서 다른 레지스터의 값을 출력하듯 info register fs나 print $fs와 같은 방식은 안됨!

그래서 여기선 fs의 값을 설정할 때 호출되는 arch_prctl(int code, unsigned long addr)
시스템 콜에 중단점을 설정하여 fs가 어떤 값을 설정되는지 조사합시다.
이 시스템 콜을 arch_prctl(ARCH_SET_FS, addr)의 형태로 호출하면 fs의 값은 addr로 설정됨!

참고로 arch_prctl에 대하여 자세히 알고 싶으면 여기로

catch : gdb에 특정 이벤트가 발생 시, 프로세스를 중지시키는 명령어

 

이 명령어로 arch_prctl에 catchpoint를 설정하고 실습에 사용했던 canary를 실행합시다

---

catchpoint에 도달했을 때, rdi의 값이 0x1002인데 이 값은 ARCH_SET_FS의 상숫값이죠
rsi의 값이 0x7ffff7fb1580이므로, 이 프로세스는 TLS 0x7ffff7fb1580에 저장 → fs에 가리킴

카나리가 저장될 fs+0x28(0x7ffff7fb1580+0x28)의 값을 보면, 아직 어떤 값도 설정이 안되어있네요 

---

카나리 값 설정🛠

watch : 특정 주소에 저장된 값이 변경되면 프로세스를 중단시키는 명령어

TLS의 주소를 알았으므로, gdb의 watch 명령어로 TLS+0x28에 값을 쓸 때 프로세스를 중단하죠

---

watchpoint를 설정하고 프로세스를 계속 진행시키면 Security_init함수에서 프로세스가 멈춰요
근데 저는 Security_init함수가 안 보이네요 저거 Contiune 한번 더 한 건데도..

---

여기서 TLS+0x28의 값을 조회하면 0xe15de3b266156800 이 카나리로 설정된 걸 확인했죠

실제로 이 값이 main함수에 사용되는 카나리값이지 확인 해볼까요?

---

mov rax,QWORD PTR fs:0x28를 실행하고 rax 값을 확인해보면
security_init에서 설정한 값과 같은 것을 확인할 수 있습니다!!

---

카나리 우회

카나리가 등장하면 당연히 우회 방법도 연구를 했겠죠 우회 방법은 아래와 같습니다.

무차별 대입(Brute Force)

 x64 아키텍처에서는 8바이트의 카나리가 생성되며, x86 아키텍처에서는 4바이트의 카나리가 생성됩니다. 각각의 카나리에는 NULL 바이트가 포함되어 있으므로, 실제로는 7바이트와 3바이트의 랜덤한 값이 포함됩니다.

 즉, 무차별 대입으로 x64 아키텍처의 카나리 값을 알아내려면 최대 256^7번, x86 에서는 최대 256^3 번의 연산이 필요합니다. 연산량이 많아서 x64 아키텍처의 카나리는 무차별 대입으로 알아내는 것 자체가 현실적으로 어려우며, x86 아키텍처는 구할 순 있지만, 실제 서버를 대상으로 저정도 횟수의 무차별 대입을 시도하는 것은 불가능합니다.

 

TLS 접근

 카나리는 TLS에 전역변수로 저장되며, 매 함수마다 이를 참조해서 사용합니다. TLS의 주소는 매 실행마다 바뀌지만 만약 실행중에 TLS의 주소를 알 수 있고, 임의 주소에 대한 읽기 또는 쓰기가 가능하다면 TLS에 설정된 카나리 값을 읽거나, 이를 임의의 값으로 조작할 수 있습니다.

 그 뒤, 스택 버퍼 오버플로우를 수행할 때 알아낸 카나리 값 또는 조작한 카나리 값으로 스택 카나리를 덮으면 함수의 에필로그에 있는 카나리 검사를 우회할 수 있습니다.

---

스택 카나리 릭

스택 카나리를 읽을 수 있는 취약점이 있다면, 이를 이용해 카나리 검사 우회 가능!!

// Name: bypass_canary.c
// Compile: gcc -o bypass_canary bypass_canary.c
 
#include <stdio.h>
#include <unistd.h>
 
int main() {
  char memo[8];
  char name[8];
 
  printf("name : ");
  read(0, name, 64);
  printf("hello %s\n", name);
 
  printf("memo : ");
  read(0, memo, 64);
  printf("memo %s\n", memo);
  return 0;
}

첫번째 입력에서 BOF를 시켜서 카나리의 값을 얻어내고,
BOF의 값이 카나리값이 릭이 되고, 얻어낸 값을 활용해 검사를 우회함

스택 카나리 취약점 활용 모습

직접 또 이 코드를 보며, 분석할 수 있지만.. 너무 힘들어요 ㅠ
어짜피 문제 풀면서 또 할거 오늘은 여기까지!!

---

코스 요약 📝

 

카나리

함수 시작 시 스택 버퍼와 Return Address 사이에 랜덤 값을 삽입한 후 함수 종료 시
해당 랜덤 값의 변조 여부를 확인하여 메모리 오염 여부를 확인하는 보호 기법

카나리 생성

security_init함수에서 TLB에 랜덤 값으로 카나리를 설정하면, 매 함수에서 이를 참조하여 사용

카나리 우회 기법

• 무차별 대입 공격(Brute Force Attack):
   - 무차별 대입으로 카나리 값을 구하는 방법. 현실적으로 불가능에 가깝습니다.
• TLS 접근:
   - 카나리는 TLS에 전역 변수로 저장되므로, 이 값을 읽거나 조작할 수 있으면 카나리를 우회
• 스택 카나리 릭:
  - 함수의 프롤로그에서 스택에 카나리 값을 저장하므로, 이를 읽어낼 수 있으면 카나리를 우회
  - 가장 현실적인 카나리 우회 기법입니다.

---

참고 자료

Mitigation: Stack Canary

[잠깐과학]광부를 구한 생명의 지저귐 탄광의 카나리아

Thread-local storage - Wikipedia

 

Thread Local Storage

 

참고 이미지

Mitigation: Stack Canary

스레드 로컬 스토리지 - Win32 apps