Authors: Insu Yun, Georgia Institute of Technology; Dhaval Kapil, Facebook; Taesoo Kim, Georgia Institute of Technology

Paper: https://www.usenix.org/system/files/sec20-yun.pdf

Presentation: https://youtu.be/b8IHrcKKiic

Open-source: ArcHeap https://github.com/sslab-gatech/ArcHeap 


*주의 : 본 포스트 내용은 개인 공부용으로 작성한 것입니다. 아래의 설명은 논문 전체를 번역한 것이 아니라, 블로그 저자의 개인 주관으로 내용을 선별하여 강조한 것이므로 원문의 의도와 완전히 일치하지는 않을 수 있으며, 필요하다면 반드시 상기 링크를 통해 원저자의 논문을 확인하기 바랍니다. (혹시 틀린 부분 발견하시면 알려주세요.)

0. Abstract

Heap Allocator의 메타데이터를 훼손할 수 있는 익스플로잇 기법은 그 범용성(애플리케이션에 종속적이지 않으며)과 강력함(최신 보호 기법을 우회할 수 있음) 덕분에 널리 연구되고 있다. 하지만 이러한 기법들은 소위 '예술적 경지'로 취급받고 있는 바, 이를 수행하는 사람의 수작업과 각 allocator별 특성에 천차만별의 차이를 두고 있다.

본 논문에서는 ArcHeap이라는 자동화된 힙 익스플로잇 도구를 소개한다. 이 도구는 어떤 heap allocator이든 그 구현에 상관없이 취약점을 자동으로 찾아낸다.  핵심적인 아이디어는 컴퓨터가 스스로 그러한 입력 값을 찾아내도록 하는 것으로, 소위 퍼징(fuzzing) 기법을 차용한 것이다. 현대의 heap allocator의 일반적인 설계 구조와, 여러 취약점의 근본 원인을 모델링함으로써, 만약 힙의 동작 명령어가 주어지는 경우 어떤 행동을 했을 때 공격이 될 것인지를 찾아가는 과정이다. 이러한 탐색을 수행하는 동안 ArcHeap은 여러 작업들의 조합이 어떻게 되었을 때 잠재적인 취약점이 발생할 수 있으며 또 이를 악용할 수 있는지(예를 들어 임의 주소 쓰기나 chunks 겹쳐쓰기가 발생하는지)를 확인하는 것이다. ArcHeap은 그 결과로써 PoC 코드도 생성할 수 있다.

ArcHeap으로 리눅스 기본 구현체인 ptmalloc2를 포함한 10종의 allocator에 대하여 실험을 수행했으며, 실제로 ptmalloc2에서 지금까지 밝혀지지 않았던 취약점 악용 기법을 5개 발견해내었고, 10개 중 7개의 allocator에서도 몇 개의 취약점을 찾았다. 비교 대상으로 삼은 allocator에는 보안을 최우선으로 고려하여 설계된 것으로 알려진 DieHarder도 포함되어 있으나 이곳에서도 역시 취약점이 발견되었다. ArcHeap의 효용성을 여러 분야에 확장할 수 있도록 하기 위해 보안 측면에서 보다 심도 깊은 분석을 수행했고, ptmalloc2의 여러 버전 간에서 비교 작업도 수행했다.


1. Introduction

메모리 취약점 중 Heap 영역을 대상으로 하는 공격 기법이 나날이 증가하고 있다. Microsoft에 따르면 2017년 자신들의 제품에서 발생하 ㄴ힙 관련 취약점은 약 53%에 달한다. 아래 자료는 CppCon 2019에서 발표된 Killing Uninitialized Memory: Protecting the OS Without Destroying Performance이라는 내용의 일부이다. 

Heap의 취약점을 이용하여 익스플로잇을 수행하는 HET(Heap Exploitation Technique)들이 나날이 발전하고 있다. 이러한 기법은 대상 시스템의 힙 할당자(allocator)를 공격하는 방법으로 대상 응용 프로그램에 종속되지 않는다. 그리고 현존하는 완화 기법(mitigation)을 효과적으로 우회할 수 있을 만큼 매우 강력하다. 심지어 오직 1 바이트의 내용을 NULL 바이트로 덮어쓰는 것만으로도 대상 프로그램에서 임의의 코드를 실행할 수 있는 등 제어 흐름을 탈취할 수 있을 정도이다(참고: Chrome OS exploit: one byte overflow and symlinks).

