SSo

gets함수의 길이 검증이 없어서 오버플로우가 일어나는 부분이 있다.

아주 간단하게 rtl로 풀려고 했다.

일단 메인함수를 gdb로 열어보고,

system함수의 주소도 찾고,

/bin/sh의 주소도 찾았다.

근데 막상 페이로드를 입력하고 보니 쉘을 얻었는데 level19의 쉘이 따졌다. 

정상적이라면 level20의 쉘이 따져야하는데.. 19의 쉘을 땄다. 이것이 왜인고.. 하면 

힌트 소스를 보면 setreuid가 없다..

즉 setreuid가 설정이 안된것이다.

그래서 구글링으로 setreuid가 있는 쉘코드를 찾았다.

쉘코드

\x31\xc0\xb0\x31\xcd\x80\x89\xc3\x89\xc1\x31\xc0\xb0\x46\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\x89\xc2\xb0\x0b\xcd\x80

그리고 쉘코드를 환경변수에 등록했다.

등록한 환경변수를 gdb로 어디에 위치했는지 찾았다.

대략 0xbffffbbc쯤 있다.

페이로드를 작성해 쉘을 얻었다.

힌트 소스를 보면 파일디스크립터와 관련된 여러가지 새로운 함수들이 추가되었다.

그리고 쉘을 실행시키는 shellout이라는 함수가 선언되었다.

일반적인 오버플로우 문제랑은 조금 다르다.

오버플로우를 할 수 있는 구조가 없는 것 같다.

파일디스크립터 문서들을 읽다가 이해가 안돼서 답을 조금 봤다.

푸는 방법은 의외로 간단했다.

case 문에서 값을 비교할 때 0x08이 있을 때 count를 --하는 부분이 있다.

일단 스택 구조는 아래와 같다.

fds     : ebp-240

count : ebp-112

x       : ebp-108

check : ebp-104 <- 여기가 같아야함

string : ebp-100

그리고 배열의 인덱스 값이 음수이면 스택의 낮은 주소를 가리키게 된다. 이를 이용해 문제를 풀면 된다.

일단 stdin에 0x08을 4번 넣어주게 되면 count가 4번 -가 되므로 string[-4]를 가리킬 수 있다. string[-4]는 스택의 구조에 의해서 check변수가 위치할것이다.

string[-4]에 0xdeadbeef를 넣어주면 두번째 if문에서 check가 0xdeadbeef와 같으므로 shellout함수를 실행할 수 있다.