AWS Firecracker VMM의 마이크로아키텍처 보안: 개요 및 소개

링크 표

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

추상적인

Firecracker는 서버리스 클라우드 플랫폼을 위해 Amazon Web Services(AWS)에서 특별히 제작한 가상 머신 관리자(VMM)입니다. 즉, 작업별로 최종 사용자를 위한 코드를 실행하고 서버 인프라를 자동으로 관리하는 서비스입니다. Firecracker는 빠르고 가벼운 VM을 제공하며 일반적으로 작은 작업을 격리하는 데 사용되는 컨테이너의 속도와 성능을 희생하면서 더 큰 격리를 제공하는 경향이 있는 VM의 보안 조합을 약속합니다. AWS는 이러한 보안과 효율성의 조합을 통해 호스트 시스템이 활성 작업 간을 빠르고 자주 전환함으로써 동일한 하드웨어에서 서로 다른 사용자가 수천 개의 사용자 작업을 실행하는 것이 가능할 뿐만 아니라 안전하다고 주장합니다. AWS에서는 위협 모델에 마이크로아키텍처 공격이 포함되어 있다고 명시하고 있지만, 서버리스 컴퓨팅의 확장성이 전례 없는 수의 사용자 간의 하드웨어 공유에 달려 있는 것처럼 이러한 종류의 공격은 공유 하드웨어에 직접적으로 의존합니다.

이 작업에서는 Firecracker가 마이크로아키텍처 공격에 대해 얼마나 안전한지 조사합니다. 먼저, Firecracker가 명시한 격리 모델과 권장 배포 모범 사례를 검토하고, 서버리스 플랫폼에 대한 잠재적인 위협 모델을 식별하고, 잠재적인 약점을 분석합니다. 그런 다음 마이크로아키텍처 공격 개념 증명을 사용하여 Firecracker가 제공하는 격리를 테스트하고 Spectre 또는 MDS 공격에 대한 보호 기능이 거의 없음을 확인했습니다. 특히 우려되는 두 가지 사례를 발견했습니다. 1) Firecracker VM을 위협하지만 VM 외부에서 실행되는 프로세스는 위협하지 않고 AWS에서 권장하는 방어 수단으로 완화되지 않는 Medusa 변종, 2) 권장 대책이 적용되더라도 계속 악용 가능한 Spectre-PHT 변종 장소와 SMT는 시스템에서 비활성화됩니다. 요약하면, AWS는 Firecracker VMM에 내재된 보안을 과장하고 Firecracker를 사용하는 클라우드 시스템을 적절하게 보호하기 위한 불완전한 지침을 제공한다는 것을 보여줍니다.

CCS 개념

• 보안 및 개인 정보 보호 → 가상화 및 보안; 사이드채널 분석 및 대응방안.

키워드

시스템 보안, 마이크로아키텍처 보안, 가상 머신, 하이퍼바이저, 서버리스, 클라우드 시스템

1. 소개

서버리스 컴퓨팅은 클라우드 서비스 공급자(CSP)가 고객에게 런타임 환경을 제공하는 클라우드 컴퓨팅의 새로운 추세입니다. 이렇게 하면 고객은 하드웨어, 운영 체제(OS), 때로는 런타임과 관련된 관리 작업을 CSP에 맡기면서 기능 코드를 유지하는 데 집중할 수 있습니다. 일반적인 서버리스 플랫폼 모델에는 FaaS(Function-as-a-Service)와 CaaS(Container-as-a-Service)가 포함됩니다. 개별 기능은 일반적으로 작지만 고객의 애플리케이션은 각각 하나에서 수천 개의 기능까지 어디에서나 실행될 수 있으므로 CSP는 유휴 시간을 최소화하고 결과적으로 이익을 극대화하기 위해 단일 서버에 최대한 많은 기능을 탑재하는 것을 목표로 합니다. 런타임 환경을 제공하기 위한 다소 가벼운 접근 방식은 컨테이너를 실행하는 것입니다. 컨테이너는 각 프로세스에 필요한 파일만 공유 커널의 가상 파일 시스템 상단에 로드되도록 종속성과 함께 프로세스를 캡슐화합니다. 이렇게 하면 컨테이너 간 전환이 프로세스 간 컨텍스트 전환보다 조금 더 줄어듭니다. 반면, 전체 가상화는 가상 머신(VM) 간의 우수한 격리를 제공하여 테넌트 간 보안을 제공하는 동시에 각 VM이 자체 커널과 함께 제공되므로 다소 무거워집니다.

