The Linux IOCTL Census: A Source-Derived Database of the Linux Kernel Control-Code Surface

기술 요약: 리눅스 IOCTL 센서스 (The Linux IO $\text{CT}$ Census)

문제 정의
ioctl 시스템 콜은 장치 제어를 위한 리눅스의 주요 인터페이스 역할을 하며, 사용자 공간 프로그램이 숫자 명령 코드와 인자 버퍼를 커널 드라이버로 보낼 수 있게 합니다. 하드웨어 구성 및 상태 관리에 필수적이지만, 이 인터페이스는 방대하고 이질적이며 제대로 목록화되지 않은 로컬 공격 표면을 나타냅니다. 드라이버들은 수천 개의 고유한 명령을 정의하며, 종종 균일한 검증 없이 커널 컨텍스트 내에서 인자를 파싱합니다. 검증되지 않은 인자 길이를 신뢰하는 핸들러는 범위를 벗어난 메모리 읽기 또는 쓰기를 초래할 수 있습니다.

현재의 분석 접근 방식은 파편화되어 있습니다:

• 동적 스캐너 (예: syzkaller): 실행 시점의 버그와 레이스 컨디션을 찾는 데는 효과적이지만, 명시적으로 실행하도록 지시된 특정 명령 공간에 국한됩니다. 이들은 트리거된 버그를 보고할 뿐, 아직 탐색되지 않은 명령 공간을 보고하지 않습니다.
• 수동 큐레이션: unprivileged-reach LPE 카탈로그나 위협 모델 문서와 같은 목록들이 존재하지만, 이는 체계적이고 쿼리가 가능한 열거형이 아닌, 수기로 관리되는 산문 형태의 자료입니다.

디스패처(dispatcher), 디코딩된 명령, 핸들러, 그리고 권한 게이트(permission gate)를 포함하여 전체 정적 명령 표면을 매핑하는 지속적인 소스 기반 인벤토리가 부족한 실정입니다.

방법론: Extract-Gate-Rank
저자들은 리눅스 커널 소스 코드를 읽어 ioctl 표면을 관계형 데이터베이스로 구체화하는 결정론적 파이프라인인 Extract-Gate-Rank를 제시합니다. 이 프로세스는 169개 서브트리에 걸친 878개 모듈을 포함하는 allmodconfig 빌드(x86_64)를 대상으로 동작합니다.

1. Extract (추출):

   • libclang 기반의 지식 그래프를 활용하여 unlocked_ioctl, compat_ioctl, 또는 proc_ops.proc_ioctl에 바인딩된 ioctl 디스패처 함수를 식별합니다.
   • 호출 클로저(call closures)를 따라가며 각 명령 핸들러 본체로 이동합니다.
   • 명령 코드 디코딩: _IOC 매크로를 UAPI 헤더에 대해 리졸버(resolver)를 실행하여, 32비트 명령 코드를 네 가지 필드(방향, 크기, magic byte, ordinal)로 확장하여 디코딩합니다.
   • Sink 및 Gate 식별: 제어된 입력 Sink(예: copy_from_user)와 권한 게이트(capability checks, LSM hooks, f_mode checks)를 기록합니다.
   • Sanitization 휴리스틱: 동일한 함수 소스 순서 내에서 선행하는 하드 바운드 체크가 존재하지 않으면 해당 Sink를 "unsanitized(미검증)"로 표시합니다. 이는 구조적 대리 지표(proxy)이며, 제어 흐름의 증명은 아닙니다.

2. Gate (게이트):

   • 위협 모델 도달 가능성 필터를 쿼리 가능한 컬럼으로 적용합니다.
   • 모듈에 hard init-namespace capability gate(예: CAP_SYS_ADMIN)가 없는 경우 해당 모듈을 capability_ungated로 표시합니다.
   • 이는 unprivileged reach에 대한 필요 조건 상한선(upper bound) 역할을 하며, 실제 노드 개방 가능성(node-openability)을 분류하는 것은 아닙니다. 커널 문서에 따라 스테이징 드라이버 및 debugfs 경로를 제외합니다.

3. Rank (순위 지정):

   • 저장소에 대한 관계형 뷰를 생성하여, capability-ungated 디스패처와 unsanitized sink를 우선순위에 둡니다.
   • 서로 다른 드라이버 간에 공유되는 명령 코드(type, ordinal, access)를 그룹화하는 교차 모듈 뷰를 포함합니다.
   • 트리아지(triage)를 위한 선택적 LLM 인리치먼트 레이어가 포함되어 있으나, 이는 크리티컬 패스에서 제외되며 유보된 티어(withheld tier)로 유지됩니다.

주요 결과
본 센서스는 x86_64 allmodconfig 빌드(인트리 소스 파일의 84%)를 다루며, 검증을 위해 arm64 빌드를 보조적으로 포함합니다.

