paint-brush
Bảo mật vi kiến trúc của AWS Firecracker VMM: Mô hình mối đe dọatừ tác giả@autoencoder
190 lượt đọc

Bảo mật vi kiến trúc của AWS Firecracker VMM: Mô hình mối đe dọa

dài quá đọc không nổi

Bài nghiên cứu này điều tra mức độ an toàn của Firecracker trước các cuộc tấn công vi kiến trúc.
featured image - Bảo mật vi kiến trúc của AWS Firecracker VMM: Mô hình mối đe dọa
Auto Encoder: How to Ignore the Signal Noise HackerNoon profile picture
0-item

tác giả:

(1) Zane Weissman, Học viện Bách khoa Worcester Worcester, MA, Hoa Kỳ {[email protected]};

(2) Thomas Eisenbarth, Đại học Lübeck Lübeck, SH, Đức {[email protected]};

(3) Thore Tiemann, Đại học Lübeck Lübeck, SH, Đức {[email protected]};

(4) Berk Sunar, Học viện Bách khoa Worcester Worcester, MA, Hoa Kỳ {[email protected]}.

Bảng liên kết

3. MÔ HÌNH Đe dọa

Chúng tôi đề xuất hai mô hình mối đe dọa có thể áp dụng cho hệ thống đám mây không có máy chủ dựa trên Firecracker:


(1) Mô hình người dùng với người dùng (Hình 3): người dùng độc hại chạy mã tùy ý được đóng hộp cát trong máy ảo Firecracker và cố gắng rò rỉ dữ liệu, tiêm dữ liệu hoặc lấy thông tin về hoặc kiểm soát ứng dụng hộp cát của người dùng khác. Trong mô hình này, chúng tôi xem xét


(a) chia sẻ phần cứng theo thời gian, trong đó phiên bản của hai người dùng lần lượt thực thi trên lõi CPU và


(b) đồng vị trí vật lý, trong đó mã của hai người dùng chạy đồng thời trên phần cứng được chia sẻ theo cách này hay cách khác (ví dụ: hai lõi trên cùng một CPU hoặc hai luồng trong cùng một lõi nếu bật SMT).


(2) Mô hình người dùng đến máy chủ (Hình 4): người dùng độc hại nhắm mục tiêu vào một số thành phần của hệ thống máy chủ: Firecracker VMM, KVM hoặc một phần khác của nhân hệ thống máy chủ. Đối với kịch bản này, chúng tôi chỉ xem xét việc chia sẻ tài nguyên phần cứng theo thời gian. Điều này là do máy chủ chỉ thực thi mã nếu VM của người dùng khách thoát ra, ví dụ do lỗi trang phải được xử lý bởi kernel máy chủ hoặc VMM.


Đối với cả hai mô hình, chúng tôi giả định rằng người dùng độc hại có thể kiểm soát môi trường thời gian chạy của ứng dụng. Trong mô hình của chúng tôi, người dùng độc hại không có đặc quyền kernel khách. Do đó, cả hai mô hình đều cấp cho kẻ tấn công ít đặc quyền hơn một chút so với mô hình được giả định bởi [1] trong đó nhân khách được VMM chọn và cấu hình nhưng được cho là bị xâm phạm trong thời gian chạy. Thay vào đó, khả năng của kẻ tấn công trong các mô hình của chúng tôi khớp với khả năng được cấp cho người dùng khi triển khai Firecracker trong AWS Lambda và Fargate.


Bài viết này có sẵn trên arxiv theo giấy phép CC BY-NC-ND 4.0 DEED.