요약

퍼저의 정의

다양한 취약점 탐지 기술중에, 퍼징은 큰 인기를 끌고있다.

왜냐하면 개념적인 단순함, 개발의 낮은 진입장벽, 엄청난 양의 real-world 소프트웨어 취약점 발견사례들(경험적 증거) 때문이다.

1. 개념적 단순함 : 반복적으로 프로그램에 오류가 날때까지 인풋을 넣는다.
2. 낮은 개발 진입장벽 : 계속해서 인풋을 프로그램에 던져주는 프로그램. 딱히 복잡한 알고리즘이 필요하지않다. 또 오픈소스들도 많아서 쉽게 다운받아 사용하고 수정할 수도 있다.
3. 자동으로 취약점을 탐지하는 기술이니 당연히 손으로 찾는경우(소스코드 오디팅) 보다 많은 버그를 찾을 수 있다.

퍼징은 생성된 인풋들을 이용해서 계속해서 프로그램을 실행하는 과정을 이야기한다. 그럼과 동시에 의도적으로 문법적이나 의미적론으로 (syntactically or semantically) 잘못된 형식의 인풋들을 생성해 비정상적인 프로그램 실행을 유도할 수 하는 과정이다.

*퍼징은 단순히 프로그램에 엄청난 인풋을 넣어보는 프로그램에 불과한데, 이게 왜 자동 취약점 탐지 도구일까??

(그림 1 - 프로그램의 동작구조)

모든 프로그램은 인풋과 아웃풋이 있다.

여기서 핵심은 프로그램의 동작은 인풋에 의해 결정된다는 것이다.

이 문장이 컴퓨터 공부를 처음 시작한 사람에게는 굉장히 낯설 수 있다.

프로그램의 동작이 인풋에 의해 결정되지 않는 프로그램도 물론있다.

그런데 그런경우 거의 실생활에서는 쓰이지않는 프로그램일 경우가 많다.

예를들어 다음과 같은 프로그램이다.

#include<stdio.h>
int main(){
	printf("hello world!");
}

모든 프로그램의 존재이유는 유저와의 상호작용을 위함이다.

우리가 구글을 사용할때 검색창을 클릭하고 검색어를 입력하고 그에따라 적절한 검색결과를 알려준다던지,

게임을 할때에 마우스 클릭에 따라 캐릭터가 움직이고 스킬을 사용한다던지,

모든 프로그램의 동작은 유저의 인풋에 기반하여 달라진다.

이에 비정상적인 프로그램 실행루틴을 유도하여 개발자의 의도에 반하는 프로그램 행위와 crash를 유발하는 유일한 방법은 비정상적인 인풋을 넣는 방법뿐이다.

(물론 해당 프로그램의 코드를 지워버리거나 내맘대로 바꿔버리면 프로그램을 망쳐버릴 수 있다. 다만 내가 해당 프로그램의 코드를 통제할 수 있는 상황은 해킹의 관점에서 의미있는 상황이 아니다. 예를들어 현재 서비스 중인 구글 서버프로그램을 수정하고 전세계에 배포할 수 있다면 퍼징과같은 기술을 사용할 필요가 없다. 그렇다고해서 오픈소스로 공개된 프로그램들은 내가 맘대로 코드도 바꿀 수 있는데 뭐냐? 라고 할 수 있겠지만 아직까지 해킹과 보안의 프로세스에 대한 이해가 미비해서 그렇다. 현재 전세계에 서비스 중인 프로그램과 그냥 내가 로컬에서 실행하는 프로그램 사이에는 당연히 요구되는 보안성에 대한 차이가 있다.)

퍼징 연구의 동향

연구자와 실무자 모두 최근 몇 년 동안 퍼징을 개선하기 위해 크고 다양한 노력을 기울였지만, 이러한 작업의 급증은 퍼징에 대한 포괄적이고 일관성 있는 관점을 얻는 것을 어렵게 만들었다.

*포괄적이고 일관성 있는 관점을 얻는 것을 어렵게 만들었다는게 무슨뜻일까?

⇒ 뒤에 좀 더 자세히 나오지만, 지금까지 퍼징이 큰 관심을 받으며 엄청나게 발전하였는데 단어가 통일되지 않는 문제(fragmentation)등 학문으로서 조금 체계적이지 못한 부분들이 많았다. 결국 이 논문에서 퍼징에 대한 포괄적이고 일관성있는 관점을 얻을 수 있게끔 해주겠다는 것(본 논문의 정체성 / 목표)라는 것을 소개하는 부분이다.

본 논문의 목표

이 논문은 퍼징의 방대한 문헌을 보존하고 일관성을 제공(bring coherence, 앞서 언급한 포괄적이고 일관성 있는 관점을 얻는 것을 어렵게 만드는 현재 실태를 개선)하기 위해 현재 1. 퍼징 문헌의 분류법과 함께 2. 퍼징의 통일된 범용 모델을 제시한다.

현대 퍼저를 만드는 예술, 과학, 엔지니어링 관련 문헌과 혁신을 조사하여 퍼저를 효과적으로 만들기위해 퍼저의 모든 단계에서 고려해야하는 설계 결정들에 대해서 체계적으로 탐구할 예정이다.

⇒ 퍼저 효과적으로 만들때 분야 / 단계에 따라 어떤 것들을 고려해야하는지 정리해보겠다.

1. INTRODUCTION

퍼저의 정의

1990년대 초 도입된 퍼징은 소프트웨어 보안 취약점을 발견하기 위한 기술이다.

