Bảo mật vi kiến trúc của AWS Firecracker VMM: Phân tích tấn công và phòng thủ vi kiến trúc

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

5. PHÂN TÍCH CÁC TẤN CÔNG VÀ PHÒNG NGỪA CỦA MICRO KIẾN TRÚC TRONG MICROVMS FIRECACKER

Trong phần này, chúng tôi trình bày phân tích của mình về một số PoC tấn công đầu cơ và kênh bên vi kiến trúc trên các microVM Firecracker. Chúng tôi kiểm tra các PoC này trên kim loại trần và trong các phiên bản Firecracker, đồng thời kiểm tra khả năng phòng thủ vi mã có liên quan trong các tình huống khác nhau. Chúng tôi chạy thử nghiệm trên máy chủ có CPU Intel Skylake 4114

có phần mở rộng phần cứng ảo hóa và kích hoạt SMT. CPU chạy trên phiên bản vi mã 0x2006b06[2]. Hệ điều hành máy chủ là Ubuntu 20.04 với nhân Linux 5.10. Chúng tôi đã sử dụng Firecracker v1.0.0 và v1.4.0, phiên bản mới nhất tính đến tháng 7 năm 2023, để chạy máy khách Ubuntu 18.04 với nhân Linux 5.4 do Amazon cung cấp khi làm theo hướng dẫn bắt đầu nhanh[3].

Tóm lại, thiết lập máy chủ sản xuất được đề xuất đi kèm với AWS Firecracker là không đủ khi nói đến việc bảo vệ người thuê khỏi những người hàng xóm độc hại. Do đó, Firecracker không thể cung cấp các đảm bảo cách ly như đã tuyên bố. Điều này là do

(1) chúng tôi xác định một biến thể Medusa chỉ có thể khai thác được khi nó chạy trên microVM. Ngoài ra, các biện pháp đối phó được đề xuất không bao gồm các bước cần thiết để giảm thiểu kênh bên hoặc hầu hết các biến thể Medusa khác.

(2) chúng tôi cho thấy rằng người thuê không được bảo vệ đúng cách khỏi rò rỉ thông tin do Spectre-PHT hoặc Spectre-BTB gây ra khi áp dụng các biện pháp đối phó được khuyến nghị. Các biến thể Spectre-PHT vẫn là một vấn đề ngay cả khi tắt SMT.

(3) chúng tôi nhận thấy không có sự khác biệt nào về hiệu suất PoC giữa Firecracker v1.0.0 và v1.4.0.

Chúng tôi kết luận rằng lớp ảo hóa do Firecracker cung cấp ít ảnh hưởng đến các cuộc tấn công vi kiến trúc và các khuyến nghị về bảo mật hệ thống của Firecracker là chưa đủ.

5.1 Medusa

Chúng tôi đã đánh giá PoC của Moghimi [35] cho các kênh phụ Medusa [37] (được Intel phân loại là các biến thể MLPDS của MDS [25]) trên kim loại trần của hệ thống thử nghiệm của chúng tôi và trong máy ảo Firecracker. Có một PoC bị rò rỉ cho mỗi biến thể trong số ba biến thể đã biết được mô tả trong phần 2.4.2. Chúng tôi đã sử dụng hai chương trình nạn nhân từ thư viện PoC:

• Chương trình “Block Write” ghi một lượng lớn dữ liệu liên tiếp trong một vòng lặp (để bộ xử lý sẽ xác định các lần lưu trữ lặp lại và kết hợp chúng).

• Chương trình “REP MOV” thực hiện thao tác tương tự, nhưng với lệnh REP MOV thay vì nhiều lệnh di chuyển các khối dữ liệu nhỏ hơn trong một vòng lặp.

5.1.1 Kết quả. Bảng 1 cho thấy các trường hợp dữ liệu bị rò rỉ thành công với tất cả các biện pháp bảo vệ vi cấu trúc trong hạt nhân bị vô hiệu hóa. Hai cột bên trái hiển thị các kết hợp có thể có của ba Medusa PoC và hai chương trình nạn nhân đi kèm. Các cột bên phải cho biết cấu hình nào hoạt động trên kim loại trần và chương trình bí mật và rò rỉ chạy trong các phiên bản Firecracker song song. Đáng chú ý nhất là với biến thể Cache Indexing, bí mật Block Write chỉ hoạt động với Firecracker. Điều này có thể là do ảo hóa địa chỉ bộ nhớ mà máy ảo cung cấp: khách chỉ nhìn thấy các vùng bộ nhớ ảo được KVM ánh xạ và KVM bẫy các hướng dẫn truy cập bộ nhớ và xử lý các giao dịch thay mặt cho khách.

