Bảo mật vi kiến trúc của AWS Firecracker VMM: Tóm tắt & Giới thiệu

Bảng liên kết

• Tóm tắt và giới thiệu
• Lý lịch
• Mô hình mối đe dọa
• Phân tích hệ thống ngăn chặn pháo
• Phân tích cuộc tấn công và phòng thủ vi kiến trúc trong microvms pháo
• Kết luận, lời cảm ơn và tài liệu tham khảo

TRỪU TƯỢNG

Firecracker là trình quản lý máy ảo (VMM) được Amazon Web Services (AWS) xây dựng có mục đích dành cho nền tảng đám mây không có máy chủ— các dịch vụ chạy mã cho người dùng cuối trên cơ sở từng tác vụ, tự động quản lý cơ sở hạ tầng máy chủ. Firecracker cung cấp các máy ảo nhanh và nhẹ, đồng thời hứa hẹn sự kết hợp giữa tốc độ của các bộ chứa, thường được sử dụng để cách ly các tác vụ nhỏ và tính bảo mật của máy ảo, có xu hướng mang lại sự cách ly cao hơn nhưng phải trả giá bằng hiệu năng. AWS tuyên bố, sự kết hợp giữa tính bảo mật và hiệu quả này giúp không chỉ có thể mà còn an toàn khi chạy hàng nghìn tác vụ của người dùng từ những người dùng khác nhau trên cùng một phần cứng, với hệ thống máy chủ chuyển đổi nhanh chóng và thường xuyên giữa các tác vụ đang hoạt động. Mặc dù AWS tuyên bố rằng các cuộc tấn công vi kiến trúc được đưa vào mô hình mối đe dọa của họ, nhưng loại tấn công này phụ thuộc trực tiếp vào phần cứng dùng chung, giống như khả năng mở rộng của điện toán không máy chủ phụ thuộc vào việc chia sẻ phần cứng giữa số lượng người dùng chưa từng có.

Trong công việc này, chúng tôi đ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. Trước tiên, chúng tôi xem xét mô hình cách ly đã nêu của Firecracker và đề xuất các phương pháp triển khai tốt nhất, xác định các mô hình mối đe dọa tiềm ẩn cho nền tảng không có máy chủ và phân tích các điểm yếu tiềm ẩn. Sau đó, chúng tôi sử dụng các khái niệm bằng chứng tấn công vi kiến trúc để kiểm tra khả năng cách ly do Firecracker cung cấp và nhận thấy rằng nó cung cấp rất ít khả năng bảo vệ trước các cuộc tấn công Spectre hoặc MDS. Chúng tôi phát hiện hai trường hợp đặc biệt đáng lo ngại: 1) một biến thể Medusa đe dọa các máy ảo Firecracker nhưng không xử lý các tiến trình chạy bên ngoài chúng và không bị giảm nhẹ bởi các biện pháp phòng vệ do AWS khuyến nghị và 2) một biến thể Spectre-PHT vẫn có thể khai thác được ngay cả khi đã áp dụng các biện pháp đối phó được đề xuất. nơi và SMT bị vô hiệu hóa trong hệ thống. Tóm lại, chúng tôi cho thấy AWS đã phóng đại quá mức độ bảo mật vốn có của Firecracker VMM và cung cấp hướng dẫn không đầy đủ để bảo mật đúng cách các hệ thống đám mây sử dụng Firecracker.

Ý TƯỞNG CCS

• Bảo mật và quyền riêng tư → Ảo hóa và bảo mật; Phân tích kênh bên và các biện pháp đối phó.

TỪ KHÓA

bảo mật hệ thống, bảo mật vi kiến trúc, máy ảo, hypervisor, serverless, hệ thống đám mây

1. GIỚI THIỆU

Điện toán không có máy chủ là một xu hướng mới nổi trong điện toán đám mây, nơi các nhà cung cấp dịch vụ đám mây (CSP) phục vụ môi trường thời gian chạy cho khách hàng của họ. Bằng cách này, khách hàng có thể tập trung vào việc duy trì mã chức năng của mình trong khi giao công việc quản trị liên quan đến phần cứng, hệ điều hành (OS) và đôi khi là thời gian chạy cho CSP. Các mô hình nền tảng không có máy chủ phổ biến bao gồm chức năng như một dịch vụ (FaaS) và dịch vụ chứa dưới dạng dịch vụ (CaaS). Vì các chức năng riêng lẻ thường nhỏ nhưng mỗi ứng dụng của khách hàng có thể chạy từ một đến hàng nghìn chức năng ở bất kỳ đâu nên CSP đặt mục tiêu lắp càng nhiều chức năng trên một máy chủ càng tốt để giảm thiểu thời gian nhàn rỗi và từ đó tối đa hóa lợi nhuận. Một cách tiếp cận khá nhẹ nhàng để phục vụ môi trường thời gian chạy là chạy các thùng chứa, đóng gói một quy trình với các phần phụ thuộc của nó để chỉ các tệp cần thiết cho mỗi quy trình mới được tải trong hệ thống tệp ảo trên hạt nhân dùng chung. Điều này làm giảm việc chuyển đổi giữa các vùng chứa không khác gì chuyển đổi ngữ cảnh giữa các quy trình. Mặt khác, ảo hóa hoàn toàn mang lại sự cách ly tốt giữa các máy ảo (VM) và do đó bảo mật giữa những người thuê, đồng thời khá nặng vì mỗi VM đều có nhân riêng.

