2 SYSTEMIZATION, TAXONOMY, AND TEST PROGRAMS

“fuzz”라는 용어는 본래 “타겟 프로그램이 소비(consumed) 할 랜덤 문자열 스트림을 생성하는” 프로그램을 나타내기위해 만들어졌다. 즉, 취약점 탐지와는 무관하게 프로그램에 넣을 인풋들을 랜덤으로 생성하는 프로그램을 나타내는 단어가 "fuzz"였다.

이후로 “fuzz”의 개념과 동작 즉, fuzzing은 다양한 맥락에서 등장했다.

동적 심볼릭 익스큐션, 문법기반 테스트 케이스 생성, 권한 테스팅, 동작 테스팅, 복잡도 테스팅, 커널 테스팅, 디펜던시 표현 테스팅, 함수 검출, 소프트웨어 견고성 평가, 익스플로잇 개발, GUI 테스팅, 시그니처 생성 그리고, 침투(penetration) 테스팅 등등 다양한 기술과 개념들이 fuzzing이라는 개념과 동작을 설명하기 위해 등장했다.

⇒ 대충 동적으로 프로그램을 실행한 뒤 동작을 어떻게 하는지(실행 결과가 어떠한지) 지켜보는 기술들을 나타내는 의미로 fuzzing이라는 단어가 사용됐다.

본 논문에서는 퍼징에 관한 방대한 문헌으로부터 지식을 체계화하기 위해서, 최근에 많이 사용된 사례에서 뽑아낸 퍼징관련 용어들을 소개할 예정이다.

2.1 Fuzzing & Fuzz Testing

직관적으로, 퍼징이라는 것은 “fuzz inputs”을 넣어 테스트용 프로그램(PUT)을 실행하는 작업이다.

fuzz input은 PUT가 예상하지 못할 수 있는 입력, 즉 PUT 개발자에 의해 의도하지 않은 동작을 트리거할 수 있는 입력이라고 간주한다.

이 아이디어를 이용해서 본 논문에서는 퍼징이라는 용어를 다음과 같이 정의한다.

Definition 1(Fuzzing).

Fuzzing is the execution of the PUT using input(s) sampled from an input space (the “fuzz input space”) that protrudes the expected input space of the PUT.

정의 1(Fuzzing) : Fuzzing은 PUT의 예상되는 입력 공간을 벗어나는 입력 공간("퍼지 입력 공간")에서 뽑아낸 입력을 사용하여 PUT를 실행하는 것이다. (그로써 의도하지 않은 동작을 트리거하는게 목표)

⇒ input(s) vs input spcae(”fuzz input space”) vs expected input space of the PUT

• input(s) : 프로그램에 들어가는 입력들
• input spcae(”fuzz input space”) : 의도하지 않은 동작을 트리거하기위해 프로그램에 넣어보려 대기중인 인풋들
• expected input space of the PUT : PUT을 개발할때 들어올 것이라고 예상했던 인풋들 (정상적인 동작을 하는 인풋들)

⇒ protrudes the expected input space of the PUT : 예상했던 입력들을 벗어나게끔 하는

⇒ 의도치 않은 동작을 유도하는

이 정의에 대해 세가지 정도 이야기를 해보면

First, although it may be common to see the fuzz input space to contain the expected input space, this is not necessary—it suffices for the former to contain an input not in the latter.

첫째, fuzz input space가 정상적인 동작을 하는 PUT의 인풋영역(the expected input space of PUT)을 포함한다고 보는게 일반적일 수있지만, 꼭 그럴필요는 없다. 전자(fuzz input space)가 후자(expected input space)에 없는 입력을 포함하는 것도 충분하다.

그니까 퍼징을 통해서 하고자하는건 예상치 못한 입력을 넣어 예상치 못한 동작이 있는지 확인해보기 위함이니까, 우리가 퍼징을 위해 생성하고자하는 input 들(fuzz input space)이 정상적으로 동작할 것으로 예상되는 인풋의 범위(the expected input space of PUT)안에 들든 말든 뭐 딱히 중요하지가 않다. (예상못한 인풋을 넣어서 비정상적인 동작을 유도하면 오히려 땡큐다.)

