[논문 리뷰] The Art, Science, and Engineering of Fuzzing: A Survey
원문 : https://arxiv.org/abs/1812.00140
논문 리뷰를 하려 한다. 분명히 이 논문을 이미 두 번 읽었고 이번이 세 번째이다. 하지만 21페이지라는 분량과 240개의 레퍼런스 그리고 무엇보다 온통 영어로 작성된 논문이기 때문에 매번 새롭다.
본인은 퍼징에 대한 진입장벽이 꽤 높다고 생각한다. 처음 퍼저를 처음 접한 곳은 출처가 불분명한 여러 블로그들의 글이었고, 이후 generic한 어느 퍼저의 기술 문서를 읽으면서 공부했다. 그리고 나서 이 논문이 나왔다. 그전까지는 수많은 퍼저들을 망라하는 survey 논문이 없었다고 한다. 아마 있었어도 영어라서 안 읽었을 것 같다.
본 논문의 contribution을 감히 적어보자면 크게 두 가지가 있는 것 같다.
- 모든 퍼저들을 설명할 수 있는 통일된 퍼징의 개념(모델) 제시.
- 현존하는 수많은 퍼저들을 분석하고 분류.
전자는 퍼징을 처음 접하는 사람들의 진입 장벽을 낮추는 데 도움이 될 것이다. 그리고 후자는 어떤 퍼저가 있고 무엇을 선택해야 할지 고민하는 사람들에게 도움이 될 것이다.
이 논문의 필요한 부분만 골라서 읽은 적이 많았는데, 이번에는 그냥 통번역을 하려한다. 그래서 이 논문 리뷰의 컨셉은 모든 문장을 리뷰하기다.
[*]
퍼징 입문자, 퍼징을 공부하려는 사람, 어떤 종류의 퍼저가 있는지 궁금한 사람, 새로운 퍼저를 만들기 위한 아이디어가 필요한 사람 그리고 나중에 다 까먹고 다시 이 글을 읽을 본인(금붕어의 brain)에게 이 글을 바칩니다.
[**]
해석이 애매하거나 의역한 경우 콜론 뒤에 원어를 적었습니다. → "애플(:apple)은 ..."
물음표는 오역일 수 있습니다. → "감자(?apple)는 ..."
대괄호는 본 논문 저자의 의견이 아닌 논문을 리뷰한 필자의 개인적인 의견입니다. → "사과[맛있음]는 ..."
[***]
정확한 정보 전달을 원하신다면 원문을 반드시 봐주세요.
발 번역, 틀린 내용, 애매한 내용 등 알려주시면 감사하겠습니다.
[목차]
Abstract
현존하는 많은 소프트웨어 취약점 탐지 기술 중 하나인 퍼징(fuzzing)은 단순한 개념, 낮은 배포(?deployment) 장벽, real-world 취약점 분석의 많은 경험적 증거로 인해 인기가 많다. 퍼징은 문법적으로(:syntactically) 혹은 의미론적으로(:semantically) 비정상적인 입력을 생성해 프로그램을 반복적으로 실행하는 과정을 의미한다.
연구자와 실무자 모두 최근 몇 년 동안 퍼징을 개선하기 위해 많은 노력을 해왔는데, 퍼징 연구의 폭발적인 증가로 퍼징에 대한 포괄적이고 일관된 관점(:view)을 얻는 것이 어려워졌다.
방대한 퍼징 문헌(:literature)을 보존하고 일관성을 유지하기 위해, 본 논문에서 퍼징의 general-purpose model과 현재 퍼징 문헌의 분류(:taxonomy)를 제시한다. 본 논문에서는 현대의 퍼저를 효과적으로 만드는 예술, 과학, 공학 분야의 문헌과 혁신(:innovation)을 조사하여 모델 퍼저의 모든 단계에서 설계 결정(:design decision)을 체계적으로 분석 한다.
1. Introduction
퍼징은 1990년대 초, Miller 교수의 논문 <An empirical study of the reliability of UNIX utilities> 이래 가장 널리 배포된 소프트웨어 보안 취약점 탐지 기술 중 하나이다. 퍼징은 문법적으로(:syntactically) 혹은 의미론적으로(:semantically) 비정상적인 입력을 생성해 프로그램을 반복적으로 실행하는 과정을 의미한다.
실제로 공격자는 exploit 개발이나 침투 테스트(:penetration testing)에서 퍼징을 빈번히 사용한다. 2016 DARPA CGC(Cyber Grand Challenge)의 여러 팀도 cyber reasoning systems에 퍼징을 적용했다.
이로 인해 방어자는 공격자보다 먼저 취약점을 찾기 위해 퍼징을 사용하기 시작했다. 예를 들어 Adobe, Cisco, Google, Microsoft와 같은 유명 업체는 모두 보안 개발의 일부로 퍼징을 사용한다. 최근에는 상용 소프트웨어 패키지의 보안을 측정하고 end-user에게 안전성을 보증하기 위해 security auditor와 오픈 소스 개발자도 퍼징을 사용한다.
퍼징 커뮤니티는 매우 활발하다. 본 논문을 쓰는 시점에서 GitHub만이 퍼징과 관련된 수천 개 이상의 repository를 호스팅한다. 그리고 (나중에 다루겠지만) 문헌에는 많은 퍼저가 포함되어 있으며, 메이저 보안 컨퍼런스에서 점점 더 많은 퍼징 연구가 발표되고 있다. 블로그에서도 퍼징의 성공 사례를 많이 찾아볼 수 있다.
하지만 퍼징 연구의 급증으로 부작용이 나타나고 있다. 예를 들어, 퍼저의 소스 코드와 매뉴얼에 대한 설명보다 퍼저 자체에 대한 설명을 많이 해야 하는 실정이다. 이로인해 퍼저의 design decision과 중요할 수도 있는 tweak들을 놓치지 쉽다.
[실제로 본인도 연구에서 적용한 차분 퍼징 알고리즘을 설명하기 전에 논문 두 페이지를 퍼징 개념에 대한 소개를 채워야 했다.. 당시 이 논문을 참조하여 용어와 동작 과정을 정리했었다.]
또한 퍼징관련 용어에서 단편화가 보이고 있다. 예를 들어, AFL은 crashing input의 크기를 줄이는 기술을 test case minimization라고 부르는데, funfuzz는 똑같은 기술을 test case reduction이라고 부른다. 반면 BFF는 crash minimization라는 이름이 비슷해 보이는 용어를 사용한다. 하지만 이 기술은 실제로 crashing input(크래시를 유발하는 입력)과 원본 시드 파일 사이에 다른 비트 수를 최소화하는 기술이지, 입력 크기를 줄이는 것과는 관련이 없다.
이런 문제들 때문에 평가(:evaluation) 결과를 통해 퍼저를 비교하는 것은 매우 어렵다. 이러한 단편화로 인해 퍼징 지식을 발견하거나 전파하는 것이 어렵고, 이는 장기적으로 퍼징 연구의 진행에 심각한 악영향을 미칠 것이다.
따라서 퍼징의 많은 progress들을 통합하고 분류할 때가 되었다고 생각했다. 대부분의 퍼저들은 2007-2008년에 이런 주제를 다룬 서적 <Open Source Fuzzing Tools>, <uzzing: Brute Force Vulnerability Discovery>, <Fuzzing: Brute Force Vulnerability Discovery>, <Fuzzing for Software Security Testing and Quality Assurance> 3권이 출판 된 후에 등장한 퍼저들이다.
field를 통합하는 과정은 2절에서 퍼징 용어와 통합 된 fuzzing model을 제시하는 것부터 시작할 것이다. 제시하는 용어들은 본 논문의 목적을 충실하게 유지하면서 현재의 주요 usage를 잘 반영하도록 선택하였다. 제시하는 model fuzzer(Algorithm 1)는 현대 퍼징 문헌의 분류 체계(Figure 1)에 분류 된 많은 퍼징 task에 적합하도록 설계했다. 이 설정을 기반으로 3절~7절에서 model fuzzer의 모든 단계를 분석하고 Table 1에서 주요 퍼저에 대한 자세한 개요를 다룬다. 각 단계에서 관련 문헌을 조사하여 design choice와 중요한 trade-off, 현대 퍼저의 효율 성에 크게 기여한 engineering effort를 다룰 예정이다.
Uploaded by Notion2Tistory v1.1.0