AWS Firecracker VMM의 마이크로아키텍처 보안: 마이크로아키텍처 공격 및 방어 분석

링크 표

• 초록 및 소개
• 배경
• 위협 모델
• 폭죽의 격납 시스템 분석
• Firecracker Microvms의 마이크로아키텍처 공격 및 방어 분석
• 결론, 감사의 말, 참고자료

5. 폭죽 마이크로브의 마이크로아키텍처 공격 및 방어 분석

이 섹션에서는 Firecracker microVM에 대한 다수의 마이크로아키텍처적 부채널 및 추측 공격 PoC에 대한 분석을 제시합니다. 우리는 베어메탈 및 Firecracker 인스턴스에서 이러한 PoC를 테스트하고 다양한 시나리오에서 관련 마이크로코드 방어를 테스트합니다. Intel Skylake 4114 CPU가 장착된 서버에서 테스트를 실행합니다.

가상화 하드웨어 확장과 SMT가 활성화되어 있습니다. CPU는 마이크로코드 버전 0x2006b06[2]에서 실행됩니다. 호스트 OS는 Linux 5.10 커널이 포함된 Ubuntu 20.04입니다. 우리는 빠른 시작 가이드[3]에 따라 Amazon에서 제공하는 Linux 커널 5.4가 포함된 Ubuntu 18.04 게스트를 실행하기 위해 2023년 7월 현재 최신 버전인 Firecracker v1.0.0 및 v1.4.0을 사용했습니다.

요약하자면, AWS Firecracker와 함께 제공되는 권장 프로덕션 호스트 설정은 악의적인 이웃으로부터 테넌트를 보호하는 데 충분하지 않습니다. 따라서 Firecracker는 주장된 격리 보장을 제공하지 못합니다. 이 때문입니다

(1) microVM에서 실행될 때만 악용될 수 있는 Medusa 변종을 식별합니다. 또한 권장 대책에는 사이드 채널이나 대부분의 다른 Medusa 변종을 완화하는 데 필요한 단계가 포함되어 있지 않습니다.

(2) 권장 대책 적용 시 Spectre-PHT 또는 Spectre-BTB를 통해 유발되는 정보 유출로부터 임차인이 제대로 보호되지 않음을 보여줍니다. Spectre-PHT 변종은 SMT를 비활성화한 경우에도 문제가 남아 있습니다.

(3) 우리는 Firecracker v1.0.0과 v1.4.0 사이에 PoC 성능에 차이가 없음을 관찰했습니다.

우리는 Firecracker가 제공하는 가상화 계층이 마이크로아키텍처 공격에 거의 영향을 미치지 않으며 Firecracker의 시스템 보안 권장 사항이 충분하지 않다는 결론을 내렸습니다.

5.1 메두사

우리는 테스트 시스템의 베어 메탈과 Firecracker VM에서 Medusa[37] 사이드 채널(Intel에서 MDS[25]의 MLPDS 변형으로 분류함)에 대한 Moghimi의 PoC[35]를 평가했습니다. 섹션 2.4.2에 설명된 세 가지 알려진 변종 각각에 대해 하나의 누출 PoC가 있습니다. 우리는 PoC 라이브러리의 두 가지 피해자 프로그램을 사용했습니다.

• "블록 쓰기" 프로그램은 루프에 많은 양의 연속 데이터를 씁니다(프로세서가 반복된 저장을 식별하고 이를 결합하도록).

• "REP MOV" 프로그램은 유사한 작업을 수행하지만 루프에서 더 작은 데이터 블록을 이동하는 많은 명령어 대신 REP MOV 명령어를 사용합니다.

5.1.1 결과. 표 1은 커널의 모든 마이크로 아키텍처 보호가 비활성화된 상태에서 데이터가 성공적으로 유출된 사례를 보여줍니다. 왼쪽 두 열은 3개의 Medusa PoC와 2개의 포함된 피해자 프로그램의 가능한 조합을 보여줍니다. 오른쪽 열은 베어 메탈에서 작동하는 구성과 병렬 Firecracker 인스턴스에서 실행되는 비밀 및 유출 프로그램을 나타냅니다. 특히 Cache Indexing 변형의 경우 Block Write 비밀은 Firecracker에서만 작동합니다. 이는 가상 머신이 제공하는 메모리 주소 가상화 때문일 수 있습니다. 게스트는 KVM에 의해 매핑된 가상 메모리 영역만 볼 수 있으며 KVM은 메모리 액세스 지침을 트랩하고 게스트를 대신하여 트랜잭션을 처리합니다.

