[요약 & 1장] Fuzzing: Art, Science, and Engineering 번역

https://arxiv.org/pdf/1812.00140.pdf

Abstract

Among the many software vulnerability discovery techniques available today, fuzzing has remained highly popular due to its conceptual simplicity, its low barrier to deployment, and its vast amount of empirical evidence in discovering real-world software vulnerabilities.

다양한 취약점 탐지 기술중에, 퍼징은 큰 인기를 끌고있다. 왜냐하면 개념적인 단순함, 개발의 낮은 진입장벽, 엄청난 양의 real-world 소프트웨어 취약점 발견사례들(경험적 증거) 때문이다.

 

At a high level, fuzzing refers to a process of repeatedly running a program with generated inputs that may be syntactically or semantically malformed.

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

 

While researchers and practitioners alike have invested a large and diverse effort towards improving fuzzing in recent years, this surge of work has also made it difficult to gain a comprehensive(포괄적인) and coherent(일관성있는) view of fuzzing.

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

 

To help preserve and bring coherence to the vast literature of fuzzing, this paper presents a unified, general-purpose model of fuzzing together with a taxonomy(분류체계) of the current fuzzing literature.

이 논문은 퍼징의 방대한 문헌을 보존하고 일관성을 제공(bring coherence)하기 위해 현재 퍼징 문헌의 분류체계와 함께 퍼징의 통일된 범용 모델을 제시한다.

 

We methodically explore the design decisions at every stage of our model fuzzer by surveying the related literature and innovations in the art, science, and engineering that make modern-day fuzzers effective.

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

*설계 결정 : 퍼저 효율적으로 제작하기위해 분야 / 단계에 따라 고려해야하는 사항들.

 

1. INTRODUCTION

Ever since its introduction in the early 1990s, fuzzing has remained one of the most widely-deployed techniques to discover software security vulnerabilities.

1990년대 초 도입된 이후 퍼징은 소프트웨어 보안 취약점을 발견하기 위해 가장 널리 보급된 기술 중 하나로 남아 있다.

 

At a high level, fuzzing refers to a process of repeatedly running a program with generated inputs that may be syntactically or semantically malformed.

high level에서 퍼징은 구문적 또는 의미적으로 잘못된 형식의 입력을 생성하고 이 입력을 이용해서 프로그램을 반복적으로 실행하는 과정을 말한다.

 

In practice, attackers routinely deploy(효율적으로 사용하다) fuzzing in scenarios such as exploit generation and penetration testing;

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

 

several teams in the 2016 DARPA Cyber Grand Challenge (CGC) also employed fuzzing in their cyber reasoning systems.

2016년 DARPA Cyber Grand Challenge(CGC)의 여러 팀도 사이버 추론 시스템에 퍼징을 사용했다.

 

Fueled by these activities, defenders have started to use fuzzing in an attempt to discover vulnerabilities before attackers do.

이러한 활동에 힘입어 방어자들은 공격자보다 먼저 취약점을 발견하기 위해 퍼징을 사용하기 시작했다.

*fuel : 연료를 공급하다

**fueled by ~ : ~에 의해 힙 입다. (~에 의해 부채질되다.) 

 

For example, prominent vendors such as Adobe [1], Cisco [2], Google [61], [5], [15], and Microsoft [38], [8] all employ fuzzing as part of their secure development practices.

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

 

More recently, security auditors [237] and open-source developers [4] have also started to use fuzzing to gauge the security of commodity software packages and provide some suitable forms of assurance to end-users.

최근에는 보안 감사업체[237]와 오픈 소스 개발자[4]도 일반 소프트웨어 패키지의 보안을 측정하고 최종 사용자에게 적절한 형태의 보증(assurance)을 제공하기 위해 퍼징을 사용하기 시작했다.

*assurance : 확언, 장담, 확약, 자신감

 

The fuzzing community is extremely vibrant. As of this writing, GitHub alone hosts over a thousand public repositories related to fuzzing [86].

퍼징 커뮤니티는 매우 활기차다. 이 글에서 GitHub만 해도 퍼징과 관련된 1,000개 이상의 공용 저장소를 호스팅하고 있다[86].

 

And as we will demonstrate, the literature also contains a large number of fuzzers (see Figure 1 on p. 5) and an increasing number of fuzzing studies appear at major security conferences (e.g. [225], [52], [37], [176], [83], [239]).

그리고 우리가 보여줄 것처럼, 문헌에는 퍼저도 다수 포함되어 있으며(페이지 5의 그림 1 참조), 점점 더 많은 퍼저 연구가 주요 보안 회의에 등장한다(예: [225], [52], [37], [176], [83], [239]).

 

In addition, the blogosphere is filled with many success stories of fuzzing, some of which also contain what we consider to be gems that warrant a permanent place in the literature.

