[PL] Fuzzing, 퍼징이란?

피드백과 정정 댓글은 환영입니다 :)

해당 게시글의 참고 문헌은 게시글 가장 아래에 작성해두었습니다.

 

1) 퍼징(Fuzzing)이란? 

소프트웨어는 사람에 의해 개발된 것이기 때문에 필연적으로 오류 및 취약점이 존재한다. 퍼징은 이러한 취약점들을 발견해내기 위한 소프트웨어 테스트 기법 중 하나이다. 퍼징은 프로그램에 무작위로 생성된 여러 데이터를 입력하여 취약점을 찾아내는데, 취약점을 발견하는 과정이 매우 우연적이기 때문에 바보 과학이라고 불리기도 한다. 예로, C에서 변수에 1부터 아주 큰 숫자들을 무작위로 집어넣었을 때 특정 숫자에서 Integer Overflow 오류가 발생하는 것을 알게 된다면 무작위로 생성된 여러 정수 데이터를 통해 취약점을 발견해냈다고 이야기할 수 있다. (물론 Integer Overflow 버그가 아직 발견되지 않았다는 가정 하에)

 

2) 프로그램의 정보 활용 정도에 따른 퍼징(Fuzzing) 기법의 분류

퍼징 기법은 프로그램의 정보를 활용하는 정도에 따라 크게 세가지로 분류될 수 있다.

(1) 블랙박스 퍼징/Black-Box Fuzzing

블랙박스 퍼징은 분석 대상이 되는 프로그램의 내부 정보를 배제한 상태에서 테스팅이 이루어진다. 오직 대상 프로그램의 입력과 출력 데이터만 사용하게 된다. 소프트웨어의 내부 구조를 들여다보지 않는 만큼 소프트웨어의 소스코드에 대한 배경 지식은 필요하지 않다는 것이 장점이지만 전체 소스코드의 범위는 검사하지 못한다는 것이 단점이다. 

 

(2) 화이트박스 퍼징/White-Box Fuzzing

화이트박스 퍼징은 프로그램의 내부 구조에 대한 정보와 실행 과정에서 알 수 있는 커버리지 정보 등을 활용하여 사용되는 기법이다. 주로 정적분석이라고도 불리우며, 블랙박스 퍼징과는 달리 소프트웨어의 소스코드에 대한 지식이 필요하다. 하지만 그만큼 소스코드를 직접 살펴보기 때문에 동작 방식을 정확히 이해할 수 있으며, 완전하고 효과적인 테스팅 방법이라고 할 수 있다. 단점으로는 실제 프로그램이 작동할 때 발생되는 런타임 에러를 잡아내기는 어렵다는 점이 있다. 

 

(3) 그레이박스 퍼징/Gray-Box Fuzzing

그레이박스 퍼징은 앞선 블랙박스와 화이트박스 퍼징의 특성을 모두 부분적으로 가지는 퍼징 기법이다. 화이트박스 퍼징에 비해 소프트웨어에서 알아내고자 하는 정보가 더 추상화되어 있다. 

 

예로, C 컴파일러의 버그를 찾아내기 위해 fuzzing을 사용한다고 해보자. 각 fuzzing의 종류에 따라 접근 방법은 아래와 같을 것이다. (아닐 수도 있습니다...)

블랙박스 퍼징: 수많은 샘플 프로그램들을 입력으로 넣어 사용자가 기대하는 값과 다른 출력값이 나온 것들을 버그로 판별

화이트박스 퍼징: C 컴파일러의 소스코드를 분석하여 프로그램의 모든 케이스에 대해 데이터 작성 후 테스팅

그레이박스 퍼징: 샘플 프로그램들을 생성할 때 소스코드의 정보를 활용하여 버그를 찾아낼 수 있을만한 프로그램들을 생성/변이 후 이를 실행시켜 출력값들을 비교

 

3) 데이터 생성 기법에 따른 퍼징(Fuzzing) 기법의 분류

(1) 생성 기반 퍼징/Generation-based fuzzing

