ELF Memory Protection - DEP/NX

DEP란?

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

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

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

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

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

[DEP_test.c]

간단히 bof 취약점이 존재하는 프로그램이다.

gets() 에 의해 bof가 발생된다.

먼저 모든 메모리 보호기법을 꺼놓고 bof 공격을 해봤다.

컴파일 옵션은 이러하다.

gcc -o DEP_test DEP_test.c -mpreferred-stack-boundary=2  -fno-stack-protector -z execstack -z norelro

-z execstack으로 스택영역에서 실행권한을 주었다.

DEP/NX를 해제한다는 의미이다.

checksec으로 확인해보면 컴파일이 아주 잘된것을 확인할 수 있었다.

NX부분에도 NX disabled 라고 해제되었음을 알 수 있다.

cat /proc/PID/maps로 해당 프로세스에 대한 정보를 보면 여러가지 정보 중 rwxp로 stack영역에 실행권한이 있는것을 볼 수 있다.

NX가 걸려있을때와 비교해보면

이렇게 실행권한이 없는것으로 NX가 걸려있다면 스택에서 쉘을 실행시킬 수 가 없다.

쉘을 띄우는 쾌감을 느끼기 위해 NX를 해제하고 bof공격으로 쉘을 띄워보았다.

스택에 쉘코드를 넣고 실행시켜야 하기 때문에 버퍼의 시작 위치를 찾기 위해 bp 를 main+16 위치에 걸고 AAAA를 입력하였다.

0x41414141이 들어가 있는곳이 바로 버퍼의 시작 위치이다.

따라서 여기서 버퍼의 시작 주소는 0xbfffee68 이다.

하지만 익스가 안된다;;

이럴경우를 대비해서 버퍼의 시작 주소를 출력하도록 했는데 

실행을 해보면 gdb내에서의 주소와 실제 주소와 다르다.

구글에게 물어보니 최신 리눅스이기 때문이라는데 자세하게 왜 그런지는 모르겠다.

따라서 시작주소를 0xbfffeea8로 잡고 공격을 하였다.

쉘을 띄운것을 확인 할 수 있었다.

DEP/NX 가 걸린 상태에서는 당연히 stack에 실행 권한이 없기 때문에 쉘코드가 실행되지 않는다.

이를 우회하는 RTL 이라는 기법이 존재하고 다음은 RTL에 대해 알아보겠다.