Chúng tôi đã kiểm tra tính hiệu quả của các biện pháp phòng thủ mds và nosmt chống lại từng sự kết hợp giữa PoC của kẻ tấn công và nạn nhân trên kim loại trần và trong máy ảo Firecracker. Bảng 2 liệt kê các biện pháp bảo vệ cần thiết để ngăn chặn các cuộc tấn công của Medusa trong các tình huống sử dụng kim loại trần và Pháo. Trong bốn lỗ hổng trong Firecracker, chỉ có một lỗ hổng được giảm thiểu chỉ bằng nosmt và AWS không khuyến nghị rõ ràng việc bật tính năng bảo vệ mds, mặc dù hầu hết các bản phân phối Linux đều bật tính năng này theo mặc định. Điều đó có nghĩa là, nền tảng đám mây nhiều người thuê có thể sử dụng Firecracker theo cách tuân thủ các biện pháp bảo mật được đề xuất của AWS và vẫn dễ bị tấn công bởi phần lớn các biến thể Medusa, bao gồm cả biến thể mà chính Firecracker VMM làm rò rỉ dữ liệu của người dùng. nếu không sẽ bị rò rỉ.

5.2 RIDL và hơn thế nữa

Trong phần này, chúng tôi trình bày đánh giá về các chương trình RIDL PoC [51] được cung cấp cùng với bài báo năm 2019 của van Schaik và cộng sự [50]. RIDL là một loại tấn công MDS khai thác tải suy đoán từ bộ đệm bên trong CPU (không phải từ bộ đệm hoặc bộ nhớ). Kho lưu trữ RIDL PoC cũng bao gồm các ví dụ về các cuộc tấn công được đưa ra trong phụ lục sau của bài báo cũng như một biến thể của cuộc tấn công Fallout MDS.

5.2.1 Kết quả. Bảng 3 hiển thị một số thông tin cơ bản về RIDL PoC mà chúng tôi đã thử nghiệm và hiệu quả của các biện pháp đối phó có liên quan trong việc ngăn chặn các cuộc tấn công. Chúng tôi đã so sánh các cuộc tấn công trên kim loại trần và trong Firecracker để đánh giá tuyên bố của Amazon về mức độ bảo mật phần cứng nâng cao của hệ thống microVM Firecracker. Đối với các thử nghiệm trên hệ thống Firecracker, chúng tôi phân biệt giữa các cờ biện pháp đối phó được kích hoạt trên hệ thống máy chủ (H) và nhân máy khách Firecracker (VM). Ngoài các cờ nhân nosmt và mds, chúng tôi đã thử nghiệm các cờ liên quan khác (xem phần 2.4.4, [21]), bao gồm kaslr, pti và l1tf, nhưng không thấy rằng chúng có ảnh hưởng đến bất kỳ chương trình nào trong số này. Chúng tôi đã loại trừ giảm thiểu tsx_async_abort vì CPU mà chúng tôi đã thử nghiệm bao gồm giảm thiểu mds khiến cờ hạt nhân tsx_async_abort trở nên dư thừa [20].

