기술 요약: 리눅스 커널 CVE 트리거 가능성 평가를 위한 1-최소 트리거 구성 추론

문제 정의

리눅스 커널 취약점(CVE)을 평가하는 벤더들은 중요한 격차에 직면해 있다: 특정 커널 버전이 "영향을 받음(affected)"을 아는 것이, 해당 버전이 자신들의 특정 프로덕션 맞춤형 구성 하에서 반드시 **트리거 가능하다(triggerable)**는 것을 보장하지는 않는다는 점이다. 업스트림 재현 도구 및 취약점 데이터베이스(예: NVD)는 종종 구성 수준의 맥락(context)이 부족하며, 업스트림 재현 환경은 다운스트림 제품 커널과는 크게 다른, 기능이 풍부하고 커버리지 중심적인 구성(예: syzbot)을 사용한다.

KernJC와 같은 기존의 자동화된 접근 방식은 관련 옵션을 추론하기 위해 정적 Kconfig 의존성 그래프에 의존한다. 그러나 이러한 방법들은 다음과 같은 세 가지 주요 한계점을 가진다:

1. 과잉 근사(Over-approximation): 실제 런타임 트리거 경로와 무관한 방대한 옵션 세트를 추론한다.
2. 버전 민감성(Version Sensitivity): 정적 의존성 그래프는 진화하는 의존성 관계로 인해 커널 버전 간에 잘 일반화되지 않는다.
3. make olddefconfig 검증의 부재: .config에 작성된 구성은 전제 조건(예: depends on, select 체인)이 충족되지 않을 경우 make olddefconfig 프로세스 중에 조용히 롤백될 수 있다. 이는 "정확한 식별을 했으나 재현에는 실패한" 시나리오, 즉 핵심 옵션이 빌드 시스템에 의해 비활성화되는 상황을 초과하게 된다.

핵적인 과제는 Kconfig 제약 조건을 충족하면서, make olddefconfig 이후에도 유효하며, PoC(개념 증명)가 가용할 때 정의된 평가 프로토콜 하에서 취약점을 성공적으로 트리거할 수 있는 1-최소(1-minimal, 부분 집합 최소) 구성을 추론하는 것이다.

방법론: FCC 프레임워크

저자들은 트리거 구성을 추론하고 최소화하기 위해 3단계로 작동하는 자동화된 프레임워크인 **FCC (FindCveConfig)**를 제안한다.

1단계: 후보 식별 (Candidate Identification)

FCC는 비정형 취약점 아티팩트(NVD 설명, CWE, 패치, PoC 및 외부 참조)를 분석하여 구성 관련 단서를 추출한다.

• 단서 정규화(Cue Normalization): 시스템은 증거를 의미론적 단서(트리거 메커니즘, 컴포넌트, 전제 조건)와 빌드-증거 단서(파일 경로, 모듈 이름, 매크로)로 정규화한다.
• LLM 가이드 매핑: 대규모 언어 모델(LLM)은 Kconfig 및 Makefile 명세를 분석하여 이러한 정규화된 단서를 특정 CONFIG_* 옵션에 매핑하는 데만 사용된다.
• 출력: 잠재적으로 관련 있는 옵션들의 초기 후보 세트 $C$.

2단계: 의존성 완성 (Dependency Completion)

이 단계는 make olddefconfig로 인해 발생하는 "세트 $\neq$ 유효함" 실패 모드를 해결한다.

• 피드백 루프: FCC는 후보 세트를 베이스라인 .config에 주입하고 make olddefconfig를 실행한다.
• 제약 조건 해결: 옵션이 롤백(비활성화)되면, FCC는 Kconfig 코퍼스를 분석하여 누락된 전제 조건을 식별한다. 이는 다음을 처리한다:
  • 순방향 의존성: depends on 제약 조건.
  • 암시적 활성화: select에 의한 경로(예: 특정 드라이버를 활성화하여 코어 서브시스템을 select하는 경우).
  • 조건부 컨텍스트: if/source 블록.
• 반복적 수선(Iterative Repair): 시스템은 타겟 옵션이 안정적으로 활성화되거나 만족 가능한 브랜치가 발견될 때까지 누락된 전제 조건을 반복적으로 추가한다. 이 과정은 옵션 간의 관계를 나타내는 의존성 그래프 $G$를 구축한다.

3단계: 구성 최소화 (Configuration Minimization)

2단계의 유효한 세트 $S$와 의존성 그래프 $G$를 사용하여, FCC는 세트를 1-최소 경계($S_{min}$)로 축소한다.