둘째, 실제로 fuzzing을 할때 많은 반복들을 실행한다. 때문에 많은 문헌들에서 "반복 실행(repeated executions)"이라는 단어를 쓰는 것은 적절하다.

⇒ 퍼징을 하면 계속해서 새로운인풋 생성, 입력등등의 작업들을 계속해서 반복할 수 밖에 없음. 그래서 "repeated executions" 이라는 표현은 퍼징을 나타내기위한 좋은 단어임.

셋째, 샘플링 프로세스(다음 인풋으로 무엇을 넣을지 결정하는 과정)은 반드시 싹 다 무작위는 아니다. 그림5 에서 볼 수 있듯이, Fuzz testing은 fuzzing을 이용한 소프트웨어 테스트의 한 종류일 뿐이다.

⇒ 샘플링 프로세스 즉, 다음 인풋을 결정하는 과정은 무조건 무작위가 아니고 커버리지 가이디드(coverage guided) 등등 좀 더 효율적으로 샘플을 선택하는 기능이 포함될 수도 있다.

⇒ Fuzz testing과 fuzzing은 다른 뜻이다!! fuzzing 안에 fuzz testing이 있다. 상위어 : fuzzing 하위어 : fuzz testing

Fuzzer를 다른 소프트웨어 테스팅 프로그램들과 구분하고 정체성을 갖도록하는 가장 큰 특징은 바로 프로그램 crashes 및 보안 관련 버그를 찾는 목표를 가지고 있는 프로그램이라는 것이다.

Definition 2 (Fuzz Testing).

추가로 fuzz testing에서 많이 사용하는 단어인 fuzzer와 fuzz campaign에 대해서 정의할 예정이다.

Fuzz testing is the use of fuzzing to test if a PUT violates a security policy.

정의 2(fuzz testing) : fuzz testing는 fuzzing을 사용하여 PUT가 보안 정책을 위반하는지 여부를 테스트하는 것이다.

⇒ fuzzing : 대상 프로그램에 랜덤한 인풋값들을 넣는 행위

⇒ fuzz testing : 대상 프로그램에 랜덤한 인풋값들을 넣어, 보안 정책(security policy)을 위반(violate)하는 경우(crash 발생)가 있는지를 검사/테스팅하는 행위

Definition 3 (Fuzzer).

Definition 3 (Fuzzer). A fuzzer is a program that performs fuzz testing on a PUT.

정의 3 (Fuzzer) : fuzzer는 PUT에 fuzz testing을 수행하는 프로그램이다.

Definition 4 (Fuzz Campaign).

Definition 4 (Fuzz Campaign). A fuzz campaign is a specific execution of a fuzzer on a PUT with a specific security policy.

정의 4 (Fuzz Campaign) : fuzz campaign은 퍼저의 실행단위이다.

⇒ 특정한 보안 정책을 가지고 프로그램에 대해 퍼저를 한번 실행시키는 것. 그 실행 자체를 fuzz campaign이라고함

Fuzz Campaign을 통해 PUT를 실행하는 목적은 지정된 보안 정책(specified security policy)을 위반하는 버그를 찾는 것이다. 예를 들어, 초기 퍼저에 의해 채택된 보안 정책(security policy employed by early fuzzers)은 생성된 입력(테스트 케이스)이 PUT에 crashes 발생시켰는지 여부만 테스트했다.

fuzz testing은 실제로 실행에서 관찰할 수 있는 모든 보안 정책, 즉 EM(Execution Monitoring)-enforceable 을 테스트하는 데에도 사용될 수 있다.

실행이 보안 정책을 위반하는지(whether an execution violates the security policy)를 결정하는 메커니즘을 bug oracle이라고 한다.

• EM-enforceable : 실행했을때 나타날 수 있는 결과에 대해 경우의 수(정상실행, crash, 익스가능, 익스불가능)를 관찰하는거

Definition 5 (Bug Oracle).

Definition 5 (Bug Oracle). A bug oracle is a program, perhaps as part of a fuzzer, that determines whether a given execution of the PUT violates a specific security policy.

정의 5(Bug Oracle). 버그 오라클은 특정 PUT 실행이 특정 보안 정책을 위반하는지 여부를 판단하는 프로그램이다.

