Oulth의 자료창고

런타임 동안 APP의 데이터와 코드가 매핑되는 곳을 무작위로 결정함으로써 버퍼 오버플로우 위협을 완화시키는 기술이다. 우회 모든 프로세스는 재배치 불가능한 공유 라이브러리를 포함한다. 이러한 정적인 부분을 이용하면 사용 가능하다. 두 번째는 브루트 포스 방법을 사용한다. 데이터는 메모리 영역에서 적당한 크기의 차이를 갖고 움직인다. 공격자는 각 오프셋으로 서비스 요청을 보내고 결국 알맞은 오프셋을 발견함으로써 공격할 수 있게된다.

힙 오버플로우는 메모리 할당 해제 루틴에서 발생한다. 그리고 리스트 연산자는 메모리의 장소에 쓰는 것을 통해서 APP의 제어권을 가진다. 이 것을 방지하기 위해서 힙 구현을 강화한다. 각 힙 헤더 구조체에 8비트 쿠키를 저장한다. 이 쿠키와 전역 힙 쿠키를 XOR 연산 한 후 힙 청크 어드레스를 8롤 나눈다. 결과가 0이 아니면 힙 오염이 발생한 것이다. 이 연산에서 힙 청크의 주소가 사용되므로 브루트포스를 방지할 수 있다. 그리고 언링크 연산이 일어날 때마다 유효한 값이 검사하는 방법도 있다. 언링크하기 전에 현재 엘리먼트를 가리키고 있는 올바른 포인터를 가지고 있는지 검사하는 것이다. 우회 여전히 공격자는 힙 데이터 구조체를 이용해서 공격이 가능하다. 힙 보호 매커니즘의 가장 중요한 한계점은 내부 힙..

Stack Canary란?canary 는 XP SP2 이후 버전의 어플리케이션과 라이브러리에서 디폴트로 적용되어 있는 스택 보호 기법이다. canary는 크게 세 종류가 있다. 우회법 1. EBP와 리턴 주소를 덮어 쓰는 것은 방지할 수 있지만 인접한 지역변수의 덮어쓰기는 막을 수가 없다. 2. 스택 쿠키의 이후 주소에 쓰기를 수행해서 현재 함수의 매개변수 값을 덮어쓰는 방법도 있다. 이런 경우 함수가 리턴하기 전 APP의 제어를 가져가버린다. 3. 그 방법 말고도 SEH레코드의 조작도 가능하다.

힙 구현 방법은 malloc 호출 때 할당 free 때 해제한다는 공통점이 있다. 메모리가 효과적으로 할당되고 해제되려면 메모리영역의 상태가 저장되어야한다. 특히 대부분 메모리 블록 정보와 블록의 트성을 설명하는 헤더가 붙은 메모리 블록을 사용자에게 리턴한다. 블록 헤더에는 다음과 같은 정보가 있다. 현재 블록 크기이전 블록 크기블록 사용 여부몇 가지 추가적인 플래그 malloc으로 사용중일 때는 glibc 사용된 조각 이것이 되고 free되었을 때 즉 사용이 안되고 있는 경우 glibc 가용조각 이게 됩니다. 힙 오버 플로우 공격 스택 버퍼 오버플로우의 경우 리턴 어드레스라는 코드를 담고 있는 맛있는 포인터가 있지만 힙에는 그런 것이 없습니다. 그래서 공격자는 데이터 포인터나 함수의 포인터를 덮어씌워야..

메모리는 배열의 길이를 잘못 계산한 것에서도 비롯된다. 흔한 실수 중 하나는 배열의 요소를 잘못계산해서 발생하는 off by one 에러이다. 예를 들어 이러한 코드에서 dest 배열은 0부터 시작하기 때문에 i는 31에서 멈추는 것이 맞다. 하지만 sizeof(dest)이 32를 반환하므로 dest[32]=src[32] 가 실행된다. 두 번째로 이 경우 user의 문자열 길이가 1024라면 검사는 둘 다 2014이므로 성공적으로 넘어간다. 하지만 strcpy에서 1바이트 더 쓰게된다. 왜냐하면 null 바이트 때문에 한 바이트가 더 쓰여지기 때문이다. off by one은 인텔 x86 머신에서 동작하는 os에서 많이 악용된다. 베이스 포인터나 스택 프레임의 주소는 ebp 에 저장된다. 그리고 스택 상에..

