크래쉬 덤프 분석 패턴 (Part 2)
https://www.dumpanalysis.org/blog/index.php/2006/10/31/crash-dump-analysis-patterns-part-2/
글 : Dmitry Vostokov
번역 : 김희준 (2007-04-27, drost@naver.com)
크래쉬 덤프 분석 패턴 (Part 2)
이번에 소개하려는 패턴은 Dynamic Memory Corruption(Heap Corruption이나 Pool Corruption이라고 불리기도 합니다) 입니다. 이미 여러분들 잘 알고 계시겠지만, 아주 동해번쩍 서해번쩍 발생하지요. 또 랜덤하게 일어나고 원래의 오리지널 corruption 지점에서 아주 멀리 떨어진 곳에서 크래쉬되곤 합니다. 크래쉬 된 후에는 유저모드의 예외 스레드(지난번 Multiple Exceptions 패턴을 잊지 마세요) 영역에서 아래와 같은 내용을 볼 수 있을 것입니다.
ntdll!RtlpCoalesceFreeBlocks+0x10c
ntdll!RtlFreeHeap+0x142
MSVCRT!free+0xda
componentA!xxx
또는
ntdll!RtlpCoalesceFreeBlocks+0x10c
ntdll!RtlpExtendHeap+0x1c1
ntdll!RtlAllocateHeap+0x3b6
componentA!xxx
이러한 유사한 형태를 볼 수 있을 것이고, 여러분들은 이제 어플리케이션의 heap을 어떤 컴포넌트가 망가뜨렸는지 알기를 원하겠지요(보통 크래쉬된 스레드 스택에서 볼 수 있는 component.dll과는 다른 컴포넌트가 원인입니다)
이번의 빈번하게 발생하는 문제(common recurrent problem) 에서, 우리는 일반적인 해결책(general solution) 을 가지고 있습니다: 바로 heap checking을 사용하는 것이지요. 이 일반적인 해결책은 특정한 상황(specific context) 에서 아래처럼 적용이 가능합니다.
- Heap 함수들에 대하여 파라미터 값 체크
- 특정한 시점(예-“malloc”/”new” 또는 “free”/”delete” 호출) 전후에서 유저 영역의 소프트웨어적 방식으로 heap 체크: 보통 어떤 패턴을 채우고 그것을 체크하는 식으로 구현됨
- 하드웨어/OS가 지원하는 heap 체크(버퍼 오버런을 탐지하기 위한 guard나 nonaccessible page를 사용)
제 경험상 대부분의 heap corruptions들이 버퍼 오버플로우로부터 발생되기 때문에 후자에 있는 것이 주로 사용되었습니다. 그리고 특정한 패턴을 채워서 검사하는 것보다 MMU 지원기능을 바로 사용하는 것이 훨씬 쉽습니다. 다음에 링크된 글은 어떻게 full page heap을 켜는지 설명하고 있는 Citrix의 기술지원 웹 페이지입니다. 여기에서는 Citrix Independent Management Architecture (IMA) 서비스라는 이름의 특정한 프로세스를 예로 들고 있지만, 여러분들은 디버깅 하려는 어플리케이션의 이름으로 바꿔치기 하여 읽어보시면 됩니다.
볼만한 또 다른 글이 있습니다:
How to check in a user dump that full page heap was enabled
다음 마이크로소프트 문서는 다양한 heap 체크방법에 대해서 설명합니다:
How to use Pageheap.exe in Windows XP and Windows 2000
윈도우 커널 레벨에서는 page/nonpaged pool corruption이라고 부릅니다. 윈도우 커널 pool에 대해서도 마찬가지 테크닉을 사용됩니다, 예를 들어서 nonaccessible pages를 구현해 놓은 Driver Verifier로 special pool을 켜놓으면 됩니다. 더 자세한 내용은 아래의 마이크로소프트 문서를 참고하세요.
How to use the special pool feature to isolate pool damage
- Dmitry Vostokov -
Comments
- Anonymous
September 16, 2008
The comment has been removed