이러한 접근 방식(컨테이너 또는 VM) 중 어느 것도 서버리스 환경에서 사용하기에 적합하지 않습니다. 이상적으로는 많은 사용자가 소유한 많은 단기 기능이 동시에 실행되고 자주 전환되므로 이 사용 사례를 위해 새로운 격리 메커니즘이 개발되었습니다. 예를 들어, 프로세스 내 격리를 위한 메커니즘[38, 45, 49]은 런타임과 기본 커널의 공격 표면을 줄여 컨테이너의 보안을 향상시키기 위해 시작되었습니다. 커널을 보호하는 것은 중요합니다. 손상된 커널은 컨테이너 케이스에서 완전히 손상된 시스템으로 직접 이어지기 때문입니다. 그러나 syscall 제한과 같은 특정 강력한 보호 기능은 컨테이너에서 사용할 수 있는 기능을 제한하고 일부 애플리케이션과의 호환성을 깨뜨릴 수도 있습니다. VM 연구에서 개발자는 더욱 작고 효율적인 VM을 만들어 결국 소위 microVM으로 이어졌습니다. MicroVM은 일반 가상 머신과 동일한 격리 보장을 제공하지만 장치 또는 OS 지원과 관련하여 기능이 매우 제한되어 있어 일반 VM에 비해 가벼우므로 서버리스 컴퓨팅에 더 적합합니다.

Firecracker[1]는 일반적인 컨테이너 시스템과 비슷한 메모리 오버헤드와 시작 시간을 제공하면서 microVM을 실행하도록 설계된 가상 머신 관리자(VMM)입니다. Firecracker는 Amazon Web Services(AWS)에서 적극적으로 개발되었으며 2018년부터 AWS Lambda[5] 및 AWS Fargate[4] 서버리스 컴퓨팅 서비스의 프로덕션에 사용되었습니다[1]. AWS의 설계 문서[1]에서는 Firecracker의 기능, 기존 가상 머신과의 차이점, 그리고 Firecracker가 제공하는 의도된 격리 모델에 대해 설명합니다. 동일한 하드웨어에서 실행되는 여러 기능에 대한 안전성, 권한 상승으로부터 보호, 정보 공개, 비밀 채널 및 기타 위험” [1]. 또한 AWS는 Firecracker VM이 상호 작용하는 CPU 및 커널 부분을 보호하기 위한 프로덕션 호스트 설정 권장 사항[8]을 제공합니다. 이 문서에서는 Firecracker가 microVM 전체의 은밀한 측면 채널로부터 기능을 보호한다는 주장에 이의를 제기합니다. 우리는 Firecracker 자체가 마이크로아키텍처 공격 대응책을 추가하지 않고 호스트 및 게스트 Linux 커널과 CPU 펌웨어/마이크로코드 업데이트에 전적으로 의존한다는 것을 보여줍니다.

다양한 Spectre[10, 13, 22, 30, 31, 33, 52] 및 마이크로아키텍처 데이터 샘플링(MDS) [14, 37, 46, 50] 변종과 같은 마이크로아키텍처 공격은 종종 멀티 테넌트 시스템에 위협이 됩니다. VM의 경계를 포함하여 소프트웨어 및 아키텍처 격리 경계를 모두 우회할 수 있습니다. Spectre와 MDS는 BPU(분기 예측 장치) 또는 LFB(라인 필 버퍼)와 같은 CPU 코어 리소스를 공유하는 테넌트를 위협합니다. 보다 전통적인 서비스를 제공하는 CSP는 수명이 긴 VM 테넌트를 별도의 CPU 코어에 고정하여 공유 하드웨어 리소스 문제를 완화할 수 있습니다. 이는 테넌트 간에 리소스를 효과적으로 분할하고 마이크로아키텍처 상태가 한 번에 단일 테넌트에 의해서만 영향을 받도록 보장합니다. .