Nhìn chung, chúng tôi nhận thấy rằng tính năng bảo vệ mds không bảo vệ đầy đủ trước phần lớn các cuộc tấn công RIDL. Tuy nhiên, việc vô hiệu hóa SMT sẽ giảm thiểu phần lớn các hoạt động khai thác này. Điều này nhất quán với tuyên bố của Intel [25] và các nhà phát triển Linux [21] rằng SMT phải bị vô hiệu hóa để ngăn chặn các cuộc tấn công MDS trên các siêu phân luồng. Hai ngoại lệ trong số các PoC này là Align_write, yêu cầu cả nosmt và mds trên máy chủ và pgtable_leak_notsx, chỉ được giảm thiểu bằng các biện pháp đối phó mds. Sự rò rỉ dựa vào căn chỉnh_write sử dụng lỗi căn chỉnh thay vì rò rỉ lỗi bảng trang để kích hoạt suy đoán [50]. Bài báo RIDL [50] và tài liệu của Intel về cách khai thác VRS có liên quan [26] không rõ ràng về điểm khác biệt chính xác của cuộc tấn công này với các cuộc tấn công MFBDS dựa trên lỗi trang được tìm thấy trong các PoC khác, nhưng các phát hiện thử nghiệm của chúng tôi chỉ ra rằng cơ chế vi kiến trúc của rò rỉ là riêng biệt. Có một lời giải thích đơn giản và hợp lý cho hành vi của pgtable_leak_notsx, đây là cách giải thích duy nhất trong số các PoC này vì một lý do chính: đây là cách khai thác duy nhất vượt qua ranh giới bảo mật (rò rỉ các giá trị bảng trang từ kernel) trong một luồng thay vì rò rỉ từ một chủ đề khác. Rõ ràng là việc vô hiệu hóa đa luồng sẽ ít ảnh hưởng đến việc khai thác đơn luồng này. Tuy nhiên, biện pháp đối phó mds xóa bộ đệm vi kiến trúc trước khi chuyển từ thực thi đặc quyền kernel sang thực thi đặc quyền người dùng trong cùng một luồng, xóa sạch dữ liệu bảng trang được mã kernel truy cập từ LFB trước khi mã người dùng tấn công có thể rò rỉ nó.

Ngược lại với Medusa, hầu hết các PoC này đều được giảm nhẹ nhờ khuyến nghị của AWS về việc vô hiệu hóa smt. Tuy nhiên, giống như Medusa, bản thân Firecracker VMM không cung cấp biện pháp bảo vệ vi kiến trúc nào chống lại các cuộc tấn công này.

5.3 Bóng ma

Tiếp theo chúng tôi tập trung vào các lỗ hổng Spectre. Mặc dù đã có nhiều biện pháp đối phó được phát triển kể từ khi các cuộc tấn công của Spectre lần đầu tiên được phát hiện, nhiều biện pháp trong số đó đi kèm với hình phạt hiệu suất (đáng kể) hoặc chỉ giảm thiểu một phần cuộc tấn công. Vì thế,

các nhà khai thác hệ thống thường phải quyết định giữa sự cân bằng giữa hiệu suất và bảo mật. Trong phần này, chúng tôi đánh giá bề mặt tấn công Spectre có sẵn cho người thuê Firecracker trong cả hai mô hình mối đe dọa được mô tả trước đó. Để đánh giá phạm vi rộng của các cuộc tấn công Spectre, chúng tôi dựa vào các PoC được cung cấp trong [15]. Đối với Spectre-PHT, Spectre-BTB và SpectreRSB, mỗi kho chứa bốn PoC. Chúng khác nhau ở cách kẻ tấn công đánh lừa BPU. Bốn khả năng là (1) cùng một quy trình–kẻ tấn công có quyền kiểm soát quy trình nạn nhân hoặc đầu vào của nó để đánh lừa quy trình chéo BPU–(2)–kẻ tấn công chạy mã riêng của nó trong một quy trình riêng biệt để tác động đến các dự đoán nhánh của quy trình nạn nhân–(a) tại chỗ–kẻ tấn công đánh nhầm BPU với lệnh nhánh nằm ở cùng địa chỉ ảo với nhánh mục tiêu mà kẻ tấn công muốn dự đoán sai trong quy trình nạn nhân–(b) ngoài- place–kẻ tấn công đánh nhầm BPU với các hướng dẫn nhánh nằm tại các địa chỉ phù hợp với các nhánh mục tiêu trong quy trình nạn nhân.

(1) quy trình tương tự: kẻ tấn công có quyền kiểm soát quy trình nạn nhân hoặc đầu vào của nó để đánh lừa BPU,

(2) đa tiến trình: kẻ tấn công chạy mã riêng của nó trong một tiến trình riêng biệt để tác động đến các dự đoán nhánh của tiến trình nạn nhân,

