Smashing The Stack For Fun And Profit을 읽으려는 분들에게

related keyword : Smashing The Stack For Fun And Profit errata, misprint, 오탈자, 에러

-----

http://www.phrack.org/issues/49/14.html#article

Aleph One이 저술한 Smashing The Stack For Fun And Profit은 96년도에 나온 문서라 그런지 몰라도 안에 코드들

을 현재의 최신 OS 및 컴파일러 환경에서 실행하면 제대로 동작하지 않는 부분이 많고, 실습을 위해 몇몇 설정을

해주어야 하는 부분들이 있다. 이 글은 내가 해당 문서를 공부하고 직접 따라 실습해보면서 막혔던 부분이나 동작

하지 않는 코드의 원인, 어떻게 하면 최신 환경에서 동작하게 만들 수 있는지에 대해 정리하려는 목적으로 작성

되었다. 혹시라도 해당 문서를 공부하려는 사람이 이 글을 보고 도움이 되길 바란다.

OS environment : 우분투 14.04 LTS (vmware 이용)

gcc version : 4.8.2

1. example3.c

function함수의 (*ret) += 8; 에서 8이 아니라 10을 더해야 한다. 혹은 gdb로 example3을 직접 분석하면서 계산한 주

소값을 사용하면 의도한대로 결과가 출력될 것이다.

2. shellcodeasm.c

a)

relative jump를 수행하기 위한 jmp 0x2a 구문이나 call -0x2f 구문을 바꿔야 한다. 문서에 나온 코드대로 컴파

일해 gdb에서 분석 해보면 jmp가 사용하는 번지가 절대주소번지로 해석이 되어버린다. relative jump를 하기 위해

서는 jmp .+번지 형태로 고쳐주어야 한다. (ex --> jmp .+0x2c)

.은 해당 명령어가 위치한 시작 주소를 나타내며, 여기에다가 원하는 번지만큼을 더해서 relative jump를 수행하도록

한다. 여기서 더할 번지는 gdb로 직접 분석해서 주소 차이만큼을 계산해야 한다.

b)

인라인 어셈블리 문법의 형태를 위의 그림처럼 바꿔야 한다

(각 명령어 및 오퍼랜드마다 ""로 감싸고 뒤에 \n\t 붙여주기)

3. testsc.c

나의 경우 testsc.c를 그대로 컴파일해 실행했을 때 segmentation fault가 발생했다. 현재의 환경에서는 버퍼오버 

플로우를 체크하거나 스택을 executable하지 못하도록 막기 때문인 듯 하다.

그림에서처럼 gcc로 testsc를 컴파일 할 때 -fno-stack-protector 옵션과 -z execstack 옵션을 주면 testsc를 실행

했을 때 셸이 실행될것이다. (그림은 testsc2지만 testsc에도 똑같이 적용됨)

해당 옵션 관련 글 : http://huammmm1.tistory.com/499

4. shellcodeasm2.c

2번과 동일

5. testsc2.c

3번과 동일

6. overflow1.c

3번과 동일

7. sp.c

현재의 환경에서는 스택의 시작 주소가 고정되어있지 않다. ASLR(Address Space Layout Randomization)이라고

해서 스택의 시작 주소가 프로세스를 실행할 때 마다 랜덤으로 변하도록 디폴트 설정이 되어 있다.

원활한 실습을 위해서는 프로세스의 스택 시작 주소를 고정시킬 필요가 있다.

관련 글 참조 : http://huammmm1.tistory.com/498

8. vulnerable.c

컴파일 시 3번처럼 -fno-stack-protector 옵션과 -z execstack 옵션을 주어야 한다. 그렇게 하지 않으면 컴파일 한

vulnerable 파일에 스택 스매싱을 방지하거나 스택의 데이터를 실행하지 못하도록 설정이 되기 때문이다.

9. exploit2.c

exploit2.c에서 사용하는 버퍼의 크기는 vulnerable의 버퍼 사이즈보다 약간 더 커야한다. 나의 경우 버퍼의 크기를

612로 주고 vulnerable.c가 사용하는 버퍼의 주소를 gdb로 알아낸 뒤 이를 get_sp() 대신 사용해서 셸을 띄우는데 

성공했다.

10. exploit3.c

사용할 버퍼의 크기는 vulnerable의 buffer 크기보다 100byte정도 크게 준다. 그리고 offset은 vulnerable 버퍼의 크기

보다 100쯤 낮게 주어서 성공했다. (vulnerable에서 지역변수로 선언한 버퍼의 크기가 있기 때문에 exploit3.c에서

get_sp()로 얻은 주소를 그대로 쓰면 안됨)

11. exploit4.c

추가된 RET 환경변수와 EGG 환경변수 때문에 vulnerable의 main함수의 스택 시작 주소가 더 낮아져서, exploit4.c에

서 얻은 esp가 vulnerable 에서는 EGG 환경변수의 시작번지와 끝번지 사이를 가리키게 됨을 확인했으나, 더 정확하

게는 문서에 나온 코드 대신 getenv()로 EGG 주소를 얻어서 사용하는 것이 더 정확할 것 같다.