[!WARNING] 강연을 듣고 쓴 메모를 바탕으로 후에 재구성한 내용이라, 어느 정도의 오류가 있을 수 있습니다.
퍼징 환경의 고려사항
퍼징 (Fuzzing) 환경을 구축할 때, 바이너리 실행 속도 자체를 최우선으로 고려하지는 않습니다.
예를 들어 ASan (AddressSanitizer) 같은 도구를 사용하면 속도가 2~3배 정도 느려지지만, 버그 탐지 능력이 향상되므로 감수할 만합니다.
퍼징은 블록 커버리지 (Block Coverage), 엣지 커버리지 (Edge Coverage) 등을 측정하며, 유전 알고리즘 (Genetic Algorithm)과 같은 기법을 사용해 효율적인 테스트 케이스를 생성합니다. (이때 LibFuzzer 같은 도구가 활용됩니다.)
(이러한 접근법을 통해 CVE-2020-29664와 같은 실제 취약점을 발견한 사례가 있습니다.)
A command injection issue in dji_sys in DJI Mavic 2 Remote Controller before firmware version 01.00.0510 allows for code execution via a malicious firmware upgrade packet.
해당 오류는 메모리만 보고서는 알 수 없으므로, LibFuzzer만으로는 어려웠을 것입니다.
사례 연구: PX4 드론 시스템 분석
오픈소스 드론 시스템인 PX4의 소스 코드 (C/C++)를 분석 대상으로 삼았습니다.
- 과제 1 (파싱)
- 과제 2 (포팅): 데몬 (daemon) 실행 기능부터 요구되었습니다. LibFuzzer stub (스텁)을 드론 시스템에 맞게 포팅해야 합니다.
Q&A (방법론)
Q: LibFuzzer에 입력을 줄 지점 (퍼징 타겟)은 어떻게 선정했습니까? 그리고 그 과정에서 문제점은 없었나요?
A: 정적 분석을 사용했습니다. (이에 대해 “그럴 거면 왜 퍼징을 돌렸냐"는 반문이 있을 수 있지만, 정적 분석은 버그가 아닌 ‘퍼징 지점’을 찾는 데 사용되었습니다.)
드론 시스템은 여러 컴포넌트로 구성되는데, 외부 센서와만 상호작용하는 부분은 퍼징이 어렵습니다. 따라서 정적 분석을 통해 MAVLink 메시지를 직접 수신하는 컴포넌트들을 선별적으로 식별할 필요가 있었습니다.
또한, 단순히 프로그램 가동 여부 (했다/안 했다)뿐만 아니라, 구체적인 실행 방법 (예: command line 인수)까지 분석해야 했습니다.
Q: 정적 분석을 구체적으로 어떻게 활용했습니까?
A: 수동 분석 이었습니다. 소스 코드는 물론, 바이너리 디컴파일 코드를 직접 검토하며 분석했습니다.