(3) tại chỗ: kẻ tấn công đánh nhầm BPU với lệnh nhánh nằm ở cùng địa chỉ ảo với nhánh mục tiêu mà kẻ tấn công muốn dự đoán sai trong quy trình của nạn nhân

(4) không đúng chỗ: kẻ tấn công đánh nhầm BPU với các hướng dẫn nhánh nằm tại các địa chỉ phù hợp với các nhánh mục tiêu trong quy trình nạn nhân.

Hai tình huống đầu tiên và hai tình huống sau là trực giao, vì vậy mỗi PoC kết hợp hai trong số đó. Đối với Spectre-STL, chỉ các biến thể của cùng một quy trình mới được biết, đó là lý do tại sao kho lưu trữ chỉ cung cấp hai PoC trong trường hợp này. Đối với các thử nghiệm trên nhiều VM, tính năng ngẫu nhiên hóa bố cục không gian địa chỉ đã bị vô hiệu hóa cho nhân máy chủ và máy khách cũng như cấp độ người dùng máy chủ và khách để dễ dàng tìm thấy các địa chỉ phù hợp được sử dụng để nhầm lẫn.

5.3.1 Kết quả. Với các biện pháp đối phó được AWS khuyến nghị [8] (mặc định cho nhân Linux đang sử dụng, xem Hình 5) được kích hoạt trên hệ thống máy chủ và bên trong máy ảo Firecracker, chúng tôi thấy rằng Spectre-RSB đã được giảm thiểu thành công cả trên máy chủ cũng như bên trong và trên các máy ảo (xem Bảng 4). Mặt khác, Spectre-STL, Spectre-BTB và Spectre-PHT cho phép rò rỉ thông tin trong các tình huống cụ thể.

PoC cho Spectre-STL cho thấy sự rò rỉ. Tuy nhiên, sự rò rỉ chỉ xảy ra trong cùng một tiến trình và cùng mức đặc quyền. Vì không có biến thể quy trình chéo nào được xác định nên chúng tôi đã không thử nghiệm kịch bản crossVM cho Spectre-STL. Trong mô hình mối đe dọa giữa người dùng với người dùng của chúng tôi, Spectre-STL không phải là một vectơ tấn công có thể xảy ra vì không có biến thể quy trình chéo nào được biết đến. Nếu hai khối lượng công việc của đối tượng thuê bị cô lập bằng cách cách ly trong quá trình trong cùng một VM, Spectre-STL vẫn có thể là một phương tiện tấn công khả thi. Trong mô hình người dùng đến máy chủ, Spectre-STL được giảm thiểu bằng các biện pháp đối phó có trong nhân Linux hiện tại và được bật theo mặc định.

Đối với Spectre-PHT, các biện pháp đối phó hạt nhân bao gồm việc dọn dẹp con trỏ người dùng và sử dụng các rào cản (lfence) trên các thiết bị chuyển mạch cấp đặc quyền. Do đó, chúng tôi kết luận rằng SpectrePHT gây ra ít hoặc không có mối đe dọa nào đối với hệ thống máy chủ. Tuy nhiên, những điều này

các biện pháp giảm thiểu không bảo vệ hai siêu phân luồng khỏi nhau nếu chúng thực thi song song trên cùng một lõi vật lý. Đây là lý do tại sao cả bốn biến thể sai sót Spectre-PHT đều hoạt động đầy đủ trên hệ thống máy chủ cũng như bên trong máy ảo Firecracker. Như có thể thấy trong Bảng 4, điều này vẫn đúng ngay cả khi SMT bị tắt [4]. Trên thực tế, việc ghim cả hai máy ảo vào cùng một luồng vật lý sẽ tạo ra phiên bản Spectre-PHT không đúng quy trình trong khi chúng tôi không quan sát thấy rò rỉ trong trường hợp SMT. Điều này làm cho Spectre-PHT trở thành mối đe dọa đáng kể đối với người dùng.

PoC Spectre-BTB hoạt động một phần khi các biện pháp đối phó được AWS khuyến nghị được kích hoạt. Biến thể ban đầu nhầm lẫn BTB trong cùng một quy trình và tại cùng một địa chỉ có đầy đủ chức năng trong khi biến thể nhầm lẫn ngoài vị trí của cùng một quy trình là