Cả hai cách tiếp cận này, container hay VM, đều không lý tưởng để sử dụng trong môi trường không có máy chủ, nơi lý tưởng nhất là nhiều chức năng tồn tại trong thời gian ngắn do nhiều người dùng sở hữu sẽ chạy đồng thời và chuyển đổi thường xuyên, vì vậy, các cơ chế cách ly mới đã được phát triển cho trường hợp sử dụng này. Ví dụ: các cơ chế cách ly trong quá trình [38, 45, 49] được đặt ra để cải thiện tính bảo mật của các vùng chứa bằng cách giảm bề mặt tấn công của thời gian chạy và hạt nhân cơ bản. Bảo vệ hạt nhân là điều quan trọng, vì hạt nhân bị xâm phạm sẽ trực tiếp dẫn đến hệ thống bị xâm phạm hoàn toàn trong hộp chứa. Tuy nhiên, một số biện pháp bảo vệ mạnh mẽ nhất định, chẳng hạn như giới hạn cuộc gọi chung, cũng hạn chế chức năng có sẵn cho vùng chứa và thậm chí phá vỡ khả năng tương thích với một số ứng dụng. Trong nghiên cứu VM, các nhà phát triển đã tạo ra các VM nhỏ hơn và hiệu quả hơn bao giờ hết, cuối cùng dẫn đến cái gọi là microVM. MicroVM cung cấp các đảm bảo cách ly giống như các máy ảo thông thường, nhưng rất hạn chế về khả năng hỗ trợ thiết bị hoặc hệ điều hành, khiến chúng nhẹ hơn so với các máy ảo thông thường và do đó phù hợp hơn với điện toán serverless.

Firecracker [1] là một trình quản lý máy ảo (VMM) được thiết kế để chạy microVM trong khi cung cấp chi phí bộ nhớ và thời gian khởi động tương đương với các hệ thống container thông thường. Firecracker được Amazon Web Services (AWS) tích cực phát triển và đã được sử dụng trong sản xuất cho các dịch vụ điện toán không có máy chủ AWS Lambda [5] và AWS Fargate [4] kể từ năm 2018 [1]. Tài liệu thiết kế của AWS [1] mô tả các tính năng của Firecracker, cách nó khác biệt với các máy ảo truyền thống hơn và mô hình cách ly dự định mà nó cung cấp: an toàn cho “nhiều chức năng chạy [ning] trên cùng một phần cứng, được bảo vệ khỏi leo thang đặc quyền, thông tin tiết lộ, các kênh bí mật và các rủi ro khác” [1]. Hơn nữa, AWS còn cung cấp các đề xuất thiết lập máy chủ sản xuất [8] để bảo mật các phần của CPU và nhân mà máy ảo Firecracker tương tác. Trong bài viết này, chúng tôi thách thức tuyên bố rằng Firecracker bảo vệ các chức năng khỏi các kênh bí mật và kênh bên trên các microVM. Chúng tôi cho thấy rằng bản thân Firecracker không bổ sung vào các biện pháp đối phó tấn công vi kiến trúc mà hoàn toàn dựa vào nhân Linux của máy chủ và máy khách cũng như các bản cập nhật chương trình cơ sở/vi mã CPU.

Các cuộc tấn công vi kiến trúc như các biến thể Spectre [10, 13, 22, 30, 31, 33, 52] và lấy mẫu dữ liệu vi kiến trúc (MDS) [14, 37, 46, 50] gây ra mối đe dọa cho các hệ thống nhiều người thuê như chúng thường xảy ra có thể vượt qua cả ranh giới cách ly phần mềm và kiến trúc, bao gồm cả ranh giới của máy ảo. Spectre và MDS đe dọa những đối tượng thuê chia sẻ tài nguyên lõi CPU như đơn vị dự đoán nhánh (BPU) hoặc bộ đệm điền dòng (LFB). CSP cung cấp nhiều dịch vụ truyền thống hơn có thể giảm thiểu vấn đề về tài nguyên phần cứng dùng chung bằng cách ghim các đối tượng thuê máy ảo tồn tại lâu dài vào các lõi CPU riêng biệt, giúp phân chia tài nguyên giữa các đối tượng thuê một cách hiệu quả và đảm bảo rằng trạng thái vi kiến trúc chỉ được thực hiện bởi một đối tượng thuê duy nhất tại một thời điểm. .

