기술 요약: AI 코드 샌드박스: 비교 보안 연구 (파트 1)

문제 정의

본 논문은 AI 에이전트가 신뢰할 수 없는 코드를 실행할 때 발생하는 **엔진 레벨 격리(engine-level isolation)**의 임계적 과제를 다룬다. "샌드박싱"은 에이전트형 AI 보안 문헌에서 표준적인 방어 체계이지만, 서로 다른 제품들이 호스트 커널로부터 게스트 코드를 어떻게 격리하는지에 대한 심층적인 엔진 레벨의 측정 비교는 부족한 실정이다. 이 연구의 시급성은 AI 에이전트가 이미 현재의 컴퓨팅 예산 내에서 다단계 사이버 공격(예: 32개의 기업 네트워크 공격 단계 중 22개 완료)을 수행할 수 있다는 "위험한 능력(dangerous capability)" 연구에 의해 뒷받침된다. 본 연구는 T0.H2.N2 위협 모델: 즉, 단일 테넌트 운영자가 자신의 인프라에서 신뢰할 수 없는 코드를 실행하며, 운영자는 인프라는 신뢰하지만 코드는 신뢰하지 않는 상황에 초점을 맞춘다. 목표는 다섯 가지 특정 AI 샌드박스 제품(arrakis, e2b, microsandbox, gvisor, daytona)이 호스트 커널 탈출(host kernel escape) 및 정보 유출을 어떻게 방지하는지 측정하는 것이다.

방법론

본 연구는 엔진(microVM, 사용자 공간 커널, 또는 OCI 컨테이너)에 의해 결정되는 속성을 측정하는 6축 교차 클래스 비교 프레임워크를 채택한다. 방법론은 종합 점수 산출이나 전체 순위 매기기를 명시적으로 금지하며, 대신 축별 순위와 위협 모델 자격 행렬(qualification matrix)을 제공한다.

6가지 축:

1. 호스트 공격 표면 (1.1): strace 시스템 콜(syscall) 수, seccomp 필터 상한선, 그리고 원시 도달 가능성(14개의 특정 커널-LPE/컨테이너 탈출 프리미티브)을 통해 런타임/중재자(L2)가 호스트 커널(L1)에 미치는 발자국을 측정한다.
2. 정보 유출 (1.2): /proc, /sys, /dev 읽기를 통해 호스트 식별 데이터(CPU, RAM, 커널 버전, 디스크 시리얼 등)가 게스트에 얼마나 노출되는지 측정한다.
3. 방어 심층 구조 적층성 (1.3): 운영자가 엔진 기본값 위에 추가적인 리눅스 하드닝(seccomp, AppArmor, 사용자 네임스페이스 등)을 계층화할 수 있는지 평가한다.
4. 공개 CVE 이력 (1.4): 각 엔진의 지난 24개월간의 CVE를 분석하고, 이를 영향도(탈출, 호스트 유출, 호스트 DoS)에 따라 분류한다.
5. 패치 속도 (1.5): 업스트림 패치와 제품 레벨 가용성 사이의 시간 격차를 측정하며, 조율된 공개(coordinated disclosures) 모델과 "선(先) 침묵 수정(silent-fix-first)" 모델을 구분한다.
6. 업스트림 퍼징 태세 (1.6): 지속적인 공개 퍼징, 인트리(in-tree) 하네스, 그리고 CVE당 퍼저 발견 기여도를 평가한다.

실험 설정:

• 호스트: 단일 Hetzner 베어 메탈 노드 (Ubuntu 24.04, Kernel 6.8.0).
• 제품: 세 가지 엔진 클래스에 매핑된 다섯 가지 제품:
  • MicroVMs: arrakis (Cloud Hypervisor), e2b (Firecracker), microsandbox (libkrun).
  • 사용자 공간 커널: gvisor (runsc).
  • OCI 컨테이너: daytona (runc via Docker-CE).
• 검증: "프로브(probe)" 테스트(합격/불합격), "측정"(시스템 콜 수), "데스크 리서치"(CVE/퍼징 분석)를 사용한다.

주요 기여 및 결과

1. 엔진 클래스 대 제품 편차

엔진 클래스(microVM 대 사용자 공간 커널 대 컨테이너)는 구조적 축(공격 표면, 유출)에서는 명확히 구분되지만, 동일한 클래스 내의 제품 간에는 차이가 존재한다. 제품 레벨의 설정과 고정 정책(pin policies)이 엔진 클래스 자체보다 더 중요한 차별화 요소인 경우가 많다.

• 예시: arrakis(microVM)는 "고정된(frozen)" 패치 정책(471일 이상)을 가진 반면, daytona(컨테이너)는 패치에 대해 "최신(current)" 상태를 유지하여, 격리 클래스만으로 예상되는 보안 계층 구조를 역전시킨다.

2. 공격 표면 및 프리미티브 도달 가능성

