The Windows IOCTL Census: A Corpus-Scale, Multi-Architecture Database of the Driver Control-Code Surface

기술 요약: Windows IOCTL 센서스 (The Windows IOCTL Census)

문제 정의
Windows의 디바이스 제어 경로는 권한이 없는 프로세스가 I/O 제어(IOCTL) 코드를 통해 커널 메모리에 도달할 수 있는 핵심적인 공격 표면을 나타낸다. 체크되지 않은 버퍼 길이와 같은 이 경로의 취약점은 권한 상승을 허용한다. 보안 커뮤니티는 특정 취약점을 찾기 위해 드라이버를 심볼릭 실행하는 스캐너(예: ScrewedDrivers, POPKORN, ioctlance)와 알려진 악성 드라이버를 추적하는 큐레이션된 리스트(예: LOLDrivers)를 보유하고 있지만, 전체 드라이버 생태계 전반에 걸친 제어 코드 디스패치 표면에 대한 체계적이고 지속적인 지도는 존재하지 않는다. 기존의 심볼릭 도구들은 경로 폭발(path explosion), 높은 미검출률(false-negative), 그리고 구조적 한계 문제를 겪는다. 특히, 이들은 배포되는 드라이버 코퍼스의 약 절반을 차지하며 "취약한 드라이버 가져오기(Bring Your Own Vulnerable Driver, BYOVD)" 공격에 자주 악용되는 32비트(x86) 드라이버 분석에서 실패하는 경우가 많다. 또한, 이러한 도구들은 일회성 결과 리스트만을 생성하고 복구된 구조적 데이터를 폐기하므로, 드라이버 간 교차 분석이나 재평가를 방지한다.

방법론
저자들은 27,087개의 서명된 Windows 드라이버 코퍼스를 세 단계(Recover, Enrich, Rank)로 처리하는 결정론적이고 아키텍처 중립적인 파이프라인인 Windows IOCTL 센서스를 제안한다.

1. Recover (결정론적 패스):

   • 아키텍처: 이 단계는 심볼릭 실행을 완전히 배제한다. 대신, glaurung 프레임워크를 사용하여 드라이버 바이너리를 아키텍처 중립적인 중간 표현(IR)으로 리프팅(lifting)한다.
   • 디스패치 복구: 비교 상수와 점프 테이블을 분석하여 IRP_MJ_DEVICE_CONTROL 핸들러를 식별하고 제어 코드를 디코딩한다. 이 접근 방식은 x64 및 x86 아키텍처 모두에서 디스패치 표면을 성공적으로 복구한다.
   • 구조적 분석: x64 드라이버의 경우, 파이프라인은 드라이버 간 호출 그래프(inter-procedural call graphs)를 구축하고, 디스패치 루틴으로부터 도달 가능성 분석을 수행하며, 경량 테인트 분석(taint analysis)을 실행한다. 테인트 소스는 버퍼링된 입력 포인터(Irp->AssociatedIrp.SystemBuffer)이며, 이를 싱크(dereferences 또는 stores)까지 추적하여 검증되지 않은 제어 입력을 식별한다.
   • 출처(Provenance): PE 메타데이터, Authenticode 서명 정보, 그리고 허용적인 액세스 제어 목록(ACL)을 플래그 처리하기 위한 디바이스 보안 디스크립터(SDDL)를 추출한다.
   • 제약 사항: 분석은 드라이버 크기(4MB 초과 시 전체 디스어셈블리 생략)와 아키텍처(x86은 독립적인 검증 오라클의 부재로 인해 표면 분석만 수행)에 의해 제한된다.

2. Enrich (모델 패스):

   • 타겟팅: 이 단계는 허용적인 디바이스 디스크립터를 가지고 있으며 적어도 하나의 검증되지 않은 버퍼드-입력 싱크를 포함하는 드라이버의 디스패치 루틴이라는 좁고 우선순위가 높은 하위 집합에 대해서만 실행된다.
   • LLM 통합: 대규모 언어 모델(LLM)에 컴팩트한 특징 요약(디바이스 디스크립터, 디코딩된 코드, 테인트 싱크 상세 정보, 디스어셈블리 발췌본)을 프롬프트로 제공하여 구조화된 판결을 생성한다. 모델은 환각(hallucination)을 피하기 위해 원시 디컴파일된 바이트를 보지 않도록 명시적으로 지시받으며, 결정론적인 사실에 의존한다. 판결에는 위험 수준, 프리미티브 유형(예: out-of-bounds write) 및 근거가 포함된다.

3. Rank (쿼리 인터페이스):

   • 시스템은 관계형 뷰를 통해 데이터를 노출한다. 주요 뷰로는 검증되지 않은 싱크 개수에 따라 사용자 도달 가능 핸들러를 순위 매기는 "hunt" 뷰, 공급업체 간 공유되는 제어 코드를 그룹화하는 "cross-driver" 뷰, 그리고 정적 테인트 결과와 인입된 심볼릭 실행 결과를 비교하는 "oracle-agreement" 뷰가 있다.

