PWN / fake_canary

이번 문제는 ImaginaryCTF 2021에서 나온 문제입니다.

간단한 문제지만 플래그를 얻지는 못했고 그 대신 모르는 지식을 얻어간 문제입니다 아직 뉴비인 저에겐 더욱 좋죠

무엇보다 이 글은 문제 풀이보단 문제를 풀지 못한 이유와 그것을 이해하는데 중점을 두려고 합니다ㅎㅎ

 

file

해당 문제에서는 64비트 ELF 파일이 주어집니다.

 

어째 이름부터가 fake_canary이기에 stack-canary가 걸려있을까 보았는데 canary는 걸려있지 않습니다

No canary

gdb

주목적이 풀이가 아니기 때문에 빠르게 보고 넘어가면 gets를 통해 bof가 발생하고  fake-canary는 static(0 xdeadbeef)으로 rbp-0x8과 비교하여 overflow 여부를 판단하기 때문에 ret값까지 데이터를 넣다가 rbp-0x8에서 fake-canary값을 넣어주고

win()함수

ret를 win(0x400725) 함수로 덮어주어서 쉘을 실행시키도록 exploit를 짜서 실행시키면 쉘을!!!

Tlqkf

에...

 

안쓰러운 영어실력으로 물어보니까 rbp랑 movaps issue라고 합니다.

결과적으로는 x64에서 스택을 16의 배수를 정렬을 해주지 않아 생기는 문제라고 합니다

ret 실행전

ret 실행 후

exploit를 다시 gdb에 attach 해서 ret 실행 전까지 보면 16으로 정렬이 되지 않고 이러면 ret명령어를 수행한 뒤  즉 rbp+0x8에는 스택이 16으로 정렬이 되겠죠

win()함수 push rbp

결국엔 정렬된 상태에서 push rbp로 스택이 8 감소하기 때문에 결국엔 정렬되지 않은 상태가 되기 때문에 

결국엔 Segmentation fault가 되면서 그대로 종료되게 됩니다

ret 가젯 exploit code

exploit 실행

결국 스택만 정렬해주면 문제가 풀리기 때문에 ret에 ret주소를 한번 더 넣는 방법으로 해결할 수 있고 

skip push rbp exploit code

exploit 실행

다른 방법으로는 push rbp를 건너뛴 win(0x400726)으로 ret를 덮어 씌우면 정렬 문제를 해결하고 정상적으로 exploit을 실행시킬 수 있습니다.

 

 

결국에는 이 정렬문제가 왜 생기는 걸까 의문점이 드는데요

 

명확한 이유는 아직 알지 못하지만 개인적인 추론으로는 function이 ret가 수행될 때 해당 function을 호출한 function의 다음 명령어를 수행해주어야 하기 때문에 정렬된 상태로 다시 돌아가서 rip의 명령을 정렬된 상태에서 수행해주는데

여기서는 function의 프롤로그부터 다시 수행하기 때문에 이문제가 생기는 것이 아닐까 생각해봅니다

 

 

플래그보다 값진걸 얻어서 기분이 좋네여ㅎㅎ