Meltdown & Spectre - Việc vá nhân khách của một trình ảo hóa chưa được vá có ngăn chặn rò rỉ bộ nhớ VM không?


12

24 giờ sau khi phát hành trên diện rộng các lỗ hổng, Rackspace im lặng về Spectre và Meltdown. Họ không có kế hoạch vá tất cả các siêu giám sát Xen. Tất cả các máy chủ nền tảng mới hơn của họ là máy chủ HVM, dễ bị tấn công. Máy chủ PV cũ không dễ bị tổn thương.

Tôi đã cập nhật nhân Linux của các khách HVM của mình, nhưng Rackspace chưa cập nhật bất kỳ trình ảo hóa nào của họ. Việc cập nhật kernel khách trên một trình ảo hóa chưa được vá sẽ ngăn các VM "kẻ xấu" truy cập bộ nhớ bị rò rỉ từ máy chủ được vá của tôi?


1
Xem thêm bảo
Michael Hampton

Câu trả lời:


12

Từ những gì tôi hiểu về các lỗ hổng, không - các cuộc tấn công bộ nhớ đệm đầu cơ bỏ qua tất cả các biện pháp bảo vệ của CPU chống lại quá trình lấy bộ nhớ từ bất kỳ địa chỉ tùy ý nào.

Tôi tin rằng điều này sẽ bao gồm các máy ảo VM lân cận (ngay cả những máy được vá để bảo vệ chống lại cuộc tấn công) cũng như không gian bộ nhớ kernel của nhà ảo thuật - nhưng ngay cả khi có thứ gì đó tôi thiếu sẽ bảo vệ chống lại việc tiết lộ bộ nhớ trực tiếp, cũng có tiềm năng kẻ tấn công có thể sử dụng quyền truy cập của chúng vào bộ nhớ kernel để có quyền truy cập hoàn chỉnh hơn vào trình ảo hóa.

Bạn chắc chắn không muốn mạo hiểm khi chạy một khối lượng công việc nhạy cảm trên một trình siêu giám sát chưa từng có dưới bất kỳ hình thức nào nếu bạn không tin tưởng tất cả các VM chạy trên nó.


6
Nói một cách rõ ràng: Việc có một kernel khách đã vá có thể ngăn VM của bạn truy cập vào trình ảo hóa hoặc các VM khác, nhưng nó sẽ không ngăn các VM khác truy cập vào VM của bạn!
Michael Hampton

Xin chào Shane, đó là niềm tin của tôi. Bạn có tài liệu nào để sao lưu không? Điểm đặc biệt về bộ nhớ của một khách vá lỗi dễ bị tổn thương trước các khách khác trên cùng phần cứng. Cảm ơn.
Danny F

2
@DannyF Tài liệu tham khảo trực tiếp nhất về điều này mà tôi có thể tìm thấy là trong bài báo meltdown - "bộ nhớ vật lý của các quá trình khác, hạt nhân và trong trường hợp các giải pháp hộp cát chia sẻ hạt nhân (ví dụ: Docker, LXC) hoặc Xen trong chế độ ảo hóa, bộ nhớ của kernel (hoặc hypanneror) và các trường hợp cùng vị trí khác "
Shane Madden

-4

Bóng ma và Meltdown.

Chúng ta bắt đầu từ đâu? Thật tệ, ý tôi là thông cáo báo chí rất tệ về một cái gì đó có thể hoặc không thể ảnh hưởng đến máy tính, máy trạm, máy chủ hoặc máy chủ của bạn trên đám mây. Đúng vậy, nhưng bạn phải có quyền truy cập cục bộ vào CPU, có thể là PC hoặc Điện thoại, có vẻ như Apple đã làm ví dụ nhưng hãy nghĩ CPU ARM của mình, vì vậy mọi nền tảng Di động đều hỗ trợ (tính năng / phơi nhiễm vi mã / kiểm soát quá nhiều CPU từ HĐH / etc / etc)

Ứng dụng phải được chạy trên CPU của thiết bị nên tôi nghĩ sẽ truy cập bảng điều khiển hoặc ít nhất là người dùng từ xa truy cập hệ thống, truy cập thiết bị đầu vào ....

Tại thời điểm này, cách duy nhất được biết để khai thác các lỗ hổng này là từ cục bộ / truy cập trực tiếp vào CPU (Một lần nữa có thể được điều khiển từ xa khi bạn có SSH / VNC, v.v.)

Dưới đây là các bản vá tôi đã tìm thấy cho đến nay.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

Bây giờ đây phải là phản ứng tốt nhất cho vấn đề hiện tại

Bạn bè BSD của chúng tôi đã nói gì?

Google xấu; (

kiểm tra Powershell cho cùng;)

Hạt nhân Linux Ok, chúng tôi đã có một tuần thú vị và đến bây giờ mọi người đều biết tại sao chúng tôi hợp nhất tất cả các bản vá cách ly bảng x86 lẻ mà không tuân theo tất cả các quy tắc thời gian phát hành thông thường.

Tôi có thể / sẽ quay lại và chỉnh sửa bài này. Tôi chắc chắn rằng vấn đề không tồn tại (cho đến khi trong tự nhiên) sẽ không phải là vấn đề thực sự lâu dài. Google thực sự nên theo dõi ngày phát hành tiết lộ ở đây! -1 cho Google


"Amazon Linux (AMI)" là bản phân phối Linux của Amazon, bị ảnh hưởng giống như tất cả các hệ điều hành khách khác. Liên quan hơn trong bối cảnh này là aws.amazon.com/de/security/security-bONSins/AWS-2018-013 (phần ban đầu) cho thông báo EC2 (nền tảng ảo hóa của họ), vì bạn dường như đang cố gắng liệt kê các giải pháp ảo hóa.
Håkan Lindqvist

1
Đọc và đọc lại điều này, tôi không tin rằng nó thực sự giải quyết câu hỏi? Nó chủ yếu chỉ là một lời ca ngợi về quá trình tiết lộ?
Håkan Lindqvist

Tôi đánh giá cao biên tập và các liên kết để sửa lỗi, nhưng câu trả lời này là sai lệch hoặc ít nhất là khó hiểu. Tôi tin rằng nó chỉ ra rằng kịch bản mà tôi mô tả sẽ yêu cầu quyền truy cập cục bộ vào trình siêu giám sát xenserver, điều này không đúng. Yêu cầu duy nhất là kẻ xấu có VM riêng của chúng trên cùng một trình ảo hóa như VM nạn nhân.
Danny F
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.