PROBE: 익스플로잇 가능성을 기준으로 커널 퍼징하기

개요

PROBE 는 Google syzkaller를 기반으로 만든 exploit-guided kernel fuzzer다.

기존 커널 퍼저는 보통 coverage-guided 방식으로 동작한다. 더 많은 코드 경로를 실행하고, 새로운 coverage가 나오면 좋은 입력으로 판단한다. 이 방식은 강력하지만, 보안 취약점 분석 관점에서는 아쉬운 지점이 있다.

새로운 coverage가 항상 exploitability가 높은 버그로 이어지는 것은 아니다. 반대로 coverage 증가는 작아도, 특정 heap object가 빠르게 재사용되거나, free 이후 write가 발생하거나, 권한 상승에 가까운 런타임 신호가 보이면 보안적으로 훨씬 더 중요한 입력일 수 있다.

PROBE는 이 지점을 목표로 잡았다.

목표: 더 많은 coverage가 아니라, 더 위험해 보이는 kernel state를 더 오래 파고들기

즉 coverage는 여전히 탐색 수단으로 사용하지만, 최종적으로는 UAF, OOB, double-free, cross-cache, privilege escalation 가능성이 높은 흐름을 더 우선적으로 추적한다.

왜 exploit-guided인가

syzkaller는 이미 매우 잘 만들어진 커널 퍼저다. corpus 관리, coverage 피드백, repro 생성, crash dedup, dashboard까지 퍼징에 필요한 많은 요소가 갖춰져 있다.

그래서 PROBE에서 새로 만들고 싶었던 것은 "또 다른 퍼저"가 아니라, syzkaller 위에 exploitability를 보는 레이어를 얹는 것이었다.

내가 보고 싶었던 질문은 이런 쪽에 가까웠다.

이 crash는 단순 WARNING인가, memory corruption으로 이어질 가능성이 있는가?

crash가 아직 안 났더라도 UAF에 유리한 heap reuse 패턴이 있었는가?

특정 syscall 조합이 slab reuse, double-free, write-to-freed 신호를 반복해서 만들고 있는가?

LLM이 crash log와 fuzzing state를 보고 다음 mutation 방향을 제안할 수 있는가?

Focus Mode가 고위험 입력을 더 오래 파고들면 실제로 추가 coverage나 variant가 생기는가?

그래서 PROBE는 크게 세 가지 피드백을 섞는다.

coverage feedback + runtime exploitability signal + AI triage / strategy feedback

전체 구조

구조는 단순하게 보면 host의 syz-manager와 guest VM의 syz-executor 사이에 eBPF 기반 관측 레이어를 추가한 형태다.

Host syz-manager - crash filtering / dedup - AI triage - Focus Mode scheduler - DEzzer mutation scheduler - web dashboard

Guest VM syz-executor - syscall execution - coverage collection - eBPF metrics read/reset

Kernel eBPF programs - kmalloc / kfree tracepoint - kmemcachealloc / kmemcachefree kprobe - commitcreds / copyfromuser 계열 관측 - page alloc/free, fd lifecycle, race signal 관측

중요한 제약은 Linux kernel source를 직접 수정하지 않는 것이다. 커널에는 KASAN, BPF, KPROBES 같은 설정만 켜고, 실제 관측은 tracepoint와 kprobe 기반 eBPF 프로그램으로 붙인다.