Có thể một máy ảo như VirtualBox có lỗ hổng bảo mật "bóng ma" không? Tôi nghĩ rằng VM có thể thực hiện không theo thứ tự, nhưng theo tôi không thể nhìn trộm bộ đệm để đọc kết quả.

Có bất kỳ lời giải thích làm thế nào có thể đọc bộ nhớ cache của một cpu ảo?

Có Spectre có thể vượt qua ranh giới máy chủ / khách, khách / chủ và khách / khách vì đây là lỗ hổng cấp độ CPU có nghĩa là thông tin có khả năng nhạy cảm có thể bị rò rỉ trên bất kỳ thứ gì chạy trên lõi CPU.

Hầu hết các câu chuyện tin tức trên internet nói về các nhà cung cấp đám mây bị ảnh hưởng nặng nề nhất vì họ có các cụm hệ thống khổng lồ được ảo hóa và có khả năng bị lạm dụng để rò rỉ thông tin nhạy cảm.

Bây giờ hầu hết các nhà cung cấp lớn đã được vá lỗi, vì tốt nhất có thể, nhưng đây sẽ là một vấn đề tồn tại với chúng ta trong một thời gian.

Security.SE có một Hỏi & Đáp chính tắc về vấn đề này và nó đề cập đến VM:

Tôi đang chạy Máy ảo / Container, tôi dễ bị tổn thương đến mức nào?

Theo câu trả lời của Steffen Ullrich

• Các cuộc tấn công Meltdown không vượt qua VM, chỉ rò rỉ bộ nhớ kernel cho các tiến trình cục bộ.
• Spectre có thể hoạt động trên các máy ảo.

Ngoài ra, từ Steffen một lần nữa , Meltdown và Spectre hoạt động với các container, vì các container phụ thuộc vào kernel host.

Máy ảo sử dụng CPU thực tế trong hệ thống của bạn với một số hướng dẫn đặc quyền bị mắc kẹt và có thể được chuyển hướng. Nó sử dụng bộ nhớ cache và hướng dẫn giống như máy chủ lưu trữ. Nó thực chất chỉ là một lớp khác trong CPU vật lý trong hệ thống của bạn.

Ảo hóa chỉ nhanh vì nó sử dụng CPU vật lý với càng ít trừu tượng càng tốt và dựa vào phần cứng CPU để cung cấp sự cô lập. Những thứ như qemu có thể thực hiện mô phỏng sẽ an toàn hơn vì nó không phải là CPU phần cứng, nhưng nó chậm hơn nhiều và khác với ảo hóa.

Từ bài viết kinh điển Security.se một lần nữa:

Spectre hoạt động ở một cấp độ khác và không cho phép truy cập dữ liệu không gian nhân từ không gian người dùng. Trong cuộc tấn công này, kẻ tấn công đánh lừa việc thực hiện đầu cơ để dự đoán thực hiện các hướng dẫn sai. Tóm lại, bộ dự đoán bị ép buộc để dự đoán một kết quả nhánh cụ thể (nếu -> đúng), dẫn đến yêu cầu truy cập bộ nhớ ngoài giới hạn mà quy trình nạn nhân thường không yêu cầu, dẫn đến thực hiện đầu cơ không chính xác. Sau đó, theo kênh bên, lấy giá trị của bộ nhớ này. Theo cách này, bộ nhớ thuộc về quá trình nạn nhân bị rò rỉ vào quá trình độc hại.

Vì vậy, vì VM chạy trong phần cứng CPU thực tế và tất cả những gì nó cần làm là chạy một vòng lặp cụ thể để "huấn luyện" công cụ thực thi đầu cơ. Sau đó, nó có thể sử dụng thời gian chính xác để xem các bộ đệm cho các mẫu chỉ định truy cập cụ thể của máy chủ hoặc máy khách (hoặc VM khác) mà nó đang tìm cách khai thác.

Theo cách này, nó có nghĩa là một cỗ máy có thể khai thác theo mọi hướng. Từ máy chủ đến VM, từ VM đến máy chủ và từ VM sang VM.

Đúng, nó không phải là dễ dàng và là một điều khó khăn vì lõi CPU VM có thể thay đổi bất cứ lúc nào của máy chủ và máy chủ cũng có thể vui vẻ lên lịch các tác vụ trên các lõi khác nhau, nhưng trong một thời gian dài đủ thông tin có thể bị rò rỉ để từ bỏ một khóa bí mật cho một số hệ thống hoặc tài khoản quan trọng. Cho đủ thời gian và một số phần mềm tàng hình phù hợp, mọi thứ đều có khả năng mở.

Nếu bạn muốn có một VM "an toàn" thì bạn phải đảm bảo rằng các lõi của nó được cách ly. Cách thực sự duy nhất để ngăn chặn cuộc tấn công này là "buộc" máy chủ và máy ảo chỉ sử dụng một số lõi nhất định để chúng không bao giờ chạy trên cùng một phần cứng nhưng điều này sẽ dẫn đến tăng chi phí hiệu quả vì bạn sẽ không thể có nhiều VM trên một máy chủ nhất định. Bạn sẽ không bao giờ có thể thoát khỏi việc chạy nhiều máy ảo hơn số lượng lõi có sẵn, đây là điều tôi mong đợi sẽ được thực hiện trên các máy chủ "tải thấp" vì nhiều hệ thống không hoạt động trong 90% tuổi thọ của chúng.

đá quý5

Nếu bạn quan tâm đến việc nghiên cứu / tái tạo các lỗ hổng hoàn toàn bằng mô phỏng, mà không sử dụng CPU chủ, tôi không nghĩ QEMU đủ chi tiết để quan sát chúng vì nó không mô phỏng đường ống CPU.

Tuy nhiên, gem5 được sử dụng để ước tính hiệu năng hệ thống trong nghiên cứu và phát triển và mô phỏng đủ các phần bên trong CPU để bạn quan sát Spectre trong môi trường hoàn toàn sạch sẽ và được kiểm soát.

Một bản demo x86_64 thú vị với trực quan hóa đã được xuất bản tại: http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html

Nhược điểm của gem5 là chậm hơn nhiều so với QEMU, mô phỏng chi tiết hơn.