• 런타임 검증: 최소화는 **트리거 오라클(trigger oracle)**에 의해 가이드된다. 각 후보 옵션에 대해, FCC는 옵션을 일시적으로 제거하고, 커널을 다시 빌드하며, QEMU/KVM 환경에서 부팅한 후 PoC를 실행한다.
• 1-최소성 기준: 옵션은 구성이 여전히 유효하고( make olddefconfig 및 빌드 체크 통과) PoC가 여전히 일치하는 트리거 증거(예: 특정 크래시 시그니처 또는 KASAN 보고서)를 생성하는 경우에만 제거된다.
• 토폴로지 가이드 프루닝(Topology-Guided Pruning): 알고리즘은 연쇄적인 비활성화를 최소화하기 위해 의존성이 없는 옵션($D_{in}=0$)을 우선적으로 제거하여 검색이 효율적으로 수렴하도록 한다.

주요 기여

1. 최소 트리거 구성 추론의 공식화: 논문은 빌드 가능하면서도 프로덕션 제약 조건 하에서 트리거 가능하도록 설계된 작고 감사 가능한 구성 경계를 도출하는 작업을 정의한다.
2. FCC 프레임워크: LLM 기반의 후보 마이닝과 결정론적인 make olddefconfig 검증 및 런타임 트리거 최소화를 결적으로 결합한 새로운 파이프라인을 제공한다. 결정적으로, LLM은 후보 생성 및 파싱으로 제한되며, 모든 구성의 유효성은 빌드 시스템에 의해 검증된다.
3. Kconfig 제약 기반 의존성 완성: 핵심 옵션이 make olddefconfig에서 살아남도록 전제 조건을 재귀적으로 추론하고 수선하는 메커니즘을 제공하여, '조용한 롤백' 문제를 해결한다.
4. 런타임 검증된 최소화: 동적 트리거 증거를 사용하여 구성을 1-최소 세트로 프루닝하는 알고리즘을 통해, 구성이 이론적으로 충분할 뿐만 아니라 운영상으로도 효과적임을 보장한다.

실험 결과

프레임워크는 여러 커널 버전에 걸친 88개의 리눅스 커널 CVE(KernJC 32개, KernelCTF 56개)를 대상으로 평가되었다.

• 중복성 감소 (RQ1): KernJC와 비교했을 때, FCC는 커버리지를 유지하면서 후보 세트 크기를 크게 줄였다. KernJC 데이터셋에서 평균 후보 세트 크기는 CVE당 69.00(KernJC)에서 14.72(FCC)로 감소했다. KernelCTF에서 FCC는 평균 27.51개의 옵션으로 94.6%의 커버리지를 달ian했으며, 이는 KernJC의 201.76개와 대조적이다.
• make olddefconfig 이후의 유효성 (RQ2): FCC는 "olddef-only" 주입 베이스라인을 사용했을 때의 구성 성공률(모든 핵심 옵션이 활성 상태로 유지되는 비율)을 62.5%(55/88)에서 96.6%(85/88)로 향상시켰다. 남은 실패 사례는 알고리즘 결함이 아닌 하드웨어 환경 제약(예: 아키텍처 특정 옵션)에 기인했다.
• 최소화 효율성 (RQ3): 실행 가능한 PoC가 있는 32개의 KernJC CVE에 대해, FCC는 유효 구성 세트를 평균 14.72개의 옵션에서 최종 1-최소 경계인 1.63개로 줄였다(88.93% 감소). 모든 최소화된 구성은 트리거 증거를 성공적으로 재현했다.
• 비용 분석 (RQ4): 1단계(후보 식별)가 오버헤드의 대부분을 차지했다. 그러나 CVE 중심의 증거 선택 변형을 사용하면 1단계 시간과 토큰 비용을 각각 약 73% 및 53% 줄일 수 있었다. 2단계는 가벼웠으며, 3단계 비용은 필수적인 커널 컴파일 및 VM 부팅 사이클을 반영했다.

의의 및 범위

본 논문은 FCC가 벤더들에게 배포 구성에 대한 트리거 가능성 범위를 결정할 수 있는 명확하고 도구로 지원되는 결정선을 제공한다고 주장한다. FCC는 감사 가능한 1-최소 구성 경계를 반환함으로써, 단순히 소스 코드에 존재하는 취약점과 특정 프로덕션 설정 하에서 실제로 악용 가능한 취약점을 구분하는 데 도움을 준다.

저자들은 다음과 같이 주장의 겸손함을 강조한다:

• FCC는 독립적인 악용 가능성 보장이 아닌 **구성 수준의 트리거 술어(predicate)**를 출력한다.
• 트리거 가능성은 실행 가능한 PoC와 특정 평가 환경(업스트림 QEMU/KVM)의 가용성에 따라 조건부적이다.
• 프레임워크는 악용 코드를 합성하거나 배포별 패치 스택 또는 독점 하드웨어 의존성을 처리하지 않는다. 이는 트리거 가능성에 필요한 구성 전제 조건을 식별하는 것이다.

이 연구는 단순한 버전 매칭을 넘어 구성 인지적(configuration-aware) 위험 평가로 나아감으로써 취약점 관리의 중요한 격차를 해결한다.