Tuy nhiên, trong môi trường không có máy chủ, mối đe dọa từ các cuộc tấn công kiến trúc vi mô sẽ lớn hơn. Lý do cho điều này là thời gian tồn tại ngắn ngủi của các chức năng được điều hành bởi những người thuê khác nhau. Tài nguyên máy chủ trong môi trường serverless dự kiến sẽ bị cam kết quá mức, điều này dẫn đến các chức năng của đối tượng thuê sẽ cạnh tranh để giành tài nguyên điện toán trên cùng một phần cứng. Việc vô hiệu hóa đa luồng đồng thời (SMT), điều này sẽ vô hiệu hóa việc sử dụng đồng thời tài nguyên CPU của hai luồng anh chị em, làm giảm sức mạnh tính toán của CPU tới 30% [34]. Nếu khách hàng thuê các lõi CPU cụ thể, hình phạt về hiệu suất này có thể được chấp nhận hoặc cả hai luồng trên lõi CPU có thể được thuê cùng nhau. Nhưng đối với các dịch vụ không có máy chủ, hình phạt về hiệu suất trực tiếp có nghĩa là số lượng khách hàng có thể được phục vụ trong một khoảng thời gian nhất định sẽ giảm đi 30%. Đây là lý do tại sao phải giả định rằng hầu hết các CSP không có máy chủ đều kích hoạt SMT trong hệ thống của họ trừ khi họ có quy định khác. Bề mặt tấn công vi kiến trúc sẽ lớn nhất nếu SMT được kích hoạt và luồng độc hại có quyền truy cập đồng thời vào lõi chia sẻ. Nhưng cũng có những biến thể tấn công hoạt động tốt nếu luồng kẻ tấn công chuẩn bị vi kiến trúc trước khi nó chuyển lõi CPU cho luồng nạn nhân hoặc thực thi ngay sau khi luồng nạn nhân tạm dừng thực thi. Và ngay cả khi CSP vô hiệu hóa SMT (như trường hợp của AWS Lambda), đối tượng thuê vẫn chia sẻ CPU với nhiều người khác theo kiểu chia cắt thời gian này.

AWS tuyên bố rằng Firecracker chạy trên hệ thống có hệ thống bảo vệ kiến trúc vi mô cập nhật sẽ cung cấp đủ khả năng tăng cường chống lại các cuộc tấn công kiến trúc vi mô [1]. Tài liệu về Firecracker cũng chứa các đề xuất cụ thể về các biện pháp bảo mật vi kiến trúc cần được kích hoạt. Trong công việc này, chúng tôi kiểm tra các tuyên bố và khuyến nghị về bảo mật của Firecracker và phát hiện những sơ suất trong hướng dẫn của nó cũng như các mối đe dọa hoàn toàn không được giải quyết.

Tóm lại, những đóng góp chính của chúng tôi là:

• Chúng tôi cung cấp bản phân tích bảo mật toàn diện về khả năng cách ly đối tượng thuê chéo và đối tượng thuê-hypervisor của điện toán phi máy chủ khi dựa trên máy ảo Firecracker.

• Chúng tôi kiểm tra khả năng phòng thủ của Firecracker trước các bằng chứng khái niệm tấn công vi kiến trúc (PoC), sử dụng các biện pháp bảo vệ có sẵn thông qua các bản cập nhật vi mã và nhân Linux. Chúng tôi cho thấy rằng bản thân máy ảo cung cấp khả năng bảo vệ không đáng kể trước các lớp tấn công vi kiến trúc chính.

• Chúng tôi xác định một biến thể của cuộc tấn công Medusa MDS có thể bị khai thác từ bên trong máy ảo Firecracker mặc dù nó không có trên máy chủ. Biện pháp giảm nhẹ nhân nhằm bảo vệ chống lại hoạt động khai thác này và hầu hết các biến thể Medusa đã biết đều không được đề cập trong đề xuất thiết lập máy chủ Firecracker của AWS. Ngoài ra, chúng tôi cho thấy rằng việc vô hiệu hóa SMT sẽ không cung cấp đủ khả năng bảo vệ chống lại biến thể Medusa đã được xác định, điều này thúc đẩy nhu cầu giảm thiểu nhân.

• Chúng tôi xác định các biến thể Spectre-PHT và Spectre-BTB làm rò rỉ dữ liệu ngay cả khi đã áp dụng các biện pháp đối phó được khuyến nghị. Các biến thể Spectre-PHT thậm chí còn là một vấn đề khi SMT bị vô hiệu hóa nếu kẻ tấn công và nạn nhân dùng chung lõi CPU theo kiểu cắt thời gian.

1.1 Tiết lộ có trách nhiệm

Chúng tôi đã thông báo cho nhóm bảo mật AWS về những phát hiện của mình và thảo luận chi tiết kỹ thuật. Nhóm bảo mật AWS tuyên bố rằng các dịch vụ AWS không bị ảnh hưởng bởi những phát hiện của chúng tôi do các biện pháp bảo mật bổ sung. AWS đồng ý rằng Firecracker không tự mình cung cấp bảo mật kiến trúc vi mô mà chỉ kết hợp với các bản cập nhật vi mã cũng như hệ điều hành máy chủ và máy khách an toàn, đồng thời có kế hoạch cập nhật các đề xuất thiết lập máy chủ cho quá trình cài đặt Firecracker.