Heap을 공격하는 방법은 ASLR이 도입된 이전에는 52건 중 24건이 해당되어 쏙, ASLR이 도입된 이후에도 Non-scriptable 한 프로그램에서 21건 중 10건에 해당하는 비중을 차지한다. 실제로 2019년에는 exim, WhatsApp, VMware ESXi 등에서 힙 취약점을 이용한 공격 사례가 발견되었다. 

학계에서는 이와 같은 힙 취약점에 대한 가능한 공격 기법에 대해 연구를 진행하고 있다. 아래는 2001년부터 현재에 이르기까지 대략적인 타임라인이다. 연도별로 각 기법에서 발견된 새로운 유형의 개수가 괄호 안에 표시되어 있다. 예를 들어 ArcHeap은 5개의 새로운 HET을 발견하였다.

지금까지의 HET 발견 방법은 거의 '예술적 경지'에 이른 사람의 수작업에 의존함으로써, 그 과정이 지나치게 복잡하고, 특정 Allocator의 구현에 종속적이었다(대다수가 ptmalloc2에만 집중). 그래서 각 Heap allocator 종류에 대해 종합적인 이해가 부족하였으며 심지어 같은 Allocator에서도 버전마다 다른 분석이 필요했다. 그리고 보안을 고려하여 설계된 DieHarder에서도 취약점이 발생할 수 있는지에 대한 검토가 필요하다. 

그래서 본 논문에서는 자동화된 힙 취약점 기법 탐색 도구인 ArcHeap을 제안한다. ArcHeap은 어떤 Allocator가 주어지든지 그 구현에 상관없이 자동으로 heap exploitation primitive를 체계적으로 찾아내는 도구이다. ArcHeap의 핵심 아이디어는 컴퓨터가 스스로 가능한 범위를 직접 탐색하도록 하는 것으로 소위 Fuzzing이라고 볼 수 있다. 이와 같은 전략을 적용하기 위해 생각해야 할 난제와, 그것을 해결하기 위한 방안을 제시하고 이를 프로토타입으로 구현한 ArcHeap에 대해 소개한다.


이 논문의 2장에서는 Heap Allocator의 구현을 분석할 것이다. 특히 현대의(modern) 운영체제에서 사용되고 있는 Heap Allocator들의 공통된 특징을 살펴보고, Heap Exploit 사례인 Unsafe Unlink를 이해한다. 3장에서는 Heap에 대한 Abstract Model을 제시한다. 이렇게 함으로써 특정 allocator에 종속되지 않는 일반적인 디자인을 논의할 수 있다. 그리고 Threat Model 또한 제시한다. 4장에서는 자동화된 힙 익스플로잇 기법을 찾아내기 위해 겪어야 할 난제들을 살펴본다. 그리고 이러한 난제들을 어떻게 기술적으로 극복할 수 있을지에 대해 5장에서 풀이한다. 6장은 실제 구현을 AFL을 통해 어떻게 했는지에 간단히 언급하고 있으나 설명이 자세하지 않으므로 실제 github 소스코드를 참고하는 것이 좋을 듯하다. 7장은 ArcHeap을 통해 실제로 얻은 결과물을 다룬다. 5개의 새로운 형태의 힙 익스플로잇 기법을 설명한다. 그리고 다른 Heap Allocator들과 다른 운영체제 상황에서도 적용되는지 여부를 보여준다. 8장에서는 Evaluation을 다루며 기존 연구 중 유사 연구인 HeapHopper에 비해 어떤 점에서 ArcHeap이 더 우월했는지를 비교 분석한다. 그리고 PoC 코드 생성에서 사용된 delta-debugging 기법에 대해 간단히 설명한다. 9장은 Discussion으로 해당 연구의 한계점과 앞으로의 후속 방향에 대해 언급하며 10장은 관련된 연구 주제들을 다룬다. 11장은 결론이다.


2. Analysis of Heap Allocators 

2.1 Modern Heap Allocators 

Heap은 run-time 에 할당이 필요한 메모리 공간을 어떻게 관리할지가 관건이다. 대표적으로 malloc() 함수를 통해 새로운 메모리를 할당하고, free()함수를 통해 메모리를 해제한다. 그 밖에 calloc이나 realloc과 같은 추가 함수도 제공된다.