giảm nhẹ thành công. Ngoài ra, tất cả các nỗ lực rò rỉ thông tin qua các ranh giới quy trình thông qua việc đào tạo sai vị trí đều không cho thấy bất kỳ sự rò rỉ nào. Tuy nhiên, với việc đào tạo sai tại chỗ trong nhiều quy trình, chúng tôi đã quan sát thấy sự rò rỉ. Trên hệ thống máy chủ, rò rỉ xảy ra độc lập với SMT. Bên trong VM, rò rỉ chỉ xảy ra nếu tất cả các lõi CPU ảo được gán cho một luồng vật lý riêng biệt. Trên các máy ảo, việc vô hiệu hóa SMT đã loại bỏ rò rỉ.

Ngoài các biện pháp đối phó được liệt kê trong Hình 5, nhân máy chủ còn có các biện pháp đối phó Spectre được biên dịch vào điểm vào và ra VM[5] để vô hiệu hóa hoàn toàn các khách độc hại tấn công nhân máy chủ trong khi nhân xử lý lối ra VM.

Tóm lại, chúng ta có thể nói rằng các biện pháp đối phó mặc định của Linux – được AWS Firecracker khuyến nghị – chỉ giảm thiểu một phần Spectre. Chính xác, chúng tôi hiển thị:

• Spectre-PHT và Spectre-BTB vẫn có thể rò rỉ thông tin giữa các đối tượng thuê trong tình huống khách với khách với các biện pháp đối phó được AWS khuyến nghị – bao gồm cả việc vô hiệu hóa SMT – tại chỗ.

• Nhân máy chủ có thể được bảo vệ đầy đủ nhờ các biện pháp phòng ngừa bổ sung được biên dịch vào nhân Linux để bảo vệ các mục nhập và thoát VM. Tuy nhiên, điều này trực giao với các biện pháp bảo mật do Firecracker cung cấp.

Tất cả các rò rỉ được quan sát đều độc lập với phiên bản Firecracker đang sử dụng.

5.3.2 Đánh giá. Chúng tôi nhận thấy rằng Firecracker không bổ sung các biện pháp giảm thiểu chống lại Spectre mà chỉ dựa vào các khuyến nghị bảo vệ chung, bao gồm các biện pháp giảm thiểu do nhân máy chủ và khách cung cấp cũng như các bản cập nhật vi mã tùy chọn. Tệ hơn nữa, các biện pháp đối phó được đề xuất không đủ để bảo vệ các ứng dụng không có máy chủ khỏi bị rò rỉ thông tin cho những người thuê khác. Do đó, chúng tôi khẳng định rằng Firecracker không đạt được mục tiêu cô lập ở cấp độ vi kiến trúc, mặc dù các cuộc tấn công vi kiến trúc được coi là nằm trong phạm vi của mô hình mối đe dọa Firecracker.

Người đọc cảnh báo có thể thắc mắc tại sao Spectre-BTB vẫn là một vấn đề với biện pháp đối phó STIBP được áp dụng (xem Hình 5) vì bản vá vi mã này được thiết kế để ngăn dự đoán nhánh sử dụng thông tin dự đoán bắt nguồn từ một luồng khác. Điều này cũng khiến chúng tôi bối rối trong một thời gian cho đến khi gần đây Google xuất bản một lời khuyên bảo mật[6] xác định một lỗ hổng trong Linux 6.2 khiến việc giảm nhẹ STIBP liên tục bị vô hiệu hóa khi IBRS được bật. Chúng tôi đã xác minh rằng phần mã được xác định là nguyên nhân gây ra sự cố cũng có trong mã nguồn Linux 5.10. Do đó, giả định của chúng tôi là vấn đề tương tự do Google xác định cũng xảy ra trên hệ thống của chúng tôi.

[2] Việc cập nhật vi mã lên phiên bản mới hơn sẽ vô hiệu hóa TSX trên hệ thống của chúng tôi, điều này khiến việc thử nghiệm với các biến thể MDS dựa trên TSX là không thể.

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

[4] Điều này được mô phỏng bằng cách ghim tiến trình của kẻ tấn công và nạn nhân vào cùng một lõi ((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