우리는 퍼저에 의해 구현된 알고리즘을 단순히 "fuzz algorithm"이라고 부른다. 거의 모든 fuzz algorithm은 PUT(으로의 경로) 너머의 일부 파라미터에 의존한다.

⇒ some parameters beyond (the path) to the PUT : PUT을 실행하기위해 필요한 틀 안에서 바꿀 수 있는 (특정 인풋을 프로그램에 전달할 수 있는 조건을 만족한 상태가 전제되어야 하는 - ex. 드라이버 통신규약을 준수한 상태에서 변경가능한 값만 변경하여 퍼징)의 파라미터에 의존한다.

Definition 6 (fuzz configuration).

Each concrete setting of the parameters is a fuzz configuration: Definition 6 (Fuzz Configuration).

파라미터의 각 구체적인 설정은 fuzz configuration이다. 정의 6(fuzz configuration) : fuzz algorithm의 fuzz configuration은 fuzz algorithm을 컨트롤하는 파라미터 값을 포함하여 구성되어있다. fuzz configuration는 광범위하게 정의될 수 있어야한다.

fuzz configuration의 값 유형은 fuzz algorithm의 유형에 따라 달라진다.

예를 들어 랜덤 바이트 스트림을 PUT으로 전송하는 fuzz algorithm에는 단순한 configuration space {(PUT)}이 있다.

한편, 고도의 퍼저에는, a set of configurations를 받아 들여, 시간이 지남에 따라 세팅을 진화시키는 알고리즘이 포함되어 있다. 이 알고리즘에는 configurations의 추가와 삭제가 포함된다.

⇒ add & remove configurations 는 곧 evolve the set 이다.

예를 들어 CERT BFF[49]는 campaign의 진행에 따라 mutation ratio(뮤테이션 비율 : mutation ⇒ 새로운 인풋을 만들어내는 행위. 돌연변이)와 seed를 모두 변화시키기 때문에 그 configuration space는 {(PUT, s1, r1), (PUT, s2, r2), ..}이다.

시드는 PUT에 입력된 (일반적으로 잘 구성된) 것으로, 이를 수정하여 테스트 케이스를 생성하기위해 사용된다.

⇒ 시드를 뮤테이션 해서 테스트 케이스를 마구마구 생성해냄

퍼저는 일반적으로 a collection of seeds를 유지하며, 일부 퍼저는 fuzz campaign이 진행됨에 따라 collection을 발전시킵니다. 이 collection을 seed pool이라고 합니다.

⇒ 퍼징을 할때마다(fuzzer campaign - 한번 퍼징 실행 할때마다) 시드 모음집을 업데이트 해줌. (오 이 seed pool 기반으로 또 퍼징해봐)

마지막으로 퍼저는 각 configuration 내에서 일부 데이터를 저장할 수 있다. 예를 들어, coverage-guided fuzzers는 도달한 커버리지를 각 Configuration에 저장할 수 있다.

2.2 Paper Selection Criteria

본 논문을 위해 2008년 1월부터 2019년 2월까지 4개의 주요 보안 회의와 3개의 주요 소프트웨어 엔지니어링 회의의 마지막 과정에 퍼징에 관한 모든 출판물을 포함한다.

§2.1에서 언급했듯이 fuzz testing은 fuzz testing이 보안과 관련되어 있다(security related)는 점에서 단순한 software testing과 차별화된다.

이론적으로 버그에 초점을 맞춘다고 해서 퍼징이나 소프트웨어 테스팅이나 뭐 크게 다른게 없다. 그러나 실제로 사용되는 기술은 종종 다르다.

When designing a testing tool, access to source code and some knowledge about the PUT are often assumed. Such assumptions often drive the development of testing tools to have different characteristics compared to those of fuzzers, which are more likely to be employed by parties other than the PUT’s developer.

단순히 테스팅 도구를 설계할때에는 주로 PUT 개발자에 의해 설계되기 때문에 소스코드에 대한 접근과 PUT에 대한 일부지식이 가정되는 경우가 많다.(access to source code and some knowledge about the PUT are often assumed) 이러한 가정들은 테스팅도구의 개발과 퍼저의 개발을 구분지어 다른 특성을 갖도록한다. 때문에 퍼저는 자연스럽게 단순 소프트웨어 테스트 도구를 사용하는 개발자 말고 다른 사람들에게(공격자, 방어자, 보안연구가)들에 의해 채택될 가능성이 높다.