한편 Heap Allocator를 설계할 때에는 크게 3가지 측면의 고려 사항이 있다. Performance, Memory usage, Security 이다. 좋은 성능을 내기 위해서는 동작이 빨라야 하는데, Memory Usage를 고려하기 위해서는 fragmentation 발생을 최소화하기 위해 여러가지 작업이 수반되므로 결국 이 둘은 동시에 적당한 수준으로 만족시키기 위한 지점(a good balance between these two goals)을 찾아야 하는 것이 Heap Allocator 설계자들의 숙제이다.

거기에 추가적으로, 단순히 성능뿐만 아니라 '보안'도 고려해야 한다. 이미 Heap을 이용한 공격 기법이 많이 존재하기 때문이다. 이에 현대의 heap allocator을 분석해보니 대체적으로 아래와 같은 Security-related 설계 원리를 공통적으로 공유하고 있음을 알 수 있었다. 

  • binning: size-base groups/operations (e.g., caching the same size objects together)
  • in-place metadata: metadata before/after or even inside (e.g, putting metadata inside the freed region). Allocators place metadata near its chunk’s start or end for locality
  • cardinal data: no encoding, direct pointers and sizes(e.g., using raw pointers for linked lists).  Metadata in a chunk are either sizes or pointers, but not other random values

이러한 3가지 B, I, C 요소들은 실제로 다수의 Allocator들이 공통적으로 가지고 있다.

특히 Binning 과 같은 사항이 적용되어 있다고 가정함으로써 ArcHeap 의 탐색 공간을 획기적으로 줄일 수 있었다. 왜냐하면 binning size 를 예측할 수 있기 때문에 불필요한 부분에 대해서는 확인하지 않아도 되기 때문이다. Cardinal data와 In-place metadata는 random성 여부를 확정지을 수 있기 때문에 마찬가지로 가능성의 범위를 좁히는데 사용할 수 있었다.


2.2 ptmalloc2: glibc’s Heap Allocator 

ptmalloc2는 현재 리눅스의 glibc 기본 heap allocator이다. ptmalloc2의 Metadata는 아래와 같다.

출처: https://sourceware.org/glibc/wiki/MallocInternals

binning이란 메모리 관리를 효율적으로 하기 위해서 free된 chunck들을 비슷한 크기끼리 묶어서 관리하는 것이다. ptmalloc2의 binning은 fast bin, small bin, large bin, unsorted bin, tcache 등이 있으며 각각이 이루고자 하는 목적이 조금씩 다르며 여기에 따라 속도나 메모리 사용량이 다르다.

Consolidation 이란 '병합'으로, 해제(free)하려는 chunk의 앞, 뒤 chunk가 이미 해제되어 있을 때 발생한다. 이전 chunk의 해제 유무는 P(prev in use) 비트 값을 통해 파악한다. 


 2.3 Complex Modern Heap Exploits 

공격자는 heap의 metadata를 손상시키기위해 overflow등의 취약점을 이용할 수 있다. 그리고 heap의 API를 부적절하게 사용하는 예를 들어 double free같은 취약점도 가능하다. 그리고 이후 Arbitrary write와 같은 유용한 익스플로잇이 가능하도록 후속 작업을 개발해야 한다. 이러한 작업이 예전에는 그다지 어려운 일이 아니었으며 heap allocator의 구현에 상관없이 범용적으로 unsafe unlink 와 같은 공격을 수행할 수 있었다. 

그러나 현대의 heap allocator는 여러가지 조건을 검사하는 보안적 기능이 추가되어 있기 때문에, 이를 익스플로잇하기 위해서는 훨씬더 복잡하고 정교한 기술이 필요해졌다. 그래서 연구자들은 다양한 heap exploit techinique 들을 찾기 시작했으며 아래의 표로 정리할 수 있다. 

이 중 하단의 5개의 기법이 ArcHeap이 새롭게 발견한 것이다.


사례 : Unsafe unlink

Heap Exploitation Technique 중에서 가장 유명한 사례가 바로 unsafe unlink attack이다. 이는 heap allocator가 double-linked list로 구현되어 있으며 이의 unlink 과정을 공격하는 것이다. 

Heap의 meta 데이터들은 Oveflow를 이용하여 수정될 수 있다. 예를 들어 아래와 같은 코드를 생각해보자. p1과 p2가 할당된 후 p1의 내용이 overflow 되었으며 이후 p1이 free된다.