게다가 blogosphere(블로그 세상. 개인들이 글을 올리는 것들을 나타내는 고유명사)는 퍼징의 많은 성공 스토리로 가득 차 있으며, 그 중 일부는 우리가 학계에서 영구적인 지위를 가질 보석이라고 여기는 귀한자료도 포함하고 있다.

 

Unfortunately, this surge of work in fuzzing by researchers and practitioners alike also bears a warning sign of impeded progress. For example, the description of some fuzzers do not go much beyond their source code and manual page.

아쉽게도, 퍼징에서 이러한 작업의 급증(관심이 급증하며 자료들이 쏟아지고 있는 상황은)은 오히려 더 빠른 발전에 방해가 되는 문제가 될 수도 있다는 신호를 보여준다. 예를 들어, 일부 퍼저에 대한 설명은 소스 코드와 매뉴얼 페이지를 크게 벗어나지 않는다. 무슨 이야기 냐면, 너무 빠르게 발전하는데에 집중할 수록 그냥 사용법에만 집중할 뿐 이 퍼저가 설계될때 어떤목적으로 설계되었는지를 자세히 설명하지않는다 (design decisions of fuzzer에 대해 설명하지 않고 source code and manual page에 대한 설명에 그친다.) 

 

As such, it is easy to lose track of the design decisions and potentially important tweaks(기계 시스템에 대한 약간의 수정) in these fuzzers over time. Furthermore, there has been an observable(관찰할 수 있는) fragmentation(파편화) in the terminology used by various fuzzers.

따라서 시간이 지남에 따라 퍼저에 대한 설계 결정 및 잠재적으로 중요한 조정 사항을 놓치기 쉽다. 게다가, 다양한 퍼저에 의해 사용되는 용어에는 관측 가능한 분열된 단어들(observable fragmentation)도 있었다. 같은 뜻을 가지고 있음에도 통일되지않고 쓰이는다른 단어들이 많이 있었다.

 

For example, whereas AFL [231] uses the term “test case minimization” to refer to a technique that reduces the size of a crashing input, the same technique is called “test case reduction” in funfuzz [187].

예를들어서, AFL이라는 퍼저는 크래쉬 인풋을 발견했을때, 그 인풋의 사이즈를 줄이기위한 기술을 “test case minimization” 이라고 부르는데, 똑같은 기술을 funfuzz라는 퍼저는 “test case reduction” 이라고 부른다. 이렇듯 퍼징 분야에서 용어의 통일이 안되어있다. 이러한 현상을 이 논문에서는 fragementation in the terminology이라고 칭한다.

 

At the same time, while BFF [49] includes a similar-sounding technique called “crash minimization”, this technique actually seeks to minimize the number of bits that differ between the crashing input and the original seed file and is not related to reducing input size.

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

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

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

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

 

This makes it difficult, if not impossible, to compare fuzzers using the published evaluation results. We believe such fragmentation makes it difficult to discover and disseminate(보급,전파하다) fuzzing knowledge and this may severely hinder the progress in fuzzing research in the long run.

따라서 공개된 퍼저 사용 결과들을 사용하여 어떤 퍼저가 더 좋은지 비교하고 연구하는 것이 아예 불가능한건 아니지만, 굉장히 어렵다. 우리는 이러한 분열된 단어들(fragmentation) 가 퍼징 지식을 발견하고 전파하는 것을 어렵게 하고, 장기적으로 퍼징 연구의 진보를 심각하게 방해할 수 있다고 믿는다.

 

Due to the above reasons, we believe it is prime time to consolidate and distill the large amount of progress in fuzzing, many of which happened after the three tradebooks on the subject were published in 2007–2008 [79], [203], [205].

상기의 이유로, 우리는 지금이 퍼징의 많은 발전 과정들을 통합하고 분류할 수 있는 황금기라고 생각한다. 퍼징에 대한 많은 연구들은 2007-2008년에 이 주제에 관한 3권의 서적이 출판된 후에 일어났다[79], [203], [205].

 

As we attempt to unify the field, we will start by using §2 to present our fuzzing terminology and a unified model of fuzzing.

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

 

Staying true to the purpose of this paper, our terminology is chosen to closely reflect the current predominant usages, and our model fuzzer (Algorithm 1, p. 3) is designed to suit a large number of fuzzing tasks as classified in a taxonomy of the current fuzzing literature (Figure 1, p. 5).

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

 

With this setup, we will then explore every stage of our model fuzzer in §3–§7, and present a detailed overview of major fuzzers in Table 1 (p. 6).

이 셋업(모델 설계, 본 논문의 연구방향 및 방법설정) 들과 함께, 단락3 – 단락7에 있는 우리의 모델 퍼저들의 모든 단계를 살펴보고 표 1의 주요 퍼저에 대한 자세한 개요를 제시한다(p. 6).

 

At each stage, we will survey the relevant literature to explain the design choices, discuss important trade-offs, and highlight many marvelous(놀라운, 믿기어려운, 신기한, 기묘한, 우수한) engineering efforts that help make modern-day fuzzers effective at their task.

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