생성 기반 퍼징은 분석 대상이 되는 프로그램의 입력 데이터를 직접 생성하여 퍼징에 활용하는 방법이다. 

 

(2) 변이 기반 퍼징/Mutation-based fuzzing

변이 기반 퍼징은 분석 대상이 되는 프로그램의 입력 데이터를 특정 된 입력 데이터(Seed Program)를 조금씩 변이하여 만들어내는 방법이다.

 

4) 기본적인 Fuzzing pseudocode/Fuzzing Loop

https://ricercasecurity.blogspot.com/2021/12/fuzzuf-fuzzing-unification-framework-en.html

해당 수도코드는 fuzzing loop이라고 불리는 fuzzing 모델이다. 수도코드를 각 라인별로 살펴보게 되면... 

 

Input: C(seed program pool), t_limit(시간 제한)

Output: 버그 집합

1. initializing the set B as an empty set

2. preprocessing the original seed pool C and update it

3. while real taken time(t_elapsed) is less than t_limit and C has elements do -> 

4. select the seed program among seed pool C and put it in to variable, conf(=seed program)

5. mutate the conf(=seed program) and put it in variable, tcs(mutated program)

6. execute the mutated program, tcs and get feedbacks from it. B' represents the new bug set found in tcs and execinfos mean the coverage or extra information about execution.

7. The seed Pool C is updated(deleted or added) based on the execinfos

8. B is newly updated

9. After the loop ends, return the B

 

즉, 일정 시간을 두고 시드 풀에 있는 프로그램들을 바탕으로 분석을 지속적으로 수행하되, 그 과정에서 나오는 피드백을 바탕으로 시드 풀을 업데이트하여 프로그램이 최대한 많고 다양한 테스트 케이스들을 접할 수 있게끔 하는 것이 핵심이다. 

#include <stdio.h>

int main()
{
    int a;
    a = 5;
    
    if (a==1)
        b++;
    else 
        a++;
    
    return 0;
}

시드 풀을 업데이트 한다는 것이 무엇을 의미하는지 위의 예시 코드를 통해 알아보자! (하지만 확실하지 않습니다...) 위의 코드는 C로 작성된 코드로 컴파일시 else 문의 statement로 인해 오류를 일으킨다. 하지만 우선 이해를 위해 아직 C에서 조건문에서 실행이 되지 않는 statement 오류를 아직 검출해내지 못했다고 **가정**해보자! 그런 상황을 가정하였을 때 위의 코드는 정상적으로 작동할 것이고, 해당 버그를 찾아내려면 a의 값이 1로 수정되어야 한다. a의 값이 1로 업데이트 되어야만 else 문이 실행되어 오류를 일으킬 것이기 때문이다! 이를 위해서는 코드의 몇번 라인이 실제로 실행되었는지에 관한 정보가 필요한데, 이를 Code Coverage information이라고 한다. 결국, 이와 같은 종류의 피드백을 수용하여 시드 풀을 업데이트해야만 효율적으로 버그를 발견할 수 있다는 점에서 fuzzing에 있어 피드백은 필수적이라 할 수 있다. 

 

참고문헌

- 전소희 ( So-hee Jun ) , 이영한 ( Young-han Lee ) , 김현준 ( Hyun-jun Kim ) , 백윤흥 ( Yun-heung Paek ). 2020. 최근 퍼징 기법들과 발전에 관한 연구. 한국정보처리학회 학술대회논문집, 27(1): 272-274

버그헌팅: 화이트박스 테스팅과 블랙박스 테스팅

 

추가자료

만약 여러 C fuzzing 기법들이 궁금하시다면 아래의 게시물들을 확인해주세요 :)

[PL] Skeletal Program Enumeration for Rigorous Compiler Testing Qirun Zhang Chengnian Sun Zhendong Su (2016)

 

[PL] Finding Compiler Bugs via Live Code Mutation Sun, Chengnian & Le, Vu & Su, Zhendong. (2016)