[논문 리뷰] Fuzzm: Finding Memory Bugs through Binary-Only Instrumentation and Fuzzing of WebAssembly

Daniel Lehmann, Martin Toldam Torp외 1명|arXiv (Cornell University)|2021. 10. 28.

Security and Verification in Computing인용 수 6

한 줄 요약

Fuzzm은 소스 코드 없이 실전 WebAssembly 바이너리에서 메모리 버그를 탐지하고, 스택 및 힙 캐나리 인스트루먼테이션과 효율적인 커버리지 피드백, AFL 스타일의 입력 생성을 결합한 최초의 바이너리 전용 회색상자 패러다임 퍼저이다. 이는 소스 코드 없이도 실전 WebAssembly 바이너리에서 메모리 버그를 탐지하고, 실제 바이너리에서 수십 건의 크래시를 유도하며, 악용을 방지하기 위한 저비용 바이너리 하드닝을 가능하게 한다.

ABSTRACT

WebAssembly binaries are often compiled from memory-unsafe languages, such as C and C++. Because of WebAssembly's linear memory and missing protection features, e.g., stack canaries, source-level memory vulnerabilities are exploitable in compiled WebAssembly binaries, sometimes even more easily than in native code. This paper addresses the problem of detecting such vulnerabilities through the first binary-only fuzzer for WebAssembly. Our approach, called Fuzzm, combines canary instrumentation to detect overflows and underflows on the stack and the heap, an efficient coverage instrumentation, a WebAssembly VM, and the input generation algorithm of the popular AFL fuzzer. Besides as an oracle for fuzzing, our canaries also serve as a stand-alone binary hardening technique to prevent the exploitation of vulnerable binaries in production. We evaluate Fuzzm with 28 real-world WebAssembly binaries, some compiled from source and some found in the wild without source code. The fuzzer explores thousands of execution paths, triggers dozens of crashes, and performs hundreds of program executions per second. When used for binary hardening, the approach prevents previously published exploits against vulnerable WebAssembly binaries while imposing low runtime overhead.

연구 동기 및 목표

• C 및 C++와 같은 안전하지 않은 언어에서 컴파일된 WebAssembly 바이너리의 메모리 취약성에 의한 증가하는 보안 위험을 해결하기 위해.
• WebAssembly에 내장된 메모리 안전 메커니즘(예: 스택 캐나리 및 페이지 보호)의 부재로 인해 네이티브 코드보다 악용이 더 수월해지는 문제를 해결하기 위해.
• 기존 퍼징 워크플로우와 호환되는 바이너리 전용 인스트루먼테이션 및 피드백 파이프라인 설계를 통해 소스 코드 없이도 효과적인 WebAssembly 바이너리 퍼징을 가능하게 하기 위해.
• 실제로 사용 가능하고 효율적이며 구현 가능한 솔루션을 제공하여 기존 WebAssembly 바이너리의 메모리 버그 탐지 및 하드닝을 실전 환경에서 수행하기 위해.

제안 방법

• 런타임에 오버플로우 및 언더플로우를 탐지하기 위해 WebAssembly 바이너리에 스택 및 힙 캐나리 인스트루먼테이션을 적용하여, 퍼징 오라클과 동시에 바이너리 하드닝 메커니즘으로 기능시키기 위해.
• 컴파일러 삽입 코드나 아키텍처에 종속적인 동적 바이너리 인스트루먼테이션에 의존하지 않는 경량의 바이너리 전용 커버리지 인스트루먼테이션을 구현하여 실행 경로를 추적하기 위해.
• AFL의 입력 생성 엔진을 WebAssembly VM과 통합하여 WebAssembly 바이너리의 효율적이고 고처리량 퍼징을 가능하게 하기 위해.
• 퍼저와 대상 프로그램이 WebAssembly VM 내에서 동일한 주소 공간을 사용하도록 설계하여 오버헤드를 감소시키고 효율적인 피드백 수집을 가능하게 하기 위해.
• 힙 버퍼의 할당 해제 시점에 캐나리 검사를 적용하여 성능 비용을 최소화하면서도 악용 탐지 능력을 유지하기 위해.
• 실제 28개의 WebAssembly 바이너리(소스에서 컴iles된 것과 외부에서 확보한 것 포함)를 대상으로 접근 방식을 검증하기 위해.

실험 결과

연구 질문

• RQ1 소스 코드 접근 없이도 바이너리 전용 퍼저가 WebAssembly 바이너리의 메모리 취약성을 효과적으로 탐지할 수 있는가?
• RQ2 표준 컴파일러 방지 조치가 없는 상황에서 캐나리 기반 인스트루먼테이션이 WebAssembly 바이너리의 스택 및 힙 오버플로우를 얼마나 효과적으로 탐지할 수 있는가?
• RQ3 컴파일러 삽입 인스트루먼테이션에 의존하지 않고도 WebAssembly 바이너리에 효율적으로 커버리지 인스트루먼테이션을 적용하여 퍼징을 이끄는 데에 유용한가?
• RQ4 제안된 인스트루먼테이션의 성능 오버헤드는 얼마이며, 고처리량 퍼징(예: 1초당 수백 건의 실행)을 지원할 수 있는가?
• RQ5 퍼징에 사용된 동일한 인스트루먼테이션은 실전에서 알려진 취약점을 악용하는 것을 방지하기 위한 실용적인 바이너리 하드닝 기법으로도 기능할 수 있는가?

주요 결과

• Fuzzm은 실전에서 사용되는 28개의 WebAssembly 바이너리에서 수십 건의 크래시를 성공적으로 유도하여 메모리 취약성을 드러내는 데 효과적임을 입증했다.
• 퍼저는 1초당 수백 건의 프로그램 실행 성능을 달성하여, 네이티브 코드 대비 WebAssembly의 본질적 성능 오버헤드가 있음에도 불구하고 실용적임을 입증했다.
• 캐나리 인스트루먼테이션은 스택 및 힙 오버플로우를 모두 탐지했으며, WebAssembly의 선형 메모리 모델로 인해 스택에서 힙 데이터로의 오버플로우가 일반적으로 감지되지 않기 쉬운 경우에도 효과적으로 탐지했다.
• 커버리지 인스트루먼테이션은 AFL 스타일의 입력 생성을 위한 효과적인 피드백을 제공하여 대상 바이너리에서 수천 개의 실행 경로 탐색을 가능하게 했다.
• 동일한 캐나리 인스트루먼테이션은 별도의 하드닝 기법으로 사용되었을 때 이전에 발표된 취약한 WebAssembly 바이너리에 대한 악용을 성공적으로 방지했다.
• 이 접근 방식은 낮은 런타임 오버헤드를 유발하여 재컴파일 없이도 기존 바이너리를 보호하기 위해 실전 환경에 배포하기에 적합하다.