void *p1 = malloc(sz);
void *p2 = malloc(sz);

/* overflow on p1 */

free(p1);

이때 발생한 overflow에서 p2의 P(ㅔprev in use)값을 덮어썼다면, p2는 마치 free 된 것으로 간주될 수 있다. 이후 p1이 free될 때 p1과 p2의 consolidation을 유도한다. 이후 fd, bk포인터를 정리해주기 위해 p2에 unlink() 작업이 수행된다. 쉽게 말해 연속된 링크드 리스트 노드 중에서 가운데 있는 값을 빼주는 것과 동일한 작업이다.

그런데 앞서 overflow를 이용하여 p2의 내용을 임의로 바꾼 후 연결되는 fd, bk 포인터를 악의적인 행위를 할 수 있는 함수 포인터로 지정하게 된다면 control flow 를 탈취할 수 있다.

이런 방식의 취약점은 dlmalloc, ptmalloc2, windows allocator 모두에서 발생하였다. 이러한 공격을 막기 위하여 unlink 함수에 두가지 점검이 포함된 패치가 나왔다.

두개의 if 문이 추가되어 있음을 볼 수 있다. 이 때문에 공격자들은 이를 직접적으로 변경하기가 어려워졌다. 그럼에도 불구하고 보다 진보된 공격을 사용하면 이마저도 우회할 수 있다. 예를 들어 fake chunck 와 같은 방법으로 해당 조건을 만족시키도록 할 수 있기 때문이다. 이렇게 하면 비록 기존의 방법에 비해 익스플로잇이 복잡해지기는하지만 그럼에도 충분히 실현 가능한 버그가 된다.


3. Heap Abstract Model

이 장에서는 다수의 Heap allocator에서 범용적으로 사용하기 위하여, heap에 대한 추상화된 모델을 제시하고자 한다. 이 방법은 아래와 같은 기존 연구의 연장선에 있다.

  • M. Eckert, A. Bianchi, R. Wang, Y. Shoshitaishvili, C. Kruegel, and G. Vigna. HeapHopper: Bringing bounded model checking to heap implementation security. In Proceedings of the 27th USENIX Security Symposium (Security), Baltimore, MD, Aug. 2018.
  • D. Repel, J. Kinder, and L. Cavallaro. Modular synthesis of heap exploits. In Proceedings of the ACM SIGSAC Workshop on Programming Languages and Analysis for Security, Dallas, TX, Oct. 2017.

3.1 Abstracting Heap Exploitation  

heap exploit techinique를 분류할 때 첫째로는 버그의 종류, 둘째로는 해당 익스플로잇의 파급효과를 기준으로 정의할 수 있다.

1) Type of bugs : 어떤 버그를 통해
  • Overflow : 객체의 경계를 지나 write 작업 수행
    • Off-by-one : Overwriting the last byte of the next consequent chunk
    • Off-by-one NULL : Similar to the previous type, but overwriting the NULL byte
  • Write-after-free : 해제된 객체를 다시 사용
  • Arbitrary free : 임의의 포인터를 해제하려는 경우
  • Double free : 이미 해제된 객체를 다시 해제하려는 경우
2) Impact of exploitation : 어떤 악성 행위를 하려는지?
  • Arbitrary-chunk : Hijacking the next malloc to return an arbitrary pointer of choice.
  • Overlapping-chunk : Hijacking the next malloc to return a chunk inside a controllable (e.g., overwritable) chunk by an attacker.
  • Arbitrary-write : Developing the heap vulnerability into an arbitrary write (a write-where-what primitive)
  • Restricted-write : Similar to arbitrary-write, but with various restrictions (e.g., non-controllable “what”, such as a pointer to a global heap structure)

이와 같은 구분을 통해, 예를 들어 앞서 설명한 unsafe unlink는, 공격자가 "heap overflow"를 통해서 "arbitrary write"를 시도하였다. 그 결과 code pointer를 변조하여 제어 흐름을 탈취하게 된 것으로 이해할 수 있다.


3.2 Threat Model 