윈도우 시스템에는 전통적인 스택 오버플로우 공격과 약간 다른 취약점이 있습니다. 이 공격은 smashing the Structured Exeception Handler라고 합니다. 윈도우에서는 일관성있는 예외처리를 위해 SEH라는 것을 제공합니다. 예를 들어 스레드에서 예외가 발생한다면 스레드는 예외를 처리할 수 있는 기회를 얻는데 이 예외 처리를 담당하는 핸들러(함수)는 링크드 리스트로 구성되어 있고 가각 노드에 할당되게 됩니다. 리스트의 헤드는 TEB(Thread Environment Block) 의 초기에 위치한 포인터에 의해서 알 수 있으며 새로운 예외 처리가 생성된다면 새로운 노드가 리스트의 헤드에 추가되고 TEB는 새로운 노드를 가리키게 됩니다. 각가의 노드는 EXCEPTION_REGISTRA..

버퍼 오버플로우는 가장 흔한 타입의 메모리 버그이다. os에 따라서 프로세스는 메모리에 다양하게 배치될 수 있지만 공통점이 있다. 1. 모든 프로세스는 실행 가능한 프로그램 명령을 포함한다. 2. 프로그램은 전역 변수와 정적 변수를 포함한다. 또한 동적 메모리인 힙이 있다. 3. 스택이 존재한다. 이는 버퍼의 위치에 따라서 버퍼 오버플로우 취약점의 영향력이 다양해 질 수 있다는 것을 보여준다. 스택 버퍼 오버플로우 스택 오버플로우는 스택이 위치하는 목적지 퍼버에서 발생되는 오버플로우다. 모든 프로세스는 스택이라고 불리는 런타임 스택을 가지고 있다. 프로세서는 스택의 맨 위를 가리키는 레지스터가 있으며그 값은 push와 pop 을 통해 변경된다. 인텔에서는 이러한 레지스터는 esp라고 부른다. 최근 cpu..

Protected Mode 의 목적 2006년에 Protected Mode 가 IE 7에서 소개되었다. 이 PM의 목적은 데이터 수정 그리고 시스템 상에서의 악성코드 인스톨을 예방하는 것이었다. 비스타에서 소개된 무결성 메커니즘 사용해서 PM은 SANDBOXED IE 를 동작시킨다. 그리고 이것은 쓰는 작업에 대한 강력한 리미트를 제공한다. 2012년 EPM 이 소개되었다. EPM은 목적 중 하나는 기존 pm의 한계이다. 기존의 PM은 민감한 정보에 대한 read 는 제한하고 있지 않았다. EPM 에서 IE는 AppContainer 안에서 작동한다. 프로세스 고립 메커니즘은 Window8에서 소개 되었다. 이 것은 sandboxed process 로의 read write 를 둘다 제한한다. 그리고 san..

124번 째 줄의 get_buffer() 함수는 입력 버퍼를 할당 받은 header 힙에 저장합니다. 만약 current_track에 0x8000000보다 큰 값을 넣고 부호 있는 정수형으로 반환한다면 current_track 값은 음수가 될 것입니다. 그리고 if문은 false를 반환할 것 입니다. 그리고 178번째 부터 181까지의 쓰기 작업으로 총 4번의 NULL 포인터 역참조가 발생합니다. 정상적인 흐름 1. fourxm -> tracks 가 null로 초기화됩니다. 2. 만약 strk 청크를 포함하고 있다면(160번째 줄) 헤더로부터 정수를 추출해서 current track에 넣습니다. 3. track_count보다 current_track+1 이 크면 fourxm->tracks를 가리키는 메모..

static 한 방식으로 취약점을 찾는 전략은 strcpy, strcat 같은 안전하지 않는 c/c++ 라이브럴 함수들 근처에 있는 코드를 찾는 방법이다. 또는 부호와 관련된 취약점을 찾기 위해 movsx 명령어를 디스어셈블리에서 검색할 수 있다. 추약한 코드 위치를 찾았담ㄴ 그 코드로부터 역추적하면서 app의 엔트리 포인트에서 접근 가능한 취약점을 노출하고 있는지 살펴본다. 퍼징이라는 방법도 있다. 자신만의 퍼징 프레임 네트워크를 개발해서 대부분의 버그를 퍼징 툴로 찾아내는 사냥꾼들도 있다. 복잡한 프로그램이 주어졌을 때 데이터가 전달되는 시작점을 찾기란 쉽지 않겠지만 복잡한 소프트웨어는 망가진 입력 데이터를 처리할 때 충돌이 일어난ㄷ. 웹브라우저, 오피스 제품군이 그렇다. 즉 파싱하는 소프트웨러들이다..