paint-brush
AWS Firecracker VMM의 마이크로아키텍처 보안: Firecracker의 격리 시스템 분석~에 의해@autoencoder
463 판독값
463 판독값

AWS Firecracker VMM의 마이크로아키텍처 보안: Firecracker의 격리 시스템 분석

너무 오래; 읽다

이 연구 논문에서는 Firecracker가 마이크로아키텍처 공격에 대해 얼마나 안전한지 조사합니다.
featured image - AWS Firecracker VMM의 마이크로아키텍처 보안: Firecracker의 격리 시스템 분석
Auto Encoder: How to Ignore the Signal Noise HackerNoon profile picture
0-item

저자:

(1) Zane Weissman, Worcester Polytechnic Institute Worcester, MA, USA {[email protected]};

(2) Thomas Eisenbarth, 독일 SH, Lübeck Lübeck 대학교 {[email protected]};

(3) Thore Tiemann, 독일 남동부 뤼베크 뤼베크 대학교 {[email protected]};

(4) Berk Sunar, Worcester Polytechnic Institute Worcester, MA, USA {[email protected]}.

링크 표

4. 폭죽 격납 시스템 분석

그림 2는 AWS에서 제시한 대로 Firecracker가 제공하는 격리를 보여줍니다. 이 섹션에서는 묘사된 각 구성 요소와 마이크로아키텍처 공격에 대한 방어 및 취약점을 분석합니다.


그림 3: 사용자 간 위협 모델에서는 악의적인 클라우드 서비스 테넌트가 다른 테넌트에서 정보를 빼내려고 시도한다고 가정합니다. 우리는 공격자가 CSP에서 게스트 커널을 제공하는 동안 VM의 앱과 런타임을 제어할 수 있다고 가정합니다.


그림 4: 사용자-호스트 위협 모델에서 악의적인 테넌트는 호스트 시스템에서 정보를 유출하는 것을 목표로 합니다. g. 가상 머신 관리자 또는 호스트 커널. 공격자는 CSP에서 게스트 커널을 제공하는 동안 가상 머신의 런타임과 앱을 제어할 수 있습니다.


KVM . Linux 커널 기반 가상 머신(KVM)은 최신 Linux 커널에서 구현된 하이퍼바이저이므로 Linux 코드 베이스의 일부입니다. 기본 하드웨어의 감독자 및 사용자 모드를 가상화하고 VM 간의 컨텍스트 전환을 관리하며 I/O 작업과 관련되지 않은 대부분의 VM 종료 이유를 처리합니다. 이러한 아키텍처 격리 메커니즘 외에도 KVM은 VM 종료에 대한 Spectre 공격에 대한 완화 기능을 구현하여 악의적인 게스트로부터 호스트 OS 또는 하이퍼바이저를 보호합니다. Firecracker는 하이퍼바이저로 KVM에 크게 의존합니다. 그러나 KVM은 Linux 소스 코드의 일부이고 Linux 커뮤니티에서 개발되었으므로 KVM은 Firecracker의 일부가 아닌 것으로 정의합니다. 따라서 KVM에 구현된 마이크로아키텍처 공격에 대한 대응책은 Firecracker의 격리 시스템에 있다고 볼 수 없습니다.


메타데이터, 장치 및 I/O 서비스. 메타데이터, 장치 및 I/O 서비스는 VM과 직접 상호 작용하여 메트릭을 수집 및 관리하고 연결을 제공하는 Firecracker VMM 및 API의 일부입니다. AWS는 이러한 인터페이스의 단순성(공격 표면 감소)과 보안 기능으로 유명한 프로그래밍 언어인 Firecracker용으로 처음부터 작성되었다는 점을 자랑합니다[9]. 그러나 Rust는 유효하지 않거나 범위를 벗어난 메모리 액세스에 대해 프로세스 내 보호 기능을 가장 잘 제공하지만 캐시 공격, Spectre 및 MDS와 같은 마이크로아키텍처 공격은 피해자의 프로세스를 직접 하이재킹하는 대신 프로세스 간에 정보를 유출할 수 있습니다.


Firecracker와 다른 많은 VMM의 또 다른 주목할만한 차이점은 이러한 모든 서비스가 비록 다른 스레드이기는 하지만 VM 자체와 동일한 호스트 프로세스 내에서 실행된다는 것입니다. VM 내의 메모리 주소 가상화는 게스트 코드와 I/O 서비스 사이에 일부 난독화를 제공하지만 일부 Spectre 공격은 특히 단일 프로세스 내에서 작동합니다. 그러나 동일한 하드웨어에서 실행되는 두 게스트가 각각 이러한 필수 서비스의 자체 복사본을 갖고 있기 때문에 프로세스 내 공격은 실제 시스템에 대한 위협이 덜할 수 있습니다.


간수 장벽. API 또는 VMM이 손상된 경우 간수는 Firecracker 인스턴스 주변에 마지막 방어 장벽을 제공합니다. 네임스페이스와 제어 그룹(cgroup)을 각각 사용하여 호스트 시스템의 파일과 리소스를 보호합니다[7]. 마이크로아키텍처 공격은 정의상 마이크로아키텍처 상태 외부에 있는 파일을 직접적으로 위협하지 않습니다. Cgroup을 사용하면 시스템 관리자는 프로세스를 그룹에 할당한 다음 그룹별로 시스템 리소스 사용량을 할당, 제한 및 모니터링할 수 있습니다[17]. cgroup에 적용되는 제한이 특정 마이크로아키텍처 공격을 수행하는 공격자의 능력을 방해할 수 있다는 것은 그럴듯합니다. 예를 들어, 메모리 제한으로 인해 제거 기반 캐시 공격을 수행하기 어려울 수 있거나, CPU 시간 제한으로 인해 공격자가 피해자의 속도를 늦출 수 있는 HyperDegrade[2]와 같은 CPU 서비스 거부 도구를 효과적으로 사용하지 못할 수 있습니다. 프로세스를 통해 마이크로아키텍처 측면 채널 추출 또는 주입 타이밍을 단순화합니다. 실제로 Firecracker는 특정 cgroup 규칙과 함께 배포되지 않습니다[7]. 실제로 이는 기본 Linux 리소스 할당 [6] 하에서 많은 Firecracker VM의 효율적인 운영을 위해 특별히 설계되었습니다.


Firecracker의 격리 및 억제 시스템 중 어느 것도 사용자 간 또는 사용자 간 공격으로부터 직접적으로 보호하는 것으로 보이지 않습니다. 따라서 우리는 Firecracker VM 내부 및 외부의 다양한 마이크로 아키텍처 공격 개념 증명 테스트를 진행했습니다.


이 문서는 CC BY-NC-ND 4.0 DEED 라이센스에 따라 arxiv에서 볼 수 있습니다.