Pwnstar
Pwnable.kr otp 본문
이야 이문제도 참 오래 걸렸는데 학교 선배께서 이 문제랑 syscall은 라이트업을 보면서 공부하는 느낌으로 풀라고 하셔서 그렇게 풀었다... 근데 이런 방법으로 푸는 문제일줄은 상상도 못했다.
우선 mitigation은 canary와 nxbit가 걸려있다.
소스코드
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
int main(int argc, char* argv[]){
char fname[128];
unsigned long long otp[2];
if(argc!=2){
printf("usage : ./otp [passcode]\n");
return 0;
}
int fd = open("/dev/urandom", O_RDONLY);
if(fd==-1) exit(-1);
if(read(fd, otp, 16)!=16) exit(-1);
close(fd);
sprintf(fname, "/tmp/%llu", otp[0]);
FILE* fp = fopen(fname, "w");
if(fp==NULL){ exit(-1); }
fwrite(&otp[1], 8, 1, fp);
fclose(fp);
printf("OTP generated.\n");
unsigned long long passcode=0;
FILE* fp2 = fopen(fname, "r");
if(fp2==NULL){ exit(-1); }
fread(&passcode, 8, 1, fp2);
fclose(fp2);
if(strtoul(argv[1], 0, 16) == passcode){
printf("Congratz!\n");
system("/bin/cat flag");
}
else{
printf("OTP mismatch\n");
}
unlink(fname);
return 0;
}
소스코드는 뭐 별 건 없다고 생각했다.
랜덤으로 나온 passcode의 값을 argv[1]과 비교해서 같으면 flag를 보여주는 것이 전부지만, 그 부분을 잘 봐야했다.
중간에 보면 sprintf(fname, "/tmp/%11u", otp[0]) 이 부분에서 랜덤 값(otp[0])으로 파일 이름을 만들어주고, 이 파일을 열어 otp[1]에 있는 랜덤값을 파일에 넣는다.
그런데 리눅스 명령어 중에서 파일 사이즈를 0으로 만드는 명령어가 있다.
ulimit -f 0 뒤의 숫자로 파일 사이즈를 결정할 수 있는데, 이 사이즈를 0으로 만들면 바이너리가 실행될 때 만들어지는 파일의 사이즈가 0이 되고, passcode의 값도 없을 것이다.
라이트업을 보면 python의 subprocess 모듈을 사용했는데, 왜 이 모듈을 사용해야만 되는지는 아직 이해를 하지 못했다. 파일의 사이즈만 0으로 만들면 바로 해결될 거라고 생각했는데, 그것도 아니었다.
otp@pwnable:~$ python
Python 2.7.12 (default, Nov 12 2018, 14:36:49)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(["./otp", ""])
<subprocess.Popen object at 0x7f2d338eff10>
>>> OTP generated.
Congratz!
Darn... I always forget to check the return value of fclose() :(
>>>
아마도argv[1]에 null 값을 넣을 방법 중에 아닐까라는 생각을 해본다
'Pwnable.kr > Rookiss' 카테고리의 다른 글
Pwnable.kr echo1 (0) | 2020.07.28 |
---|---|
Pwnable.kr fix (0) | 2020.07.28 |
Pwnable.kr syscall (0) | 2020.07.22 |
Pwnable.kr fsb (0) | 2020.06.25 |
Pwnable.kr tiny_easy (0) | 2020.06.25 |
Comments