• g-visor는 시스템 콜을 가로채는 사용자 공간 커널 덕분에 가장 좁은 공격 표면(14개 프리미티브 중 5개 도달 가능)을 가진다.
• **Firecracker (e2b)**는 가장 타이트한 seccom 상한선(55개 시스템 콜)을 보유하고 있지만, 여전히 2026년 윈도우 내에 2개의 새로운 탈출(Escape) 클래스 CVE가 발생하여, 작은 표면이 실행 경로에서의 제로 버그를 보장하지 못함을 입증했다.
• arrakis는 게스트에 라이브 /dev/kvm 인터페이스를 노출하여, 권한 상승 없이도 중첩 가상화를 허용함으로써 다른 microVM에 비해 커널-LPE 표면을 크게 확장시킨다.

3. 패치 전파의 지배력

본 연구는 **제품 측의 고정 정책(pin policy)**이 운영자에게 영향을 미치는 지배적인 변수임을 밝혀냈다. 이는 업스트림의 조율된 공개에 대해 약 0일의 지연을 보이는 반면, 다운스트림에서는 0일에서 471일 이상까지 벌어진다.

• arrakis와 **e2b (자체 호스팅)**는 오래된 엔진 버전에 "고정"되어 있어, 최근의 치명적인 CVE(예: arrakis의 CVE-2026-45782, e2b의 CVE-2026-5747)에 대해 패치되지 않은 상태이다.
• gvisor는 수정 사항이 CVE 할당 전에 몇 달 앞서 배포되는 "선(先) 침묵 수정" 모델을 따르며, 결과적으로 음(-)의 지연 시간을 기록한다(운영자가 공개 전에 수정을 받는 형태).

4. 퍼징 태세 및 "측정되지 않은" 위험

• gvisor는 지속적인 공개 퍼저(syzkaller)와 인트리 하네스를 갖춘 유일한 엔진이다.
• Firecracker와 libkrun은 업스트림 퍼징 인프라가 없다.
• 핵심 발견: "MicroVM 클래스(강력한 격리)"와 "지속적 공개 퍼저(강력한 잔류 버그 탐지)"의 결 조합은 이 집합에서 비어 있는 영역이다.
• **libkrun (microsandbox)**은 구조적으로 측정되지 않은(unmeasured) 상태이다: 발표된 CVE가 0개이며 업스트림 퍼저도 없다. 본 논문은 여기서의 "0개 CVE"가 건전성의 증거가 아니라 신호의 부재임을 주장하며, 이를 "구조적으로 측정되지 않은" 위험 프로필로 규정한다.

5. 정보 유출

• MicroVMs는 일반적으로 0~1개의 호스트 식별자(설정 가능한 CPU 문자열)를 유출한다.
• gvisor는 합성된 /proc 구현의 격차로 인해 2개의 식별자(RAM 총량, BIOS 제품)를 유출한다.
• daytona는 공유 커널 아키텍처로 인해 디스크 시리얼 및 전체 커널 시그니처를 포함하여 10개의 식별자를 유출한다.

의의 및 주장

본 논문은 전체적인 순위 매기기는 불가능하며 제안하지도 않는다고 주장한다. 대신, 운영자가 다음 네 가지 구체적인 하위 질문에 답할 수 있도록 하는 위협 모델 자격 행렬을 제공한다:

1. 탈출 저항성: 코드가 호스트 커널을 탈출할 수 있는가?
2. 정찰 저항성: 코드가 호스트에 대해 무엇을 알아낼 수 있는가?
3. 하드닝 호환성: 운영자가 리눅스 하드닝 계층을 추가할 수 있는가?
4. 패치 전파: 운영자가 수정을 신속하게 받을 수 있는 있는가?

주요 결론:

• 트레이드오프는 피할 수 없다: 가장 강력한 격리 클래스(microVM)가 반드시 가장 강력한 잔류 버그 대응 태세(퍼징)와 상관관계가 있는 것은 아니다. 운영자는 "가장 강력한 격리"(microVM)와 "가장 얕은 잔류 버그"(gVisor) 사이에서 선택해야 한다.
• 제품 기본값이 중요하다: 엔진 레벨의 강점(예: Cloud Hypervisor의 스레드별 seccom)은 제품 레벨의 기본값(예: arrakis의 중첩 KVM 노출 또는 e2b의 고정된 핀)에 의해 무효화될 수 있다.
• "측정되지 않은" 간극: libkrun의 CVE 부재와 퍼징 부재는 이를 "안전"하거나 "위험"하다고 추론할 수 없는, 오직 "측정되지 않음"의 위험 프로필을 생성한다.
• 방법론적 전환: 본 연구는 단순한 CVE "재현"을 넘어, 아키텍처 특성, 패치 속도, 퍼징 투자를 메타 분석함으로써 AI 샌드박스 보안의 현재 상태를 기술한다.

본 논문은 엔진 레벨의 측정에 대한 기준점을 제공하며, 운영자의 즉각적인 주의나 업스트림의 개선이 필요한 특정 제품 레벨의 구성 격차(예: arrakis의 중첩 KVM 및 daytona의 Privileged: true 하드코딩)를 식별한다.