Heap Exploitation Technique를 일반적으로 설명하기 위하여, 공격자가 수행할 수 있는 '합법적인 행위(legitimate action)'를 명확히 정의해보자.

  1. 공격자는 임의 크기의 객체를 할당(malloc)할 수 있으며, 각 객체를 순서에 상관없이 해제(free)할 수 있다.
  2. 공격자는 합법적인 메모리 영역(페이로드 부분 또는 전역 메모리 공간)에 임의의 데이터를 쓸 수 있다. 
  3. 공격자가 단일 유형의 버그만을 사용한다고 가정한다. (실제로는 다양한 상황에서 여러가지를 여러번 사용할 수도 있으므로 오히려 공격자에게 더 유리한 가정이다).


4. Technical Challenges



전통적인 Fuzzing 방식을 이 문제에 바로 적용하기에는 다음과 같은 3가지 난제가 존재한다.

  1. heap 취약점을 성공적으로 발생시키기 위해서는 구체적인 데이터들의 명확한 순서로 배치되어야 한다. 이러한 방식을 풀이하기 위해서 앞선 Heaphopper 등의 연구는 소위 symbolic exectuion 기법을 사용하곤 했는데, 여기에는 경로 폭발(path exploision problem) 문제가 존재한다. 즉 탐색 범위가 너무 넓어서 길을 찾지 못하는 현상이다.
  2. heap exploitation이 가능한지 여부를 빠르게 확인할 수 있는 평가 방법 필요. 때문에 전체 익스플로잇(spawning a shell)을 평가하는 것이 아니라, impact of exploitation 조건을 만족하는(AC, OC, AW, RW) 경우에 대해 빠르게 평가할 수 있도록 함.
  3. fuzzer가 생성한 test case들은 보통 중복이 많이 발생하기도 하고, 이해하기 어려운 경우가 많음. 이런 결과를 결국 사람이 다시 분석하는데 무시할 수 없는 시간과 노력이 필요.

이러한 문제를 해결하는 방법을 5장에서 제시한다. 요약하자면 1)은 앞서 설명한 2장과 3장의 방법처럼 모델링을 통해 탐색 공간을 줄이는 것이다. 2)는 Shadow memory를 통해 arbitrary write와 restricted write 등을 탐지하는 방법을 썼다. 3)은 Delta-Debugging이라는 방법을 통해 보완했으며 84.3% 수준으로 간소화할 수 있었다.


5. Autonomous Exploration for Finding Heap Exploitation Techniques  

5.1 Overview

기본적인 Fuzzing 방법론을 따라, test generation, crash detection, test reduction 등을 수행하지만 특별히 heap exploitation 에 초점을 맞추도록 했다. 생성되는 테스트 케이스는 사전에 모델링으로 정의된 일련의 heap 관련 함수 호출 동작의 모음이다(만약 specification을 제공하지 않으면, ArcHeap 은 가능한 모든 경우의 수를 탐색한다). ArcHeap 의 전체 동작은 대략적으로 아래 그림과 같다.


5.2 Generating Actions for Abstract Heap

Heap Action에 알맞게 테스트 케이스를 만들어야 한다. 여기서 Action 이란 Allocation, Free, Buffer & Heap write, bug invocation 이 포함된다. 이 과정에서 탐색 공간을 줄이기 위해 ArcHeap은 최신 allocator들의 설계 원리에서 차용한 각 추상화 단계들을 공식화하여 처리한다. 


5.3 Detecting Techniques by Impact  

퍼징이 수행되는 동안, ArcHeap은 해당 테스트 케이스가 impacts of exploitation에 해당되는지 여부를 평가한다. 즉 퍼징에서 crash 여부를 파악하는 것과 유사하다. 

이 과정은 Shadow memory 기법을 사용하여 탐지할 수 있도록 했다. 그 과정을 다음 그림의 예시로 살펴보자.

① 처음 allocation이 이루어진 후 ArcHeap은 heap container와 shadow memory를 설정함

② 2번의 allocaiton 이 발생하였으며, 이 상황을 마찬가지로 알맞게 갱신

③ deallocatoin이 발생한 후 p[1]이 변경되었다(ptmalloc2의 unlink 함수 동작에 의해). 이 시점에서 ArcHeap이 기존의 Heap Container에 비해 shadow memory가 상이해졌음을 알 수 있다. 이 과정은 deallocation 중에 발생했으므로 발생할 수 있는 exploitatoin은 heap container에서의 restricted writes로 볼 수 있다.

④ 이 경우에는 heap container에서의 arbitrary write가 발생할 수 있다.