• 규모: 분석 결과 337개 모듈에 걸쳐 586개의 ioctl 디스패 엔트리 포인트를 복구하였으며, 1,289개의 고유한 _IOC 명령 코드를 디코딩하였습니다.
• Sinks 및 Gates: 3,583개의 제어된 입력 Sink와 1,298개의 권한 게이트를 식별하였습니다.
• 도달 가능성: 위협 모델 필터는 hard capability gate 뒤에 있는 50개 모듈을 제외하였고, unprivileged reach의 상한선으로서 281개 모듈을 허용하였습니다.
• 아키텍처 커버리지: arm64를 위한 두 번째 빌드는 단 하나의 고유 모듈(Apple adp_drv)만을 추가했을 뿐 새로운 명령 코드를 추가하지 않았으며, 이는 x86_64가 ioctl을 보유한 모듈의 99.7%를 커버함을 나타냅니다.
• 명령 공유: 공유 명령 패턴(예: watchdog WDIOC_* 명령)은 여러 드라이버에서 반복되며, 이는 공유 패턴의 취약점이 여러 모듈에 동시에 영향을 미칠 수 있음을 시사합니다.
• Capability 집중도: 권한 게이트는 CAP_SYS_ADMIN(512회 발생)에 의해 지배되며, 이는 커널 위협 모델에서 명시적으로 "모델 외(out of model)"로 취급하는 기능으로, 조사 범위(in-scope)를 더욱 좁힙니다.

백테스트 검증
저자들은 본 센서스를 22개의 최근 인트리 ioctl CVE와 대조하여 검증하였습니다:

• 커버리지: 22개 CVE 모두 커버된 서브트리 내에 존재하였으며, 이를 통해 커버리지 공백이 오류의 원인이 아님을 입증하였습니다.
• 복구: 디스패처-복구 패스를 통해 22개 중 7개 CVE의 취약한 핸들러를 찾아냈습니다.
• 누락: 15건의 누락은 전적으로 등록 모델의 한계에 기인하였습니다:
  • 8건은 ops-table 디스패(drm_ioctl_desc, v4l2_ioctl_ops)를 사용하는 DRM/V4L2 코어와 관련되었으며, 여기서 코어가 개별 명령 핸들러에 전달하기 전에 인자를 복사합니다.
  • 3건은 tty 라인 디스플린과 관련되었습니다.
  • 4건은 디스패처 아래의 호출자(callee)로서만 도달되는 함수였습니다.
• 필터 정확도: 필터는 발견된 7개의 CVE를 모두 올바르게 허용하였습니다. 두 건은 노드-DAC(장치 접근 제어) 제한(예: pci_endpoint_test)에 관한 "오탐 허용(false admits)"이었으나, 본 방법론이 장치 노드 권한이 아닌 capability gate만을 분석한다는 점을 고려할 때 이는 올바른 예측입니다.

의의 및 주장
본 논문은 Linux IOCTL Census를 버그 탐색 도구가 아닌 측정 및 데이터셋 기여로 규정합니다. 그 주요 의의는 다음과 같습니다:

1. 지속성 및 쿼리 가능성: ioctl 표면을 일시적인 버그 목록에서 지속적이고 쿼리 가능한 관계형 저장소로 변환합니다. 이를 통해 감사자는 버그 목록이 답할 수 없는 구조적 질문(예: "어떤 모듈이 이 명령 코드를 공유하는가?")을 던질 수 있습니다.
2. 위협 모델 통합: 커널의 문서화된 위협 모델을 데이터 스키마에 직접 인코딩하여, 산문 형태의 보안 경계를 쿼리 가능한 필터로 전환합니다.
3. 상호 보완성: 동적 퍼징을 보완하여, 퍼징 하네스나 설명이 부족할 수 있는 영역을 포함한 전체 정적 명령 공간을 열거함으로써 동적 도구가 탐색되지 않은 영역을 향하도록 가이드합니다.

• 교차 OS 스키마: 본 데이터셋은 윈도우 IOCTL 센서스와 동일한 스키마를 공유하여 교차 플랫폼 쿼리를 가능하게 합니다.

한계
저자들은 다음과 같은 몇 가지 한계를 명시합니다:

• 도달 가능성: "사용자 도달 가능(user-reachable)" 수치는 capability gate에 기반한 상한선이지, DAC(장치 접근 제어)에 따른 노드 개방 가능성에 대한 증명이 아닙니다.
• Sanitization: "미검증(unsanitized)" 수치는 소스 순서에 기반한 휴리스틱 대리 지표이며, 안전성에 대한 형식적 증명이 아닙니다.
• 커버리지: allmodconfig 빌드에서 컴파일되는 내용으로 제한됩니다. 따라서 다른 아키텍처나 동시에 활성화될 수 없는 드라이버는 제외됩니다.
• 등록 모델: 현재 모델은 ops-table(DRM, V4L2), tty 라인 디스플린, 또는 디스패처 아래의 헬퍼 함수를 통해 등록되는 핸들러를 놓칩니다.

데이터셋은 두 가지 티어로 공개됩니다: 오픈 라이선스 하의 공개 구조적 티어(모듈, 디스패처, 코드, 게이트)와, 이중 용도 악용을 방지하면서 승인된 연구를 지원하기 위해 유보된 타겟팅 티어(특정 sink 위치, 인리치먼트 판정, 순위가 매겨진 unprivileged 표면)입니다.