paint-brush
AWS Firecracker VMM의 마이크로아키텍처 보안: 위협 모델~에 의해@autoencoder
190 판독값

AWS Firecracker VMM의 마이크로아키텍처 보안: 위협 모델

너무 오래; 읽다

이 연구 논문에서는 Firecracker가 마이크로아키텍처 공격에 대해 얼마나 안전한지 조사합니다.
featured image - AWS Firecracker VMM의 마이크로아키텍처 보안: 위협 모델
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]}.

링크 표

3. 위협 모델

우리는 Firecracker 기반 서버리스 클라우드 시스템에 적용할 수 있는 두 가지 위협 모델을 제안합니다.


(1) 사용자 간 모델(그림 3): 악의적인 사용자는 Firecracker VM 내에서 샌드박스된 임의 코드를 실행하고 데이터 유출, 데이터 주입을 시도하거나 다른 사용자의 샌드박스된 애플리케이션에 대한 정보나 제어권을 얻으려고 시도합니다. 이 모델에서 우리는 다음을 고려합니다.


(a) 두 사용자의 인스턴스가 CPU 코어에서 차례로 실행되는 하드웨어의 시분할 공유


(b) 두 사용자의 코드가 어떤 방식으로든 공유되는 하드웨어에서 동시에 실행되는 물리적 공동 배치(예: 동일한 CPU의 두 코어 또는 SMT가 활성화된 경우 동일한 코어의 두 스레드).


(2) 사용자-호스트 모델(그림 4): 악의적인 사용자는 호스트 시스템의 일부 구성 요소(Firecracker VMM, KVM 또는 호스트 시스템 커널의 다른 부분)를 표적으로 삼습니다. 이 시나리오에서는 하드웨어 리소스의 시간 분할 공유만 고려합니다. 이는 호스트 커널이나 VMM에서 처리해야 하는 페이지 오류로 인해 게스트 사용자의 VM이 종료되는 경우에만 호스트가 코드를 실행하기 때문입니다.


두 모델 모두 악의적인 사용자가 애플리케이션의 런타임 환경을 제어할 수 있다고 가정합니다. 우리 모델에서는 악의적인 사용자가 게스트 커널 권한을 갖지 않습니다. 따라서 두 모델 모두 게스트 커널이 VMM에 의해 선택 및 구성되지만 런타임 시 손상되는 것으로 가정되는 [1]에서 가정한 모델보다 공격자에게 약간 적은 권한을 부여합니다. 오히려 우리 모델의 공격자의 능력은 AWS Lambda 및 Fargate의 Firecracker 배포에서 사용자에게 부여된 능력과 일치합니다.


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