우리는 베어메탈 및 Firecracker VM에서 공격자와 피해자 PoC의 각 조합에 대해 mds 및 nosmt 방어의 효율성을 테스트했습니다. 표 2에는 베어메탈 및 Firecracker 시나리오에서 Medusa 공격을 방지하는 데 필요한 보호 기능이 나열되어 있습니다. Firecracker의 네 가지 취약점 중 하나만 nosmt로 완화되며 AWS는 mds 보호 활성화를 명시적으로 권장하지 않습니다. 그러나 대부분의 Linux 배포판은 기본적으로 활성화된 상태로 제공됩니다. 즉, 다중 테넌트 클라우드 플랫폼은 AWS가 권장하는 보안 조치를 준수하는 방식으로 Firecracker를 사용할 수 있지만 Firecracker VMM 자체가 사용자 데이터를 유출하는 경우를 포함하여 대부분의 Medusa 변종에 여전히 취약할 수 있습니다. 그렇지 않으면 유출되지 않습니다.

5.2 RIDL 및 기타

이 섹션에서는 van Schaik et al.의 2019년 논문[50]과 함께 제공된 RIDL PoC 프로그램[51]에 대한 평가를 제시합니다. RIDL은 캐시나 메모리가 아닌 CPU 내부 버퍼의 추측성 로드를 이용하는 MDS 공격 클래스입니다. RIDL PoC 저장소에는 Fallout MDS 공격의 한 변종뿐만 아니라 백서의 이후 부록에서 발표된 공격의 예도 포함되어 있습니다.

5.2.1 결과. 표 3은 우리가 테스트한 RIDL PoC에 대한 몇 가지 기본 정보와 공격 방지 관련 대응책의 효율성을 보여줍니다. 우리는 Firecracker microVM 시스템의 하드웨어 보안이 강화되었다는 Amazon의 주장을 평가하기 위해 베어 메탈과 Firecracker에 대한 공격을 비교했습니다. Firecracker 시스템에 대한 테스트에서는 호스트 시스템(H)과 Firecracker 게스트 커널(VM)에서 활성화된 대응 플래그를 구분합니다. nosmt 및 mds 커널 플래그 외에도 kaslr, pti 및 l1tf를 포함한 다른 관련 플래그(섹션 2.4.4, [21] 참조)를 테스트했지만 해당 플래그가 이러한 프로그램에 영향을 미치는 것을 발견하지 못했습니다. 우리가 테스트한 CPU에는 tsx_async_abort 커널 플래그를 중복되게 만드는 mds 완화가 포함되어 있으므로 tsx_async_abort 완화를 제외했습니다[20].

일반적으로 우리는 mds 보호가 대부분의 RIDL 공격으로부터 적절하게 보호하지 못한다는 것을 발견했습니다. 그러나 SMT를 비활성화하면 이러한 공격의 대부분이 완화됩니다. 이는 하이퍼스레드에 대한 MDS 공격을 방지하기 위해 SMT를 비활성화해야 한다는 Intel의 [25] 및 Linux 개발자의 [21] 진술과 일치합니다. 이러한 PoC 중 두 가지 이상치는 호스트에서 nosmt와 mds를 모두 요구하는 alignment_write와 mds 대책으로만 완화되는 pgtable_leak_notsx입니다. alignment_write에 의존하는 누수는 추측을 유발하기 위해 페이지 테이블 오류 누수가 아닌 정렬 오류를 사용합니다[50]. RIDL 문서[50]와 관련 VRS 익스플로잇에 대한 Intel의 문서[26]에서는 이 공격이 다른 PoC에서 발견된 페이지 오류 기반 MFBDS 공격과 정확히 무엇이 다른지 명확하지 않지만, 실험 결과에 따르면 누출의 마이크로아키텍처 메커니즘은 다음과 같습니다. 별개의. pgtable_leak_notsx의 동작에 대한 간단하고 합리적인 설명이 있는데, 이는 한 가지 주요 이유 때문에 이러한 PoC 중에서 고유합니다. 이는 단일 스레드 내에서 보안 경계를 넘는(커널에서 페이지 테이블 값 누출) 유일한 익스플로잇입니다. 또 다른 스레드. 멀티스레딩을 비활성화해도 이 단일 스레드 공격에 거의 영향을 미치지 않는다는 것은 자명합니다. 그러나 mds 대책은 동일한 스레드 내에서 커널 권한 실행에서 사용자 권한 실행으로 전환하기 전에 마이크로아키텍처 버퍼를 플러시하여 공격하는 사용자 코드가 유출되기 전에 LFB에서 커널 코드로 액세스한 페이지 테이블 데이터를 지웁니다.

Medusa와 달리 이러한 PoC의 대부분은 smt 비활성화에 대한 AWS의 권장 사항에 의해 완화됩니다. 그러나 Medusa와 마찬가지로 Firecracker VMM 자체는 이러한 공격에 대한 마이크로아키텍처 보호 기능을 제공하지 않습니다.

