0x02.pwnable.kr - bof

0x02.pwnable.kr - bof

Nana told me that buffer overflow is one of the most common software vulnerability. 
Is that true?
​
Download : http://pwnable.kr/bin/bof
Download : http://pwnable.kr/bin/bof.c
​
Running at : nc pwnable.kr 9000

이 문제는 BufferOverflow와 관련된 문제인 것 같다. 오버플로우가 어디서 터지는지를 알아내기 위해 bof.c 파일을 확인해보았다.

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void func(int key){
    char overflowme[32];
    printf("overflow me : ");
    gets(overflowme);// smash me!
    if(key==0xcafebabe){
        system("/bin/sh");
    }
    else{
        printf("Nah..\n");
    }
}

int main(int argc, char* argv[]){
    func(0xdeadbeef);
    return 0;
}

main함수부분에서 func(0xdeadbeef)가 실행되고, fun안에서 gets로 32바이트의 크기의 overflowme 변수의 값을 사용자로부터 입력을 받는데 이를 통해 int key 변수의 값이 0xcafebabe로 변경된다면 system함수로 쉘을 실행시켜서 flag를 확인할 수 있다.

처음 예상하는 func 에서의 스택 구조는 다음과 같다.

[ overflowme[32] ][ sfp[4] ][ ret[4] ][ key[4] ]

python 파이프라인을 사용하여 다음과 같이 입력을 하였는데, Nah.. 가 출력되었다.

생각했던 버퍼의 크기를 고려하여 11개의 cafebabe를 입력하였지만 마찬가지로 Nah가 출력되었다. 이는 argv로 입력한 값이 func 호출과정에서 dummy값의 추가로 인한 것으로 예상된다.

원격 접속이라서 objdump를 직접 할 수 없기에 하나씩 증가시키며 값을 집어넣었고, 'daddy, I just pwned a buFFer :)' 라는 Flag를 확인할 수 있었다.

좀 더 확실하게 확인하기 위해서 IDA를 활용해 보았다. IDA로 func 부분을 확인해 보았더니

char s가 ebp-0x2c 부분에 있는 것을 알 수 있다. 다시 버퍼의 그림을 그려보면 다음과 같다.

[ s ] [ v3 ] [ SFP ] [ ret ] [ al ]

즉, cafebabae가 4바이트의 크기이기 때문에 44바이트 만큼을 입력을 하면 s와 v3를 덮어쓰게 되고, 48바이트 일 경우 SFP, 52바이트일 때 ret를 덮어쓰게 되고, main함수에서 넘어온 인자인 al(key)은 56바이트 만큼을 입력함으로써 덮어씌워지는 것이다. 그렇기 때문에 위에서 페이로드를 넣을 때 4 * 14(=56) 이상의 데이터 값을 넣으면 쉘을 딸 수 있는 것이다.