Memory Corruption Heap

Memory Corruption - Heap

아꿈사 (http://cafe.naver.com/architect1.cafe)

Codevania (http://codevania.textcube.com)

Index

• What is Heap?– Heap– Front End Allocator– Back End Allocator– Under the hood of Heap Allocation

• Heap Corruptions– Using Uninitialized State– Heap Overruns and Underruns– Heap Handle Miss Matches– Heap Reuse After Deletion

• Summary

What is Heap?

• Heap–정의

•애클리케이션이 메모리를 동적으로 할당하고 해제할 필요가 있을 때 사용할 수 있는 메모리 관리자의 한 형태

–언제 필요한가 ?•필요한 메모리의 크기를 사전에 알 수 없을 때•필요한 메모리가 너무 커서 스택에 할당 할 수 없을 때

–하이레벨 메모리 관리자•가상 메모리 관리자를 이용하는 윈도우 힙 관리자를 사용•일반적으로 힙 관리자를 사용

– 다음 페이지에 그림 6.1 첨부

What is Heap?

• 윈도우 메모리 관리 아키텍쳐 개요

Allocator

• Front End Allocator ( 이하 FEA)• Back End Allocator ( 이하 BEA)

Allocator

• Front End Allocator– BEA 를 위한 추상적인 최적화 계층–상이한 FEA 를 둠

•다른 메모리 요구를 가진 애플리케이션은 적절한 할당자를 선택 가능

•Ex) 작은 메모리 할당을 빈번하게 할 것으로 예상되는 애플리케이션– 단편화를 피하기 위해 LowFragment FEA 를 선호할 수 있다

•윈도우에는 두 가지 FEA 가 존재– Look aside list (LAL) front end allocator

» 메모리 할당의 가장 빠른 방법– Low fragment (LF) front end allocator

» 참조 : http://msdn.microsoft.com/en-us/library/aa366750(VS.85).aspx

Allocator

• Front End Allocator– 할당 요청 시나리오 [ 성공 ]

• 초기– [1] 크기가 16 인 3 개의 힙 블록– [3] 크기가 32 인 2 개의 힙 블록

• 크기가 24 인 힙 블록 할당 요청– 24 + 8(Metadata) = 32– 32 / 8 = 4– 4 – 1(Zero-Based Table) = 3

• [3] 조사– 2 개 이용 가능– 첫 블록 제거 , 호출자에게 반환

– 할당 요청 시나리오 [ 실패 ]• 크기가 16 인 힙 블록 요청• [2] 에 없음 BEA 로 포워딩

Allocator

• Back End Allocator

Allocator

• Back End Allocator–프리 리스트라 불리는 리스트 테이블을 소유

•프리 리스트– 책임 : 특정 힙 내의 모든 프리 힙 블록을 추적– 개수 : 128 개 . – 크기

» 각 리스트는 특정 크기의 힙 블록을 소유» 각 크기는 이전 크기에서 8 바이트씩 증가» 최대 할당 크기를 초과하는 할당은 [0] 에 위치

– 관리 : 효율을 위해 비트맵 사용» 0: 프리 힙 블록 없음» 1: 프리 힙 블록 소유

Allocator

• Back End Allocator–블록 분리 (Block Splitting)

•요청받은 크기의 프리 힙 블록을 발견하지 못할 때 사용

•요청된 프리 힙 블록보다 큰 블록을 같은 크기의 두 블록으로 나누어서 할당 요청을 만족시킴

Allocator

• Back End Allocator–큰 할당

•프리 리스트 [0]– 1016 ~ 0x7FFF0(524272) 바이트 까지만 포함 가능

•0x7FFF0 보다 큰 할당– 힙 관리자는 가상 메모리 관리자에게 명시적인 할당 요청– 이들 할당을 가상 할당 리스트에 보관

Heap Manager

• cf1. 힙 관리자는 메모리를 어디서 가져오나 ?–큰 덩어리 (chunk) 의 메모리를 할당하기 위해

윈도우 가상 메모리 관리자를 사용–힙 세그먼트

•가상 메모리 관리자에게 요청하는 덩어리

Heap segment

• cf2. 힙 세그먼트의 기본적인 배치– Figure 6.7 은 두 개의 할당과 커밋되지 않은 메모리

영역이 존재하는 상태–새로운 세그먼트가 생성되면…

힙 관리자는 새롭게 생성된 세그먼트를 추적 리스트에 추가

Pre- & Post- Allocation Metadata

• cf3. 선 / 후 할당 메타데이터의 구조–메타데이터

•세그먼트 내의 힙 블록의 효과적인 관리를 위해 사용

Heap Coalescing

• cf4. 힙 합병 (Heap Coalescing)–메모리 단편화 문제를 피하기 위한 메커니즘–인접한 프리 블록을 하나의 큰 블록으로 합침–비용 높음

What is Heap?

• Summary– 메모리 블록 할당

• 프리 블록 메모리가 이용 가능한지 확인– FEA 의 Look Aside List 를 참조

• 이용 가능– 프리 블록 메모리를 호출자에게 반환

• 이용 불가– BEA 의 프리 리스트가 참조됨– 정확하게 크기가 일치함

» 플래그 갱신 해당 블록이 Busy 함을 나타냄» 이 블록은 프리 리스트에서 제거되고 , 호출자로 반환됨

– 정확하게 크기가 일치하지 않음» 요청된 할당 크기보다 큰 블록을 양분할 수 있는지 검사» 가능하면 양분» 하나는 Busy 상태로 갱신되어 반환됨» 다른 하나는 Free 상태로 설정되어 프리 리스트에 추가됨

What is Heap?

• Summary–메모리 블록 해제

• FEA 가 해당 프리 블록을 처리할 수 있는지 요구•처리 가능

– 프리 리스트에 추가

•처리 불가– 인접한 프리 블록이 존재

» 두 개의 인접한 프리 블록이 프리 리스트에서 제거됨» 새로운 큰 블록이 Free List 나 Look-aside List 에 추가됨» 새로운 큰 블록의 플래그 필드 갱신 Free 상태

– 인접한 프리 불록이 부재» 이 블록은 Free List 나 Look-aside List 로 이동되고

플래그는 Free 상태로 갱신됨

Under the hood of Heap Allocation


• PEB (Process Environment Block)– 실행 중인 각 프로세스가 유지하는 액티브 힙 리스트

포함프로세스에 관한 정보용 구조체


• 힙 포인터의 배열 덤프– 5 개의 힙이 덤프되어 있음 ( 책에는 3 개임 )–왜 하나 이상의 힙이 존재 ?

•자신들만의 힙을 생성하는 컴포넌트를 내부적으로 사용•초기화 동안에 자신의 힙을 생성하는 C런타임이 좋은 예


• 프로세스 힙에 관한 정보 덤프


• HeapAlloc 함수 수행 전 / 후

Heap Corruptions

• Using Uninitialized State–초기화 되지 않은 상태란 ?

•성공적으로 할당은 이뤄졌으나•사용하기에 유효한 상태로 초기화되지 않은 메모리 블록

Heap Corruptions

• Using Uninitialized State–애플리케이션 실패 원인

•첫 번째 항목을 디레퍼런스 할 때•주소가 유효하지 않다면 접근 위반•무엇이 발생할 것인가는 임의의 포인터 값에 의존

Heap Corruptions

• Using Uninitialized State–디버거에서 실행

힙 관리자는 자동으로 모든 메모리를 채움 패턴으로 초기화 .c0c0c0c0 힙 블록이 할당되었지만 아직 초기화되지 않았음을 표현

Heap Corruptions

• Using Uninitialized State–실행 후 디버거 어태치

•책에서는 디버거에서 실행하는 것과 다르다고 하는데뭘 잘못했는지 계속 동일하게 나옴 ;;

–위반이 즉시 발견되지 않는 경우라면•위반이 발생할 때의 스택은 코드와 아무런 관계 없음•이 위치에서 손상의 출처를 찾는 것은 , 극도로 난해•디버거에서 프로세스를 시작해 채움패턴을 사용하도록

Heap Corruptions

• Heap Overruns and Underruns–오류 코드가 메타데이터를 덮어 쓴다

•힙의 무결성 손상 애플리케이션 폴트•힙 블록의 소유자가 블록의 경계를 소홀히 할 때 발생

Heap Corruptions

• Heap Overruns and Underruns

Heap Corruptions


Heap Corruptions

• Heap Overruns and Underruns–스택

•접근 위반시 셧다운 중이었을 것으로 추정됨

–문제점•스택에 코드가 보이지 않음•가장 큰 문제는 ,

– 폴트를 유발한 코드가 손상 시점에 쉽게 트랩 될 수 없음– 손상은 실행이 한참 진행된 이후에 나타남

–실마리 추적•힙의 어느 부분이 손상됐는지 모름 세그먼트 보존 여부 확인 (!heap 확장 명령 사용 )

Heap Corruptions


Heap Corruptions


Heap Corruptions

• Heap Overruns and Underruns –힙 관리자는 덮어쓰기가 발생한 바로 그 시점에 감지하지 못했고 , 실행이 한참 진행된 이후에 감지

–힙상태가 불완전하게 되어 접근 위반으로 이어졌음

Heap Corruptions

• Heap Overruns and Underruns –쓰여진 후가 아니라 쓰여질 때에 실행을 중단하자

•애플리케이션 베리파이어 사용– 힙 블록을 서로 격리해 보호하는 페이지 힙을 이용

기존Varifier 사용으로 인한 추가 메모리

Heap Corruptions

• Heap Overruns and Underruns– Application Varifier 사용 (Not Full)

Heap Corruptions

• Heap Overruns and Underruns– Application Varifier 사용 (Full)

Heap Corruptions

•완전 페이지 힙–왜 항상 사용하지 않나 ?

•너무 많은 자원을 소비하기 때문•메모리 소비를 엄청나게 증가시킬 수 있음•디폴트는 보호 페이지가 끝부분에 위치 .

– Backward Option 을 활성화 시키면 앞부분에도 보호 가능

• Heap Underruns–잘못된 포인터 연산으로 인해서 힙 블록의 앞부분에 쓰게 되는 경우 발생

Heap Corruptions

• Heap Handle Miss Matches–힙 관리자

•프로세스 내의 액티브 힙에 대한 리스트를 유지•메모리를 할당 / 해제 시 정확한 힙 사용을 보장해야함

– 힙의 내부 상태는 그 특정 힙 컨텍스트 내에서만 유효– 즉 , 힙은 별개의 개체라고 할 수 있음

–힙 핸들•힙의 고유성을 보장하기 위함•고유성이 보장되지 못한다면 힙 손상 발생

Heap Corruptions

• Heap Handle Miss Matches

Heap Corruptions

• Heap Handle Miss Matches

Heap Corruptions

• Heap Reuse after Deletion

• Heap Reuse after DeletionBefore

After바뀌었음

Heap Corruptions


Heap Corruptions


Summary

• 힙 손상–애플리케이션에 손상을 가할 수 있느 심각한 에러

•한 바이트 차이 손상일지라도 , 애플리케이션이…– 크래시되거나– 예측할 수 없는 행위를 하거나– 무한 루프에 빠질 수 있다

–결과를 즉시 볼 수 없음•손상이 일어난 후까지도 , 일반적으로 드러나지 않음

– 힙 손상의 출처 파악을 매우 어렵게 만듬– Application Varifier 를 사용하면 좀 쉽게 찾을 수 있음

Memory Corruption Heap

Technology