5.3 스펙터

다음으로 Spectre 취약점에 중점을 둡니다. Spectre 공격이 처음 발견된 이후 많은 대응책이 개발되었지만 그 중 다수는 (상당한) 성능 저하를 가져오거나 공격을 부분적으로만 완화했습니다. 그러므로,

시스템 운영자는 종종 성능과 보안의 균형을 결정해야 합니다. 이 섹션에서는 앞에서 설명한 두 위협 모델 모두에서 Firecracker 테넌트가 사용할 수 있는 Spectre 공격 표면을 평가합니다. 광범위한 Spectre 공격을 평가하기 위해 [15]에 제공된 PoC를 사용합니다. Spectre-PHT, Spectre-BTB 및 SpectreRSB의 경우 저장소에는 각각 4개의 PoC가 포함되어 있습니다. 공격자가 BPU를 잘못 훈련시키는 방식이 다릅니다. 네 가지 가능성은 다음과 같습니다. (1) 동일 프로세스 - 공격자가 피해자 프로세스 또는 BPU를 잘못 훈련하기 위한 입력을 제어합니다. (2) 교차 프로세스 - 공격자가 분기 예측에 영향을 주기 위해 별도의 프로세스에서 자체 코드를 실행합니다. 피해자 프로세스 - (a) 내부 - 공격자는 공격자가 피해자 프로세스에서 잘못 예측하기를 원하는 대상 분기와 동일한 가상 주소에 있는 분기 명령으로 BPU를 잘못 훈련시킵니다. (b) 외부 장소 - 공격자는 피해자 프로세스의 대상 분기와 일치하는 주소에 있는 분기 명령으로 BPU를 잘못 훈련시킵니다.

(1) 동일 프로세스: 공격자는 피해자 프로세스 또는 그 입력을 제어하여 BPU를 잘못 훈련시킵니다.

(2) 크로스 프로세스: 공격자는 피해자 프로세스의 분기 예측에 영향을 미치기 위해 별도의 프로세스에서 자체 코드를 실행합니다.

(3) 내부(in-place): 공격자는 공격자가 피해자 프로세스에서 잘못 예측하기를 원하는 대상 분기와 동일한 가상 주소에 있는 분기 명령으로 BPU를 잘못 훈련시킵니다.

(4) Out-of-place: 공격자는 피해자 프로세스의 대상 분기와 일치하는 주소에 있는 분기 명령으로 BPU를 잘못 훈련시킵니다.

처음 두 상황과 후반 두 상황은 직교하므로 각 PoC는 두 가지 상황을 결합합니다. Spectre-STL의 경우 동일한 프로세스 변형만 알려져 있으므로 이 경우 저장소는 두 개의 PoC만 제공합니다. VM 간 실험의 경우 잘못된 학습에 사용되는 합동 주소를 쉽게 찾을 수 있도록 호스트 및 게스트 커널은 물론 호스트 및 게스트 사용자 수준에 대한 주소 공간 레이아웃 무작위화를 비활성화했습니다.

5.3.1 결과. 호스트 시스템과 Firecracker VM 내부에서 AWS 권장 대책[8](사용 중인 Linux 커널의 기본값, 그림 5 참조)을 사용하면 Spectre-RSB가 호스트와 VM 내부 및 VM 전체에서 성공적으로 완화되는 것을 볼 수 있습니다. (표 4 참조). 반면 Spectre-STL, Spectre-BTB, Spectre-PHT는 특정 상황에서 정보 유출을 허용했습니다.

Spectre-STL에 대한 PoC는 누출을 보여줍니다. 그러나 유출은 동일한 프로세스 및 동일한 권한 수준 내에서만 발생합니다. 크로스 프로세스 변형이 알려져 있지 않기 때문에 Spectre-STL에 대한 크로스VM 시나리오를 테스트하지 않았습니다. 사용자 간 위협 모델에서 Spectre-STL은 프로세스 간 변형이 알려져 있지 않기 때문에 가능한 공격 벡터가 아닙니다. 두 테넌트 워크로드가 동일한 VM 내에서 프로세스 내 격리를 통해 격리되는 경우 Spectre-STL은 여전히 실행 가능한 공격 벡터가 될 수 있습니다. 사용자-호스트 모델에서 Spectre-STL은 현재 Linux 커널에 포함되고 기본적으로 활성화되는 대책을 통해 완화됩니다.

Spectre-PHT의 경우 커널 대책에는 사용자 포인터 삭제 및 권한 수준 스위치에 대한 장벽(lfence) 활용이 포함됩니다. 따라서 우리는 SpectrePHT가 호스트 시스템에 거의 또는 전혀 위협을 가하지 않는다는 결론을 내렸습니다. 그러나 이러한