⇒ 단순 소프트웨어 테스트 도구는 해당 PUT을 개발하는 사람이 쓸 확률이 높다.

⇒ 퍼저는 꼭 그 개발자가 아니더라도 다른 사람들이 쓸 수도 있다. (취약점 탐지를 위해)

따라서 출판물을 "fuzz testing"와 관련된 것으로 분류하여 이 조사에 포함시켜야 할지 확신할 수 없는 경우, fuzz라는 단어가 나오면 그냥 해당 출판물을 포함한다. (주먹구구식)

2.3 Fuzz Testing Algorithm

우리는 fuzz testing을 위한 일반적인 알고리즘인 Algorithm 1을 제시한다. 이 알고리즘은 모델 퍼저에서 구현되었다고 가정한다.

ALGORITHM 1: Fuzz Testing

Input: C, tlimit
Output: B // a finite set of bugs
B ← ∅
// C는 fuzz 인풋이 아니라 이번 Fuzz testing fuzz Configurations
C ← PREPROCESS(C)
while telapsed < tlimit ∧ CONTINUE(C) do
	conf ← SCHEDULE(C, telapsed, tlimit)
	// configuration 고려해서 인풋 새로 생성
	tcs ← INPUTGEN(conf)

	// Obug is embedded in a fuzzer
	// 한번 실행했을때 발견된 버그 & 그 인풋이 어떤 결과냈는지 그 정보 던져줌
	B', execinfos ← INPUTEVAL(conf, tcs, Obug)

	// 요번 실행 정보들 이용해서 configuration 업데이트
	C ← CONFUPDATE(C, conf, execinfos)

	B ← B ∪ B'
return B

§ 2.4에 정의된 바와 같이 위에 나와있는 알고리즘 1은 블랙, 그레이, 화이트 박스 퍼징을 포함한 기존 퍼징 기법을 다 설명할 수 있을 정도로 일반적이다.

알고리즘 1은, fuzz configurations C 와 타임 아웃 tlimit 의 세트를 입력으로서 받아들여, 검출된 버그의 셋인 B를 출력한다. 이건 두 부분으로 구성되어 있다.

첫 번째 부분은 PREPROCESS() 함수로 fuzz campaign 시작 시 실행된다.

두 번째 부분은 루프 내부의 5가지 기능(SCHEDULE, INPUTGEN, INPUTEVAL, CONFUPDATE, and CONTINUE)으로 구성되어 있다. 이 루프의 각 실행을 fuzz iteration이라고 하며, INPUTEVAL이 테스트 케이스에서 PUT를 실행하는 것을 fuzz run이라고 한다.

⇒ fuzz iteration : fuzz testing algorithm에서 루프의 각 실행

⇒ fuzz run : inputeval 함수가 PUT을 한번 실행하는 것

모든 퍼저가 5가지 기능을 모두 구현하는 것은 아니다. 예를 들어, 퍼지 구성을 업데이트하지 않는 Radamsa 모델링을 위해 CONFUPDATE는 항상 현재 set of configurations를 변경하지 않고 반환한다.

⇒ Radamsa : 뮤테이션 알고리즘, 완전 랜덤

PREPROCESS (C) → C

PREPROCESS (C) → C 는 a set of fuzz configurations를 인풋으로 PREPROCESS () 함수를 실행하고 potentially-modified set of fuzz configurations(수정됐을지도 모르는 fuzz configuration)을 결과로 받아서 C에 넣어준다.

fuzz algorithm에 따라 PREPROCESS() 는 PUT에 instrumentation code를 삽입하거나 시드 파일의 실행 속도를 측정하는 등의 다양한 작업을 수행할 수 있다.

⇒ instrumentation : 코드 커버리지 측정을 위해 필요한 코드. 예를들어 이 코드 실행여부로 프로그램 실행흐름을 추적함.

conf ← SCHEDULE(C, telapsed, tlimit)