그러나 서버리스 환경에서는 마이크로아키텍처 공격의 위협이 더 큽니다. 그 이유는 다양한 테넌트가 실행하는 기능의 수명이 짧기 때문입니다. 서버리스 환경의 서버 리소스는 과도하게 커밋될 것으로 예상되며, 이로 인해 동일한 하드웨어에서 컴퓨팅 리소스를 놓고 테넌트 기능이 경쟁하게 됩니다. 두 형제 스레드의 CPU 리소스 동시 사용을 비활성화하는 동시 멀티스레딩(SMT)을 비활성화하면 CPU의 컴퓨팅 성능이 최대 30% 감소합니다[34]. 고객이 특정 CPU 코어를 임대하는 경우 이러한 성능 저하가 허용될 수 있거나 CPU 코어의 두 스레드가 함께 임대될 수 있습니다. 그러나 서버리스 서비스의 경우 성능 저하로 인해 특정 시간 내에 서비스를 제공할 수 있는 고객 수가 30% 감소합니다. 이것이 바로 대부분의 서버리스 CSP가 별도로 명시하지 않는 한 시스템에서 SMT를 활성화된 상태로 유지한다고 가정해야 하는 이유입니다. SMT가 활성화되고 악성 스레드가 공유 코어에 동시에 액세스할 수 있는 경우 마이크로아키텍처 공격 표면이 가장 커집니다. 그러나 공격자 스레드가 CPU 코어를 피해자 스레드에 양보하기 전에 마이크로아키텍처를 준비하거나 피해자 스레드가 실행을 일시 중지한 직후에 실행하는 경우에도 동일한 성능을 발휘하는 공격 변형도 있습니다. 그리고 CSP에 의해 SMT가 비활성화된 경우에도(AWS Lambda의 경우처럼) 테넌트는 여전히 이러한 시간 분할 방식으로 다른 여러 사람과 CPU를 공유합니다.

AWS는 최신 마이크로아키텍처 방어 기능을 갖춘 시스템에서 실행되는 Firecracker가 마이크로아키텍처 공격에 대해 충분한 보안을 제공할 것이라고 주장합니다[1]. Firecracker 문서에는 활성화해야 하는 마이크로아키텍처 보안 조치에 대한 특정 권장 사항도 포함되어 있습니다. 이 작업에서 우리는 Firecracker의 보안 주장과 권장 사항을 조사하고 지침에 대한 감독은 물론 완전히 완화되지 않은 위협을 밝힙니다.

요약하자면, 우리의 주요 기여는 다음과 같습니다:

• Firecracker VM을 기반으로 하는 경우 서버리스 컴퓨팅의 교차 테넌트 및 테넌트-하이퍼바이저 격리에 대한 포괄적인 보안 분석을 제공합니다.

• 마이크로코드 업데이트와 Linux 커널을 통해 제공되는 보호 기능을 사용하여 마이크로아키텍처 공격 개념 증명(PoC)에 대한 Firecracker의 방어 기능을 테스트합니다. 우리는 가상 머신 자체가 주요 유형의 마이크로아키텍처 공격에 대해 미미한 보호 기능을 제공한다는 것을 보여줍니다.

• 우리는 호스트에 존재하지 않더라도 Firecracker VM 내에서 악용될 수 있는 Medusa MDS 공격의 변종을 식별합니다. 이 악용 및 가장 잘 알려진 Medusa 변종으로부터 보호하는 커널 완화는 AWS의 Firecracker 호스트 설정 권장 사항에 언급되어 있지 않습니다. 또한 SMT를 비활성화하면 커널 완화의 필요성을 촉구하는 식별된 Medusa 변종에 대한 보호가 충분하지 않음을 보여줍니다.

• 권장 대책을 마련했음에도 불구하고 데이터를 유출하는 Spectre-PHT 및 Spectre-BTB 변종을 식별합니다. Spectre-PHT 변종은 공격자와 피해자가 시간 분할 방식으로 CPU 코어를 공유하는 경우 SMT가 비활성화된 경우에도 문제가 남아 있습니다.

1.1 책임 있는 공개

우리는 조사 결과를 AWS 보안 팀에 알리고 기술 세부 사항에 대해 논의했습니다. AWS 보안 팀은 추가 보안 측정으로 인해 AWS 서비스가 우리의 조사 결과에 영향을 받지 않는다고 주장합니다. AWS는 Firecracker가 자체적으로 마이크로 아키텍처 보안을 제공하지 않고 마이크로코드 업데이트와 보안 호스트 및 게스트 운영 체제와의 결합을 통해서만 제공한다는 데 동의했으며 Firecracker 설치를 위한 호스트 설정 권장 사항을 업데이트할 계획입니다.