high level에서 퍼징은 구문적 또는 의미적(syntactically or semantically)으로 잘못된 형식(⇒ 프로그램의 오류를 발생시킬 법하게 만들어진)으로 생성된 인풋으로 프로그램을 반복적으로 실행하는 과정을 말한다.

실제로 공격자는 익스플로잇 생성(exploit generation) 및 침투 테스트와 같은 시나리오에서 퍼징을 많이 사용한다.

또한 방어하는 입장에서도 공격자보다 먼저 취약점을 발견하고 미리 고치기 위해서 퍼징을 사용하기 시작했다.

예를 들어 Adobe, Cisco, Google 및 Microsoft와 같은 주요 벤더는 모두 보안 개발 관행(secure development practices)의 일부로 퍼징을 채택하고 있다.

최근에는 보안 감사업체와 오픈 소스 개발자도 일반 소프트웨어 패키지의 보안을 측정하고 최종 사용자에게 적절한 형태의 보증(assurance ⇒ 해당 프로그램은 보안적인 결함이 없음을 증명)을 제공하기 위해 퍼징을 사용하기도 한다.

또 퍼징 커뮤니티는 매우 활기차고 GitHub에도 퍼징과 관련된 레퍼지토리들이 굉장히 많다.

본 논문의 목표

1. 퍼징 용어 통일

퍼저에 대한 폭발적인 발전과 연구들이 쏟아져 나왔지만, 시간이 지남에 따라 이러한 퍼저에 대한 설계 결정 및 잠재적으로 중요한 조정 사항을 놓치기 쉬워졌다. 게다가, 다양한 퍼저에 의해 사용되는 용어에는 관측 가능한 분열된 단어들(fragmentation)도 있었다.

⇒ 급하게 발전하다보니, 학문적으로 정립될 여유가 많이 없었음.

예를들어서, AFL이라는 퍼저는 크래쉬 인풋을 발견했을때, 그 인풋의 사이즈를 줄이기위한 기술을 “test case minimization” 이라고 부르는데, 똑같은 기술을 funfuzz라는 퍼저는 “test case reduction” 이라고 부른다.

⇒ 이렇듯 퍼징 분야에서 용어의 통일이 안되어있다. 이러한 현상을 이 논문에서는 분열된 단어들(fragmentation)이라고 칭함.

동시에 BFF라는 퍼저는 “crash minimization”이라고 해서 아까 이야기한 test case minimization이랑 유사해보이는 기술을 포함하고 있는데, 이 기술은 사실 실제로 크래시 입력과 원래의 시드 파일 사이에 다른 비트수를 최소한으로 만드는 것에 집중하고 있는 기술이라 엄밀히 말하면 입력사이즈 감소와는 관계가 없다.

⇒ BFF의 crash minimization : 크래쉬 인풋과 해당 크래쉬를 발생시킨 시드파일 사이 다른 비트수 최소화가 목표. 입력사이즈 감소와는 관계가 없음

⇒ AFL와 funfuzz의 test case minimization / test case reduction : 크래쉬 인풋의 크기를 줄이는 기술.

⇒ 이렇듯 용어가 통일되지 않고, 완벽히 정립되지 않아서 혼란을 많이 야기한다.

따라서 공개된 평가 결과들을 사용하여 객관적으로 퍼저의 성능을 비교하는 것이 불가능하지는 않더라도 어려운 실정이다. 본 논문에서는 이러한 분열된 단어들(fragmentation)이 새로운 지식을 발견하고 전파하여 학자들끼리의 의사소통을 어렵게 하고, 장기적으로 fuzzing 연구의 진보를 심각하게 방해할 수 있다고 생각한다.

통일되지 않은 용어로 의사소통이 어려움은 물론 퍼저의 설계 결정(design decisions of fuzzer)을 설명할때에도 어려움이 있다.

2. 퍼저 용어 및 통합 모델 제시 방법

앞서 말했듯이, 퍼징에서 이러한 작업이 급증(관심이 급증하며 자료들이 쏟아지고 있는 상황)은 오히려 발전에 문제가 있다.

예를 들어, 일부 퍼저에 대한 설명은 소스 코드와 매뉴얼 페이지를 크게 벗어나지 않는다.

⇒ 본인들의 연구를 정당화하기 위함. 그니까 점점 발전할수록 그저 사용법에만 집중해서 빠르게 설명하고 넘어갈뿐 학술적으로 이 퍼저가 설계될때 어떤 목적으로, 어떤 의미를 가지고 설계되었는지를 자세히 설명하지않음 (이 논문의 표현으로 design decisions of fuzzer) ⇒ 그래서 우리가 design decision 들을 설명해주겠다!

이 논문의 목적에 충실하기 위해 우리의 용어는 현재의 주요 용도를 면밀히 반영할 수 있는 것들로만 선택되었으며, 우리의 모델 퍼저 알고리즘은 현재 퍼징 문헌 분류법에 분류된 많은 퍼징 작업에 적합하도록 설계되었다.

각 단계에서 관련 문헌을 조사하여 설계 선택(design choices)에 대해 설명하고, 중요한 트레이드오프를 논의하며, 현대의 퍼저를 효과적으로 활용하기 위한 많은 놀라운 엔지니어링 노력을 살펴본다.

이 분야 통일(unify the field : fragmentation을 해결하면 달성할 수 있는 목표. 난잡한 지금 상태를 좀 통일하겠다는 뜻으로 보임)을 위해 단락 2에서는 퍼징 용어 및 퍼저 통합 모델을 제시한다.