Stack Canary

여태까지는 단순 stack buffer overflow를 다뤘다면

이제는 canary가 추가됐을 때를 볼 거다.

 

 

런타임일 때마다 canary 검사 실행

 

 

TLS란 그냥

 

TLS 주소는 fs register가 가지고 있다.

fs가 가리키고 있는 주소값을 알면, TLS 주소를 알 수 있다.

TLS에서 0x28만큼 떨어진 주소에 canary가 위치한다.

따라서 TLS 주소만 알고 있다면, canary 값을 획득하고 변조할 수도 있다.

 

 

 

RSI: fs가 가리키게 될 값

RDI: ARCH_SET_

 

 

Stack Canary 우회 방법

 

Brute Force

: 무차별 대입

 

TLS 접근

: TLS에 저장된 카나리값 변조

 

Stack Canary Leak

: 카나리를 유출시켜

:

 

Return to Shellcode

 

문제 코드

 

canary 존재한다.

 

컴파일해주고 실행해줬더니

buf의 시작 주소: 0xffffc2600d48

buf~RBP 사이 거리: -24로 나온다... 뭐가 문젤까

 

취약점

 

buf 크기는 0x50인데 name은 0x100만큼 입력받으므로 BOF 발생

=> buf~canary 사이를 임의의 값으로 채워 buf 출력 시 canary값도 출력되도록 할 수 있음

 

leak+exploit 코드

 

 

왜이러냐

 

 

 

1. 반환 주소를 임의로 덮을 수 있음

2. 데이터 입력할 수 있는 버퍼의 주소를 알 수 있었음

3. 해당 주소의 버퍼가 실행 가능함 ...의 조건을 만족했기 때문에 셸 코드 실행이 가능했다

공격자의 침입을 어렵게 하기 위해:

1. 메모리에서 임의의 버퍼 주소를 알기 어렵게 하기

2. 메모리 영역에서 불필요한 실행 권한 제거

ssp_001

stack에 canary가 존재하는 것을 확인할 수 있다.

 

문제 코드

 

취약점

 

run 했을 때

 

1. print_box() 함수

다음과 같이 print_box 선택해

box[] 길이를 검증하지 않고 인덱스를 받아오기 때문에 box[] 아래 메모리값을 읽어올 수 있다.

 

2. name size

main에서 name 길이를 0x40으로 지정한 반면 name size를 다시 입력받기 때문에 BOF 발생

 

=> P에서 cunury를 leak시킨 다음,

E에서 RET, 즉 main함수 반환 주소를 get_shell()함수로 덮어씌우면 될 것이다.

 

 

디버깅

 

스택 구조는 다음과 같다고 추측 가능하다.