주요 기여

• 공개 가능한 쿼리 가능 데이터베이스: 저자들은 27,087개의 바이너리, 310만 개의 디코딩된 제어 코드, 818만 개의 함수, 1,595만 개의 호출 엣지를 포함하는 데이터셋을 공개한다.
• 아키텍처 중립적 커버리지: 심볼릭 실행 대신 IR 리프팅을 사용함으로써, 저자들은 심볼릭 스캐너가 일반적으로 중단되는 32비트 x86 절반을 포함하여 코퍼스의 80%(21,708개 드라이버)에 대한 디스패치 표면을 복구했다.
• 구조적 지속성: 발견된 버그를 찾은 후 구조를 폐기하는 기존 도구와 달리, 이 센서스는 호출 그래프, 테인트 싱크, 디코딩된 코드를 지속적으로 저장하여 "이 특정 제어 코드를 공유하는 드라이버는 무엇인가?" 또는 "어떤 핸들러가 길이 체크 없이 복사 싱크에 도달하는가?"와 같은 쿼리를 가능하게 한다.
• 하이브리드 검증: 시스템은 정적 테인트 분석을 심볼릭 실행 결과(ioctlance 경유)와 통합하여 결과의 상호 검증을 수행하며, 두 방법이 서로 보완적인 사각지대(예: 정적 테인트는 METHOD_NEITHER 코드를 놓치고, 심볼릭 실행은 경로 폭발 문제로 어려움을 겪음)를 가지고 있음을 입증한다.

결과

• 커버리지: 결정론적 패스는 21,708개 드라이버에 대한 디스패치 표면을 복구했다. x64 딥 레인(deep lane)은 818만 개의 함수와 63,263개의 버퍼드-입력 테인트 싱크를 생성했다.
• 필터링 효율성: 결정론적 필터(허용적인 디스크립터 + 검증되지 않은 싱크)는 27,087개의 드라이버를 LLM 강화를 위한 330개의 후보 핸들러로 좁혔다.
• 모델 성능: LLM은 강화된 329개 핸들러 중 135개를 "critical", 159개를 "high"로 평가했다. 저자들은 이것이 확정된 버그가 아니라 우선순위 가설임을 강조하며, 보고된 참 양성(true-positive) 비율은 없다.
• 방법 간 일치성: 1,000개 드라이버 샘플에 대해 ioctlance와 비교했을 때, 두 방법은 심볼릭 엔진이 플래그를 지정한 드라이버의 65%에서 일치했다. 불일치는 주로 정밀도 오류보다는 심볼릭 엔진이 특정 핸들러에 도달하지 못하는 능력의 한계(reachability ceiling)에서 기인했다.
• 백테스팅: 알려진 CVE 및 LOLDrivers 카탈로그에 대한 백테스트 결과, 랭킹이 해당 범위 내에서 효과적임을 보여주었다(예: nvlddmkm.sys의 알려진 취약한 핸들러가 상위 0.14% 내에 위치함). 그러나 시스템은 버퍼드-입력 테인트 소스 이외의 메커니즘을 통해 입력이 전달되는 프레임워크 드라이버(WDF/KMDF)의 취약점은 놓쳤다.

의의 및 주장
본 논문은 새로운 버그의 존재를 증명하는 취약점 탐지기가 아니라, Windows 드라이버 제어 코드 표면에 대한 기초적인 지도로서의 중요성을 주장한다.

• 탐지에서 탐색으로의 전환: 저자들은 커뮤니티가 희소한 역공학 자원을 우선순위에 두기 위해 공격 표면에 대한 지속적이고 쿼리 가능한 기록이 필요하다고 주장한다. 이 센서스는 연구자들이 운이나 수동 선택에 의존하는 대신 "롱 테일(long tail)"의 배포 드라이버를 탐색할 수 있게 한다.
• 접근의 민주화: 저자들은 이중 사용(dual-use) 악용을 방지하기 위해 특정 타겟팅 계층(테인트 싱크 및 모델 판결)은 공개하지 않으면서, 구조적 데이터(디코딩, 호출 그래프, 도달 가능성)를 공개함으로써 드라이버 보안 분석의 진입 장벽을 낮추고자 한다.
• 상호 보완성: 이 작업은 결정론적 복구와 심볼릭 실행이 상호 보완적임을 보여준다. 센서스는 이러한 방법들이 서로의 사각지대를 확인하고 보완할 수 있도록 구조적 맥락을 제공한다.
• 향후 과제: 저자들은 x86 및 arm64에 대한 테인트 분석 부재, METHOD_NEITHER 및 직접 I/O 경로의 제외, 런타임에 적용되는 디바이스 디스크립터 처리 불가 등의 한계를 인정한다. 이들은 센서스를 핵심 구조를 다시 구축하지 않고도 새로운 분석기(예: 프레임워크 드라이버 또는 물리 메모리 프리미티브용)를 추가할 수 있는 살아있는 인프라로 규정한다.