conf ← SCHEDULE(C, telapsed, tlimit) 은 현재 퍼지 구성 세트, 현재 시간 및 타임아웃 tlimit을 입력으로 받아들여 현재 fuzz iteration에 사용할 fuzz configuration을 선택한다.

tcs ← INPUTGEN(conf)

tcs ← INPUTGEN(conf) takes a fuzz configuration as input and returns a set of concrete test cases tcs as output.

fuzz configuration을 입력으로 사용하고 a set of concrete test cases를 출력으로 반환한다.

test cases를 생성할 때 INPUTGEN()은 conf에서 특정 파라미터(매개변수)를 사용한다. 일부 퍼저는 test cases를 생성하기 위해 conf에서 시드를 사용하는 반면 어떤 퍼저는 model or grammar을 파라미터로 사용한다. § 5를 참조하면 좋다.

⇒ test case 생성할때 conf 에서 특정 파라미터를 사용하는데, 시드나 model 혹은 문법을 파라미터로 이용해서 생성함.

B', execinfos ← INPUTEVAL(conf, tcs, Obug)

B', execinfos ← INPUTEVAL(conf, tcs, Obug) fuzz configuration conf, a set of test cases tcs 및 bug oracle Obug를 입력으로 받아들인다.

tcs 로 PUT를 실행하여 bug oracle Obug를 사용하여 실행이 보안 정책을 위반하는지 여부(크래시 발생여부)를 확인한다. 다음으로 발견된 B'의 버그 세트와 각 퍼지 실행 execinfo에 대한 정보를 출력한다. 이 정보는 다음번 fuzz configurations 업데이트 및 피드백에 사용할 수 있다.

우리는 Obug가 모델 퍼저에 포함되어있다고 가정한다.

⇒ Obug(bug oracle) : 실행이 보안 정책을 위반하는지 여부를 결정하는 특정 메커니즘. 크래시 여부 판단 알고리즘

C ← CONFUPDATE(C, conf, execinfos)

CONFUPDATE()는 a set of fuzz configurations C, 현재 configuration Conf 및 각 fuzz runs 정보에 대한 execinfo를 입력으로 사용한다.CONFUPDATE() 를 실행하면 fuzz configurations set C 를 갱신할 수 있다.

예를 들어, 많은 그레이 박스퍼저는execinfo를 기반으로 **C의 fuzz configurations를 줄인**다.

⇒ fuzz configuration이 줄어들면 좋은 것. 해당 specific한 PUT에 적합한 구성을 찾아간다는 뜻이니까
CONTINUE(C) 는 일련의 fuzz configurations C 를 입력으로 하여 새로운 fuzz iteration이 발생할지 여부를 나타내는 참 거짓을 출력한다. 이 기능은 검색할 경로가 더 이상 없을 때 종료될 수 있는 화이트 박스 퍼저를 모델링하는 데 유용하다.

2.4 Taxonomy of Fuzzers

이 논문에서, 우리는 퍼저가 각 fuzz run에서 관찰하는 의미론의 세분성(granularity of semantics)을 기반으로 퍼저를 세 개의 그룹으로 분류했다. 이 세 가지 그룹을 블랙, 그레이 및 화이트 박스 퍼저라고 한다.이러한 그룹을 이하에서 정의한다.

이 분류는 두 가지 주요 범주(black & white 테스트)가 있는 기존 소프트웨어 테스트와는 다르다. § 2.4.3에서 설명하듯이 회색 박스 퍼징은 화이트 박스 퍼징의 변형으로 각 퍼징에서 일부 정보만 얻을 수 있다.

2.4.1 Black-box Fuzzer

"black-box"라는 용어는 소프트웨어 테스트 및 퍼징에서 PUT의 내부가 보이지 않는 기술을 나타내기 위해 일반적으로 사용된다. 이러한 기술은 PUT의 입력/출력 동작만 관찰할 수 있다.

소프트웨어 테스트에서 black-box 테스트는 IO 기반 또는 데이터 기반 테스트라고도 한다. 대부분의 전통적인 퍼저가 이 범주에 속한다.