완화는 동일한 물리적 코어에서 병렬로 실행되는 두 하이퍼스레드를 서로 보호하지 않습니다. 이것이 바로 4개의 Spectre-PHT 잘못된 학습 변종이 모두 호스트 시스템과 Firecracker VM 내부에서 완벽하게 작동하는 이유입니다. 표 4에서 볼 수 있듯이 이는 SMT가 비활성화된 경우에도 마찬가지입니다[4]. 실제로 두 VM을 동일한 물리적 스레드에 고정하면 Spectre-PHT의 크로스 프로세스 외부 버전이 활성화되는 반면, SMT 사례에서는 누출이 관찰되지 않았습니다. 이로 인해 Spectre-PHT는 사용자 간 심각한 위협이 됩니다.

Spectre-BTB PoC는 AWS 권장 대책이 활성화된 경우 부분적으로 작동합니다. 동일한 프로세스와 동일한 주소에서 BTB를 잘못 트레이닝하는 원래 변형은 완벽하게 작동하는 반면, 동일한 프로세스에서 잘못된 잘못된 트레이닝은 수행됩니다.

성공적으로 완화되었습니다. 또한 잘못된 잘못된 교육을 통해 프로세스 경계를 넘어 정보를 유출하려는 모든 시도에서는 누출이 나타나지 않았습니다. 그러나 프로세스 간 내부 잘못된 트레이닝으로 인해 누출이 관찰되었습니다. 호스트 시스템에서는 SMT와 별개로 누출이 발생했습니다. VM 내부에서는 모든 가상 CPU 코어가 별도의 물리적 스레드에 할당된 경우에만 누출이 발생했습니다. VM 전체에서 SMT를 비활성화하면 누출이 제거되었습니다.

그림 5에 나열된 대책 외에도 호스트 커널에는 VM 진입점과 종료점[5]에 컴파일된 Spectre 대책이 있어 커널이 VM 종료를 처리하는 동안 악의적인 게스트가 호스트 커널을 공격하는 것을 완전히 비활성화합니다.

요약하자면, AWS Firecracker에서 권장하는 Linux 기본 대책은 Spectre를 부분적으로만 완화한다고 말할 수 있습니다. 정확하게는 다음을 보여줍니다.

• Spectre-PHT 및 Spectre-BTB는 SMT 비활성화를 포함한 AWS 권장 대책을 사용하여 게스트 간 시나리오에서 테넌트 간에 정보를 계속 유출할 수 있습니다.

• 호스트 커널은 VM 항목 및 종료를 보호하기 위해 Linux 커널에 컴파일된 추가 예방 조치를 통해 충분히 보호될 가능성이 높습니다. 그러나 이는 Firecracker가 제공하는 보안 조치와 직교합니다.

관찰된 모든 누출은 사용 중인 Firecracker 버전과 무관했습니다.

5.3.2 평가. Firecracker는 Spectre에 대한 완화 기능을 추가하지 않고 호스트 및 게스트 커널에서 제공하는 완화 기능과 선택적 마이크로코드 업데이트를 포함하는 일반 보호 권장 사항에만 의존하는 것으로 나타났습니다 . 더 나쁜 것은 권장 대책으로는 서버리스 애플리케이션이 다른 테넌트에게 정보를 유출하는 것을 충분히 보호하지 못한다는 것입니다. 따라서 우리는 마이크로아키텍처 공격이 Firecracker 위협 모델의 범위 내로 간주됨에도 불구하고 Firecracker가 마이크로아키텍처 수준에서 격리 목표를 달성하지 못한다고 주장합니다.

예민한 독자라면 Spectre-BTB가 STIBP 대책(그림 5 참조)에서 여전히 문제로 남아 있는 이유가 궁금할 것입니다. 이 마이크로코드 패치는 분기 예측이 다른 스레드에서 발생하는 예측 정보를 사용하지 못하도록 설계되었기 때문입니다. 이는 또한 최근 Google이 IBRS가 활성화될 때 STIBP 완화를 계속 비활성화하는 Linux 6.2의 결함을 식별하는 보안 권고[6]를 발표할 때까지 한동안 우리를 당황하게 했습니다. 문제의 원인으로 식별된 코드 섹션이 Linux 5.10 소스 코드에도 존재하는 것을 확인했습니다. 따라서 우리는 Google이 식별한 동일한 문제가 우리 시스템에서도 발생한다고 가정합니다.

[2] 마이크로코드를 최신 버전으로 업데이트하면 시스템에서 TSX가 비활성화되어 TSX 기반 MDS 변형을 사용한 테스트가 불가능해집니다.

[3] https://github.com/firecracker-microvm/firecracker/blob/ dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] 이는 공격자와 피해자 프로세스를 동일한 코어((1PT))에 고정하여 시뮬레이션됩니다.

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx