google/aflamerican fuzzy lop - 보안 지향 퍼저
원래 Michal Zalewski([email protected])가 개발했습니다.
이 파일을 읽을 시간이 없다면 QuickStartGuide.txt를 참조하세요.
퍼징(Fuzzing)은 실제 소프트웨어에서 보안 문제를 식별하는 가장 강력하고 검증된 전략 중 하나입니다. 현재까지 보안에 중요한 소프트웨어에서 발견된 원격 코드 실행 및 권한 상승 버그의 대부분은 퍼징 덕분입니다.
불행히도 퍼징은 비교적 얕습니다. 맹목적인 무작위 변이는 테스트 대상 코드의 특정 코드 경로에 도달할 가능성을 매우 낮게 만들어, 일부 취약점은 이 기법의 범위 밖에 남게 됩니다.
이 문제를 해결하려는 수많은 시도가 있었습니다. 초기 접근법 중 하나는 Tavis Ormandy가 개척한 코퍼스 정제(corpus distillation)입니다. 이 방법은 커버리지 신호를 사용하여 방대하고 품질 좋은 후보 파일 코퍼스에서 흥미로운 시드(seed)의 하위 집합을 선택한 다음, 전통적인 수단으로 퍼징합니다. 이 접근법은 매우 잘 작동하지만 그러한 코퍼스가 쉽게 준비되어 있어야 합니다. 게다가 블록 커버리지 측정은 프로그램 상태에 대한 매우 단순한 이해만을 제공하므로, 장기적으로 퍼징 노력을 안내하는 데는 덜 유용합니다.
다른 더 정교한 연구는 프로그램 흐름 분석("concolic execution"), 기호 실행, 또는 정적 분석과 같은 기법에 집중해 왔습니다. 이러한 모든 방법은 실험 환경에서는 매우 유망하지만, 실제 사용에서는 신뢰성과 성능 문제를 겪는 경향이 있으며, 현재로서는 "단순한" 퍼징 기법에 대한 실행 가능한 대안을 제공하지 못합니다.
American Fuzzy Lop은 매우 단순하지만 견고한 계측 기반 유전 알고리즘과 결합된 무차별 대입 퍼저입니다. 프로그램 제어 흐름의 미묘하고 국소적인 변화를 쉽게 포착하기 위해 변형된 형태의 엣지 커버리지를 사용합니다.
약간 단순화하면, 전체 알고리즘은 다음과 같이 요약할 수 있습니다.
사용자가 제공한 초기 테스트 케이스를 큐에 로드합니다.
큐에서 다음 입력 파일을 가져옵니다.
프로그램의 측정된 동작을 변경하지 않는 가장 작은 크기로 테스트 케이스를 줄이려고 시도합니다.
균형 잡히고 잘 연구된 다양한 전통적인 퍼징 전략을 사용하여 파일을 반복적으로 변형합니다.
생성된 변형 중 하나라도 계측에 기록된 새로운 상태 전이를 초래한 경우, 변형된 출력을 큐에 새 항목으로 추가합니다.
2단계로 이동합니다.
발견된 테스트 케이스는 또한 새롭고 더 높은 커버리지를 가진 발견으로 대체된 것을 제거하기 위해 주기적으로 선별되며, 계측 기반의 여러 작업량 최소화 단계를 거칩니다.
퍼징 과정의 부산물로, 이 도구는 흥미로운 테스트 케이스로 구성된 작고 자족적인 코퍼스를 생성합니다. 이는 다른 노동 집약적이거나 리소스 집약적인 테스트 방식을 시딩(seeding)하는 데 매우 유용합니다. 예를 들어 브라우저, 오피스 애플리케이션, 그래픽 제품군 또는 클로즈드 소스 도구를 스트레스 테스트하는 경우가 있습니다.
이 퍼저는 맹목적인 퍼징이나 커버리지 전용 도구보다 훨씬 뛰어난 즉시 사용 가능한 성능을 제공하도록 철저히 테스트되었습니다.
소스 코드를 사용할 수 있는 경우, 타사 코드의 표준 빌드 프로세스에서 gcc 또는 clang을 대체하는 드롭인(drop-in) 도구로 작동하는 동반 도구를 통해 계측을 주입할 수 있습니다.
계측은 성능에 상당히 적당한 영향을 미칩니다. afl-fuzz가 구현한 다른 최적화와 함께, 대부분의 프로그램은 전통적인 도구보다 빠르거나 심지어 더 빠르게 퍼징할 수 있습니다.
대상 프로그램을 올바르게 다시 컴파일하는 방법은 빌드 프로세스의 세부 사항에 따라 다를 수 있지만, 거의 보편적으로 적용되는 방법은 다음과 같습니다.```shell $ CC=/path/to/afl/afl-gcc ./configure $ make clean all
C++ 프로그램의 경우에는 `CXX=/path/to/afl/afl-g++`도 설정하는 것이 좋습니다.
clang 래퍼(afl-clang 및 afl-clang++)도 같은 방식으로 사용할 수 있습니다;
clang 사용자는 llvm_mode/README.llvm에 설명된 대로 더 높은 성능의
계측(instrumentation) 모드를 활용할 수도 있습니다.
라이브러리를 테스트할 때는 stdin 또는 파일에서 데이터를 읽어
테스트 대상 라이브러리에 전달하는 간단한 프로그램을 찾거나 작성해야 합니다.
이러한 경우, 이 실행 파일을 계측된 라이브러리의 정적 버전에 링크하거나
런타임에 올바른 .so 파일이 로드되도록 (보통 `LD_LIBRARY_PATH`를 설정하여)
해야 합니다. 가장 간단한 방법은 정적 빌드이며,
일반적으로 다음과 같이 가능합니다:```shell
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
'make'를 호출할 때 AFL_HARDEN=1을 설정하면 CC 래퍼가
간단한 메모리 버그를 더 쉽게 탐지할 수 있도록 코드 하드닝
옵션을 자동으로 활성화합니다. AFL에 포함된 헬퍼 라이브러리인
Libdislocator(libdislocator/README.dislocator 참조)도 힙 손상 문제를 발견하는 데 도움이 될 수 있습니다.
참고: ASAN 사용자는 중요한 주의사항이 있으므로 notes_for_asan.txt 파일을 검토할 것을 권장합니다.
소스 코드를 사용할 수 없는 경우, 퍼저는 블랙박스 바이너리의 빠른 온더플라이 계측을 위한 실험적 지원을 제공합니다. 이는 잘 알려지지 않은 "사용자 공간 에뮬레이션" 모드로 실행되는 QEMU 버전을 통해 구현됩니다.
QEMU는 AFL과 별개의 프로젝트이지만, 다음을 실행하여 해당 기능을 편리하게 빌드할 수 있습니다:```shell $ cd qemu_mode $ ./build_qemu_support.sh
For additional instructions and caveats, see qemu_mode/README.qemu.
The mode is approximately 2-5x slower than compile-time instrumentation, is
less conducive to parallelization, and may have some other quirks.
## 5) Choosing initial test cases
To operate correctly, the fuzzer requires one or more starting file that
contains a good example of the input data normally expected by the targeted
application. There are two basic rules:
- Keep the files small. Under 1 kB is ideal, although not strictly necessary.
For a discussion of why size matters, see [perf_tips.txt](https://github.com/google/afl/blob/master/docs/perf_tips.txt).
- Use multiple test cases only if they are functionally different from
each other. There is no point in using fifty different vacation photos
to fuzz an image library.
You can find many good examples of starting files in the testcases/ subdirectory
that comes with this tool.
PS. If a large corpus of data is available for screening, you may want to use
the afl-cmin utility to identify a subset of functionally distinct files that
exercise different code paths in the target binary.
## 6) Fuzzing binaries
The fuzzing process itself is carried out by the afl-fuzz utility. This program
requires a read-only directory with initial test cases, a separate place to
store its findings, plus a path to the binary to test.
For target binaries that accept input directly from stdin, the usual syntax is:```shell
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
For programs that take input from a file, use '@@' to mark the location in the target's command line where the input file name should be placed. The fuzzer will substitute this for you:
파일에서 입력을 받는 프로그램의 경우, '@@'를 사용하여 대상의 명령줄에서 입력 파일 이름이 배치되어야 할 위치를 표시하십시오. 퍼저가 이를 대신 대체해 줄 것입니다:```shell $ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
또한 -f 옵션을 사용하여 변형된 데이터를 특정
파일에 쓸 수 있습니다. 이는 프로그램이 특정 파일 확장자 등을 기대하는 경우에 유용합니다.
계측되지 않은 바이너리는 QEMU 모드(명령줄에 -Q 추가)에서 퍼징하거나
전통적인 블라인드 퍼저 모드(-n 지정)로 퍼징할 수 있습니다.
-t 및 -m을 사용하여 실행 프로세스의 기본 시간 제한과 메모리 한도를
재정의할 수 있습니다. 이러한 설정을 조정해야 하는 드문 대상의 예로는
컴파일러와 비디오 디코더가 있습니다.
퍼징 성능 최적화를 위한 팁은 [perf_tips.txt](https://github.com/google/afl/blob/master/docs/perf_tips.txt)에서 논의됩니다.
afl-fuzz는 일련의 결정적(deterministic) 퍼징 단계를 수행하는 것으로 시작한다는 점을 유의하십시오.
이 단계는 며칠이 걸릴 수 있지만 깔끔한 테스트 케이스를 생성하는 경향이 있습니다.
zzuf 및 기타 전통적인 퍼저와 마찬가지로 즉시 빠르고 조잡한 결과를 원한다면
명령줄에 -d 옵션을 추가하십시오.
## 7) 출력 해석
표시된 통계를 해석하고 프로세스 상태를 모니터링하는 방법에 대한 정보는
[status_screen.txt](https://github.com/google/afl/blob/master/docs/status_screen.txt) 파일을 참조하십시오.
특히 UI 요소가 빨간색으로 강조 표시된 경우 이 파일을
반드시 확인하십시오.
퍼징 프로세스는 Ctrl-C를 누를 때까지 계속됩니다. 최소한 퍼저가
하나의 큐 사이클을 완료하도록 허용해야 하며, 이는
몇 시간에서 일주일 정도 걸릴 수 있습니다.
출력 디렉터리 내에 세 개의 하위 디렉터리가 생성되며 실시간으로
업데이트됩니다:
- queue/ - 모든 고유 실행 경로에 대한 테스트 케이스와 사용자가 제공한
모든 시작 파일. 이것은 섹션 2에서 언급된 합성 코퍼스입니다.
이 코퍼스를 다른 목적으로 사용하기 전에 afl-cmin 도구를 사용하여
더 작은 크기로 줄일 수 있습니다. 이 도구는
동일한 엣지 커버리지를 제공하는 더 작은 파일 하위 집합을 찾습니다.
- crashes/ - 테스트 중인 프로그램이 치명적인 신호(예: SIGSEGV, SIGILL, SIGABRT)를
수신하도록 하는 고유 테스트 케이스. 항목은
수신된 신호별로 그룹화됩니다.
- hangs/ - 테스트 중인 프로그램이 시간 초과되도록 하는 고유 테스트 케이스입니다.
어떤 것이 hang으로 분류되기 전의 기본 시간 제한은
1초와 -t 매개변수 값 중 더 큰 값입니다.
이 값은 AFL_HANG_TMOUT을 설정하여 미세 조정할 수 있지만, 이는
거의 필요하지 않습니다.
크래시와 hang은 관련 실행 경로에 이전에 기록된 결함에서 볼 수 없었던
상태 전환이 포함된 경우 "고유"한 것으로 간주됩니다. 단일 버그에
여러 방식으로 도달할 수 있다면 프로세스 초기에 카운트가 다소 부풀려질 수 있지만,
곧 빠르게 줄어들어야 합니다.
크래시 및 hang의 파일 이름은 상위(결함이 없는) 큐 항목과 연관됩니다.
이는 디버깅에 도움이 됩니다.
afl-fuzz가 발견한 크래시를 재현할 수 없는 경우, 가장 가능성 높은 원인은
도구에서 사용한 것과 동일한 메모리 한도를 설정하지 않았기 때문입니다. 다음을 시도해 보십시오:```shell
$ LIMIT_MB=50
$ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
Change LIMIT_MB를 afl-fuzz에 전달된 -m 매개변수와 일치하도록 변경하세요. OpenBSD에서는 -Sv도 -Sd로 변경하세요.
기존 출력 디렉터리를 사용하여 중단된 작업을 재개할 수도 있습니다. 다음과 같이 시도하세요:```shell $ ./afl-fuzz -i- -o existing_output_dir [...etc...]
gnuplot이 설치되어 있다면, afl-plot을 이용해 실행 중인 퍼징 작업에 대한 보기 좋은 그래프를 생성할 수도 있습니다. 이것이 어떤 모습인지에 대한 예시는 [http://lcamtuf.coredump.cx/afl/plot/](http://lcamtuf.coredump.cx/afl/plot/)에서 확인할 수 있습니다.
## 8) 병렬 퍼징
각각의 afl-fuzz 인스턴스는 대략 코어 하나를 차지합니다. 즉, 멀티코어 시스템에서는 하드웨어를 완전히 활용하려면 병렬화가 필요합니다. 여러 코어 또는 여러 네트워크 연결 머신에서 공통 타깃을 퍼징하는 방법에 대한 팁은 [parallel_fuzzing.txt](https://github.com/google/afl/blob/master/docs/parallel_fuzzing.txt)를 참조하세요.
병렬 퍼징 모드는 또한 AFL을 다른 퍼저, 심볼릭 또는 콘콜릭 실행 엔진 등과 연동하는 간단한 방법을 제공합니다. 역시 팁은 [parallel_fuzzing.txt](https://github.com/google/afl/blob/master/docs/parallel_fuzzing.txt)의 마지막 섹션을 참조하세요.
## 9) 퍼저 사전