Funfuzz 및 Peach와 같은 현대 퍼저는 PUT를 검사하지 않는(not inspecting the PUT) 특성을 유지하면서 보다 의미 있는 테스트 케이스를 생성하기 위해 입력에 대한 구조 정보(the structural information about inputs)를 고려한다.

적응형 랜덤 테스트(adaptive random testing)에서도 유사한 방법이 사용된다.

⇒ 적응형 랜덤 테스트는 입력 공간(input space)내에서 테스트 케이스를 보다 균등하게 분배하는 것을 목표로 한다.

2.4.2 White-box Fuzzer

black-box 퍼징과는 스펙트럼의 반대편 극단에서 white-box 퍼징은 PUT의 내부와 PUT 실행 시 수집된 정보를 해석함으로써 테스트 케이스를 생성한다. 따라서 white-box 퍼저는 PUT의 상태 공간(state space)을 체계적으로 탐색할 수 있다.

white-box 퍼징이라는 용어는 Godefroid에 의해 2007년에 도입되었으며 기호 실행의 변형인 동적 기호 실행(DSE, dynamic symbolic execution)을 의미한다.

DSE에서는 심볼릭과 구체적인(symbolic and concrete) 실행이 동시에 작동하며, 구체적인 프로그램 상태는 symbolic constraints(예: 시스템 호출 구체화)을 단순화하기 위해 사용된다.

따라서 DSE는 종종 concolic testing (concrete + symbolic)로 언급된다. 또한 white-box 퍼징은 오염분석(taint analysis)을 사용하는 퍼저를 설명하는 데에도 사용되었다. white-box 퍼징의 오버헤드는 일반적으로 블랙 박스 퍼징의 오버헤드보다 훨씬 높다.

이는 부분적으로 DSE 구현에서 dynamic instrumentation과 SMT해결을 사용하는 경우가 많기 때문이다. 사실 DSE 자체는 보안 버그를 찾는 것을 목적으로 하지 않기 때문에 white-box 퍼저라고 하기는 어렵고 엄연히 다른 기술이다.

따라서, 본 논문에서는 DSE에 대한 포괄적인 조사를 제공하지 않으며, 비보안 애플리케이션의 DSE에 대한 자세한 내용은 최근 논문을 참조하길바란다.

⇒ 컴퓨터 과학 및 수학 논리에서 Satisfiability modulo theories(SMT)는 공식이 만족할 수 있는지 여부를 결정하는 문제이다. Boolean satisfiability problem(SAT : Bool 공식(참/거짓)을 충족하는 해석이 있는지 참이될 수 있는 해석이 있는지 여부를 결정하는 문제)를 실수, 정수, 배열, 문자열과 같은 다양한 자료구조를 포함하는 보다 복잡한 공식으로 일반화한다. SMT 솔버는 이러한 SMT 문제를 해결하는 것을 목표로하는 도구이다.

2.4.3 Grey-box Fuzzer

어떤 퍼저들은 grey-box 퍼저라고 불리는 중간 접근 방식을 취한다. 일반적으로 grey-box 퍼저는 PUT 및/또는 그 실행에 관한 내부 정보를 얻을 수 있다. white-box 퍼저와 달리 grey-box 퍼저는 PUT의 완전한 의미론(semantics ⇒ 알고있는게 white-box)에 대해 추론하지 않고 PUT에 대해 경량 정적 분석(lightweight static analysis)을 수행하거나 코드 커버리지와 같은 실행에 대한 동적 정보를 수집한다.

grey-box 퍼저는 속도를 높이고 더 많은 입력을 테스트하기 위해 대략적이고 불완전한(approximated, imperfect) 정보(⇒ semantics와 반대되는 말)에 의존한다. 일반적으로 보안 전문가들 사이에 공감대가 형성되지만 black-box, grey-box, white-box 퍼징의 구별이 항상 명확하지는 않다.

black-box 퍼저는 퍼저실행(fuzz runs)에 대한 정보를 수집할 수 있고 white-box는 근사치(approximations)를 사용한다.

grey-box 퍼저의 초기 예는 EFS이며, 각 퍼저 실행(fuzz run)에서 수집된 코드 커버리지(coverage)를 사용하여 진화 알고리즘(EA)으로 테스트 케이스를 생성한다.