⑤ global buffer에 대하여 arbitrary write 상황을 야기할 수 있다.


5.4 Generating PoC via Delta-Debugging 

ArcHeap이 만약 새로운 익스플로잇을 찾아냈다면, 해당 Heap Action을 최소화(action 중 essential set만 추출)한 후 PoC 코드를 생성한다. 이 최소화 과정은 사후 분석에 있어 굉장히 유용하다. 뿐만 아니라 실험 결과에 따르면 오탐(False Positive)이 발생하지 않는다.


6. Implementation 

위의 내용을 직접 구현하기 위해, American Fuzzy Lop (AFL)을 개조하였다. heap action generator 가 무작위로 heap actions 을 생성하고 이를 실행하는 것이다. 퍼저는 impact of exploitation인 상황을 발견하면 사용자 정의 시그널인 SIGUSR2을 발생시킨다. 이를 처리할 수 있도록 AFL의 소스코드를 수정하여 SIGUSR2의 시그널을 crash로 간주하도록 하고, 그 외 signal(segmentation fault) 등은 무시하도록 변경하였다.

자세한 구현은 아래 github에서 확인할 수 있다.

GitHub - sslab-gatech/ArcHeap: ArcHeap: Automatic Techniques to Systematically Discover New Heap Exploitation Primitives
ArcHeap: Automatic Techniques to Systematically Discover New Heap Exploitation Primitives - sslab-gatech/ArcHeap
GitHub


7. Applications 

ArcHeap을 통해 ptmalloc2을 대상으로 실험한 결과 기존의 다른 연구에 비해 참신성 있는 결과를 얻을 수 있었다. 

7.1 New Heap Exploitation Techniques 

  • Unsorted bin into stack (UBS)
  • House of unsorted einherjar (HUE)
  • Unaligned double free (UDF)
  • Overlapping chunks using a small bin (OCS)
  • Fast bin into other bin (FDO)

7.2 Different Types of Heap Allocators 

기존의 연구들은 dlmalloc이나 ptmalloc에만 집중했지만, 본 연구에서는 musl이나 je-malloc, tcmalloc, Microsoft mimalloc, LLVM Scudo 등에 대해서도 실험해보았다. 뿐만 아니라 보안 관점에서 설계된 DieHarder, Mesh, FreeGuard, Guarder 등에서도 적용해보았다. LD_PRELOADD를 사용하여 각각의 allocator를 호출할 수 있도록하였다. 24시간동안 실험한 결과 10개 중 Scudo, FreeGuard, Guarder를 제외한 나머지 7개에서 exploit technique를 찾을 수 있었다. 

특히 기존 유사 연구인 HeapHopper와 비교했을 때 HeapHopper가 기호실행을 사용함에 따라 수행하기 어려웠던 한계를 뛰어넘을 수 있었다. 

Heap Allocator 개발자의 관점에서도 ArcHeap을 통해 보안 테스트를 수행해볼 수 있도록하는 장점을 제공하기도 한다. 실제로 mimalloc과 DieHarder 가 패치할 수 있도록 도움을 주기도 했다.

7.3 Evolution of Security Features

우분투 운영체제의 경우 12.04(libc 2.15), 14.04(libc 2.19), 16.04(libc 2.23), 18.04(libc 2.27)에 따라 그 변화된 흐름을 테스트해보았다. 일반적으로 새로운 버전에 새로운 보안 기능이 추가되었을 것으로 기대하기 마련이다. 각 버전에 대해 차분 테스팅(differential testing)을 수행해보았다. 이런 과정에서 다음과 같은 재미있는 사실을 발견했다.

  1. 새로운 보안 패치는 구버전의 ptmalloc2에서 사용되던 exploit tech를 효과적으로 완화했다.
  2. bionic(18.04)의 내부 설계 변경은 기존 버전의 PoC 코드를 모두 동작하지 못하게 막았다. 그런데 이것은 더 '안전'해졌다는 것은 아니다. 왜냐하면 새롭게 추가된 tcahe는 오히려 더 쉽게 exploit 될 수 있기 때문이다.
  3. tcache는 성능을 최우선 목적으로 설계되었기 때문에 보안 관점에서의 고려를 다소 놓친 것 같다. 공격 자체를 더 쉽게 했을 뿐만 아니라, 새로운 공격 기법이 출현하도록 유도한 것이다.


