(how2heap) - overlapping_chunks_2

overlapping chunk 두번째 자료이다.

이 자료 또한 어떠한 문서를 참조했다고 나와있었다.

(참조 문서)

그렇기에 나 또한 이 참조 문서 먼저 공부하였다.
이 문서에는 Heap overlapping에 관해서 3가지 정도의 방법을 제시했다.
Heap Overlapping에 관해 조금씩 다른 방법들을 제시했는데,
다들 비슷비슷한 느낌이었다. 그래도 많은 방법들을 봐두는 것이 좋은 것 같다.

지금까지 Heap Overlapping에 관련된 공격들을 정리하면서 깨달은 점이 있다.
그건
전부 Chunk 구조체의 SIZE 필드를 조작하므로써 공격을 한다는 것이었다.
PREV_SIZE라 던가, SIZE 필드라던가 chunk의 사이즈를 Allocator에게 솎여서 잘못된 할당과 해제를 유발하므로써 기존에 있던 chunk에 중첩되는 chunk를 만들게 하는 방식이었다.

그렇기에 최신 glibc에서는 PREV_SIZE 체크 라던가 SIZE 체크 부분이 추가되었고
이 부분을 우회하는 것을 최근 how2heap에서 본 기억이 난다.

무튼,

heap overlapping 2번째 분석을 시작하자!

(5개의 힙)

5개의 힙 영역을 할당한다.
malloc 사이즈는 1000으로 16진수로는 3E8이다.

뒷자리가 8인 것을 보면 눈치 채겠지만, off-by-one에 취약할 것이다.

(각 힙영역의 범위)

각 힙영역을 표시하기 위해 해당 영역에 문자들을 넣어주었다.

(문자 입력)

그 후 p4 영역을 free해준다.
왜 굳이 p4일까?
-> p4를 free해주면 top청크와 병합되지 않는다. 이유는 top청크와 인접한 p5가 존재하기 때문에 병합되지 않는다. 그리고 공격의 개략적인 시나리오를 말하자면 p1 청크에서 off-by-one으로 p2의 청크 사이즈를 조작할 것이고, p3의 영역을 포함하고 있는 중첩된 heap영역을 할당받는 것이 우리의 목적이다.

: 그렇기에 p4를 free해준 것이다.

(free)

p4를 free해준 후

p1을 이용해 p2의 청크 사이즈를 조작한다.

(청크 사이즈 조작)

조작한 사이즈는
p2 청크의 사이즈 + p3 청크의 사이즈 + PREV_IN_USE + sizeof(size_t)
조작할 사이즈는 p2와 p3를 합한 청크 사이즈로 만들 것이다.
뒤에 prev_in_use 값은 0x1 로써, 이전 청크가 사용중이라는 것을 알려주기 위해 설정한다. 그렇지 않으면 이전 청크와의 병합도 시도할 것이다.
sizeof 값이 더해지는 이유는 p2, p3의 헤더 크기를 추가해주는 것이다. 

(p2 free)

그 후 p2를 free해준다.
그렇게 되면 다음과 같은 일이 일어난다.
1. allocator는 p2를 free하려고 한다.
2. p2의 PREV_IN_USE 비트를 보니 이전 청크를 사용하는 군!
3. next chunk를 검사한다. (p2 주소 + p2의 사이즈 = p4) = next chunk는 p4
=> 왜 다음 청크가 p3이 아닌지? 방금 우리는 p2의 사이즈를 p2,p3을 합한 덩어리로 조작했다. 그렇기에 p2 주소 + (조작된)p2의 사이즈 = p4의 주소 이고 p4가 next chunk가 된다.
4. p4(next chunk)를 확인해보니, free 되어있네???
5. p4랑 병합해야지~, p2는 결론적으로 p2,p3,p4를 포함한 커다란 free chunk가 되버린다.

그 후 malloc을 통해 p3을 포함할만큼 커다란 영역을 할당받는다면?

(큰 영역 할당)

그렇게 되면 p3영역이 포함된 영역을 할당해준다.

(할당된 영역)

할당 된 영역을 보면 p6 사이에 p3영역이 들어있는 것을 확인 할 수 있다.

현재 p3에 들어있는 데이터

(p3의 데이터)

그 후 p6을 F로 1500 글자 채워준다.

(F로 채우기)

그렇게 되면 500자가 p3영역을 침범하게 되어 p3 데이터 앞부분이 F로 채워지게 된다.

(확인)

확인을 통해 p3가 중첩된 영역을 할당받은 것을 확인 할 수 있다.