Randoop 또한 유사한 접근방식을 사용했지만 보안 취약점을 대상으로 하지는 않는다. AFL 및 VUzzer 와 같은 최신 퍼저가 이 범주의 예이다.

2.5 Fuzzer Genealogy and Overview

그림 1은 퍼저의 분류를 시간순으로 제시한다. 메이저 컨퍼런스에 출연하거나 100개 이상의 GitHub 스타를 획득한 인기 퍼저를 수작업으로 선택해, 그 관계를 그래프로 나타냈다.

-퍼저는 파일, 네트워크, UI, 웹, 커널 I/O, 스레드(concurrency fuzzer의 경우) 등 PUT가 사용하는 입력 유형에 따라 세분화된다. 표 1(p. 6)은 그림 1의 가장 주목할 만한 퍼저에 사용된 기법의 상세 요약이 적혀있다.

아래 각 열에서 설명하는 속성을 설명한다. 첫 번째 열은 퍼저가 black(), white(#), grey-box(H#) 중 어느 쪽인지 나타낸다. 퍼저에 다른 종류의 피드백 수집을 사용하는 두 개의 단계가 있을 때 두 개의 원이 나타난다.

예를 들어 SymFuzz는 black-box 캠페인(+#)의 성능을 최적화하기 위해 white-box 분석을 전처리 단계로 실행하고 Driller와 같은 하이브리드 fuzzer(H#+#)는 white-box 퍼징과 grey-box 퍼징을 번갈아 수행한다.

두 번째 열은 퍼저의 소스 코드를 공개적으로 사용할 수 있는지 여부를 나타낸다.

세 번째 열은 퍼저가 작동하기 위해 PUT의 소스 코드가 필요한지 여부를 나타낸다.

네 번째 열은 퍼저가 메모리 내 퍼징(in-memory fuzzing)을 지원하는지 여부를 나타낸다(제3.1.2항 참조).

다섯 번째 열은 퍼저가 모델을 추론(infer models)할 수 있는지 여부에 관한 것이다(제5.1.2조 참조).

여섯 번째 열은 퍼저가 PR E P R O C E S에서 정적 또는 동적 분석을 수행하는지 여부를 나타낸다.

일곱 번째 열은 퍼저가 여러 시드 처리를 지원하는지 여부 및 스케줄링을 수행하는지 여부를 나타낸다. mutation 컬럼은 퍼저가 입력 변환을 실행하여 테스트 케이스를 생성하는지 여부를 지정한다.

실행 피드백에 따라 입력 변환을 유도하는 퍼저를 나타내기 위해 H#을 사용한다. 모델 기반 열은 퍼저가 모델을 기반으로 테스트 케이스를 생성하는지 여부에 대한 것이다.

제약 조건(constraint) 기반 열은 퍼저가 테스트 케이스를 생성하기 위해 기호 분석을 수행함을 보여준다. 오염 분석(taint analysis) 열은 퍼저가 오염 분석을 활용하여 테스트 사례 생성 프로세스를 안내한다는 것을 의미한다.

INPUTEVAL 섹션의 2열은, 퍼저가 stack hashing 또는 코드 커버리지 중 무엇을 사용해 crash triage를 실행할지를 나타내고 있다.

⇒ triage : 우선순위 결정. crash triage 에는 충돌을 추가로 조사할 가치가 있는지(보안 연구가의 경우 일반적으로 crash가 취약점으로 인한 것인지 여부를 결정하는 것을 의미함)을 결정하기 위해 fuzzer에서 발견한 각 crash를 검사하는 것이 포함된다.

CO N FUP D A TE 섹션의 첫 번째 열은 풀장에 새로운 시드를 추가하는 등 CO N FUP D A TE 동안 퍼저가 시드 풀을 진화시키는지 여부를 나타낸다(제7.1절 참조).

CO N FUP D A TE 섹션의 두 번째 열은 퍼저가 온라인 방식으로 입력 모델을 학습하는지 여부에 대한 것이다.

마지막으로, CO N FUP D A TE 섹션의 세 번째 열은 퍼저가 시드 풀에서 seed을 제거하는지 여부를 보여준다(제7.2절 참조).

자세한 내용은 논문을 참고해보자.