[!시간낭비 주의] ELF Memory Protection DEP

참고 : https://bpsecblog.wordpress.com/2016/05/16/memory_protect_linux_1/

DEP란?

Data Execution Prevention의 약자로 데이터 영역에서 코드가 실행되는 것을 막는 메모리 보호 기법이다.

예를 들어 bof 취약점이 있는 프로그램을 exploit 하기 위해 return address를 쉘코드의 주소로 변조하였다고 하면

DEP가 걸려 있지 않은 경우라면 바로 쉘코드가 실행되겠지만

DEP가 걸려있는 경우라면 실행권한이 없기 때문에 쉘코드를 실행하지 않고 프로그램에 대한 예외처리 후 종료된다.

실습을 하기 위해 프로그램 하나를 만들었다.

[DEP_Check.c]

gets()의 사용으로 인해 bof 공격이 가능한 프로그램이다.

스택에서 str[256]만큼 저장을 하고, 배열의 주소를 출력해준다.

환경 구성을 위해 ASLR을 꺼줬다.

ASLR 해제 : echo 0 > /proc/sys/kernel/randomize_va_space

또한 32bit로 컴파일하고, 각종 메모리 보호기법을 꺼주었다.

---

[컴파일 옵션]

32bit 컴파일 : -m32

(-m32 옵션이 먹지 않을때 : sudo apt install gcc-multilib)

32비트 컴파일 했을때 main함수에 스택을 정렬하는 인스트럭션 지우기 : -mpreferred-stack-boundary=2

CANARY 제거 : -fno-stack-protector

스택에 실행 권한 주기 : -z execstack

No RELRO가 기본 값일때 Partial RELRO가 필요하다면 : -z relro

No RELRO가 기본값일때 Partial RELRO가 필요하다면 : -z relro

Partial RELRO가 기본값일때 No RELRO가 필요하다면 : -z norelro

이런 옵션으로 컴파일했다.

---

32비트로 잘 컴파일이 되었다.

또한 DEP를 포함한 각종 메모리 보호 기법이 꺼져있는 상태임을 확인할 수 있다.

NX부분을 보면 DEP가 해제된것을 알 수 있고,

컴파일할때 -z execstack으로 스택에 실행 권한을 설정했으므로 그 점도 확인하기 위해 cat /proc/PID/maps 로 확인을 해야한다.

여기서 PID확인 하느라 시간좀 버렸는데

gdb로 간단히 확인 할 수 있었다.

gdb로 해당 파일을 열고(여기선 DEP_Check) start 명령으로 main()에 임시 중단점을 설정하여

gdb내에서 실행을 한 후 shell ps로 PID를 확인 할 수 있었다.

그리고

cat /proc/9259/maps 로 stack에 실행권한이 주어졌는지 확인 해보면 역시 스택에 실행권한이 주어진것이 보인다.

이제 bof 공격을 해보면..!

안되네요..죄송합니다