8. Evaluation 

이번 장에서는 다음 3가지 요소를 기준으로 본 논문의 결과물을 평가한다.

  • 지금까지의 동향 중 가장 좋은 것으로 알려진 HeapHopper와 비교했을 때, 얼마나 '새로운 HETs'를 효과적으로 발견하였는가?
  • ArcHeap은 얼마나 보안 관련 문제들을 충분히 많이 찾아내는가?
  • Heap 동작의 다양한 중복을 제거하는데 있어 delta-debugging 방법을 적용한 것은 과연 잘한 선택이었나?

이를 실험을 통해 입증하기 위해, Intel Xeon E7-4820 CPU 및 256GB RAM의 장비를 동원하였다. 

8.1 HeapHopper 와의 비교

HeapHopper는 이미 '기존에 존재하는 것으로 알려진' 취약점을 각 Allocator구현체에서 정확하게 찾아내는 것을 목적으로 했기 때문에 ArcHeap과는 접근 방법이 사뭇 다르다. 특히 HeapHopper는 복잡한 모델링을 수행하고 이를 풀 때 기호실행 기법을 사용했기 때문에 많은 계산량을 필요로 한다는 단점이 있으며 '알려진' 취약점을 찾는데에 목적이 있다. 하지만 ArcHeap은 지금까지 알려지지 않은 새로운 유형의 Hets를 찾을 수 있었다.

8.2 Security Check Coverage 

ptmalloc2에서 제공되는 다양한 보안 점검 기능이 있으며 내용은 아래 표와 같다.

각 체커들을 얼마나 많이 발동시켰을까? 24시간동안 ArcHeap을 구동한 후 확인해보니 21개 중 C2, C4, C21을 제외한 18개를 발생시켰다. 


8.3 Delta-Debugging-Based Minimization 

델타 디버깅을 사용하여 중복된 동작을 84.3%로 효과적으로 줄일 수 있었다.


9. 본 연구의 한계점 

  • Incompleteness: HeapHopper는 완벽한 모델을 기반으로 했기에, HeapHopper에 비해서는 정확도가 낮다. 다만 HeapHopper는 확장이 용이하지 않다는 것에서, ArcHeap이 상대적으로 낫다.
  • Overfitting: 범용성에 초점을 맞추다보니, 특정 유형의 Allocator에서는 적합하지 않을 수 있다.
  • Scope: 이 연구는 실제로 특정 Application에서 익스플로잇을 수행해 쉘을 취득하는 등의 목적으로 진행한 것이 아니다. 다만 Heap Exploitation Tech의 (새로운) 유형을 찾아내는 데 목적이 있다. 만약 익스플로잇까지 찾아내려면 연구의 범위를 AEG(Automatic Exploit Generation)으로 확장해야 한다. 그리고 본 연구에서는 user mode allocator만을 고려했지만 범위를 Kernel mode로 확장한다면 보다 고심해야할 지점이 많아질 것이다.


10. 관련 연구 

이 연구는 아래와 같은 연구들을 참고하면 좋다.

  • AEG : 이런 연구는 CGC대회를 위해 많이 사용되었다. Heap을 대상으로 한 연구도 간혹 있었지만 대부분 구버전의 ptmalloc2을 대상으로 하였다.
  • Fuzzing : 자동화 취약점 탐지 중 가장 많이 사용되는게 퍼징일 것이다. 다만 ArcHeap은 퍼징의 search space를 어떻게 줄일 것인가에 많은 고민을 했다.


11. Conclusion

본 논문에서는 새로운 종류의 힙 취약점 유형을 퍼징 방식으로 자동으로 찾는 ARCHEAP 도구를 제시하였다. ARCHEAP은 퍼징에 소요되는 탐색 공간을 줄이기위하여 두가지 아이디어를 사용했다. 현대의 힙 구현의 공통적인 사항을 추상화하고, 힙 익스플로잇 가능성을 신속하게 추정할 수 있도록 한 것이다. 이를 리눅스의 기본 힙 할당자인 ptmalloc2 및 10 개의 할당자들에 대해 적용해보니 ARCHEAP는 할당자의 특정 구현에 종속적이지 않게 다수의 할당자들 대상으로 효과적으로 새로운 힙 취약점 유형을 찾아낼 수 있음을 확인했다.

Software Security Engineer

Wanna support CPUU's work?