Thông tin mới đây đã được công bố về một lỗ hổng bảo mật đe dọa các máy chủ đám mây. Lỗ hổng này cho phép kẻ tấn công giành quyền kiểm soát hoàn toàn máy vật lý , một viễn cảnh tồi tệ đối với các nhà cung cấp cơ sở hạ tầng đám mây.
Lỗ hổng Zapscape, được đăng ký với mã định danh CVE-2026-64561, là một lỗ hổng nghiêm trọng trong trình siêu giám sát Linux KVM, làm lộ ra rủi ro mà nhiều nền tảng vô tình gặp phải khi cho phép ảo hóa lồng nhau. Lỗ hổng này cho phép kẻ tấn công có đặc quyền kernel trong máy ảo (L1) thực thi mã với quyền root trên hệ thống máy chủ (L0), phá vỡ sự cô lập của môi trường ảo hóa.
Được coi là mối đe dọa nghiêm trọng, Zapscape không chỉ tạo điều kiện cho việc thoát khỏi máy ảo mà còn mở ra một lộ trình leo thang đặc quyền cục bộ cho người dùng máy chủ có quyền ghi trên thiết bị /dev/kvm.
Mặc dù các tổ chức như Red Hat đã đánh giá lỗ hổng này với điểm CVSS là 7.0, tập trung vào sự bất ổn và từ chối dịch vụ, nhưng bằng chứng khái niệm (PoC) công khai cho thấy phạm vi phá hoại lớn hơn nhiều: tạo ra một tập tin tùy ý trực tiếp trong thư mục gốc của máy chủ.
Sự hỗn loạn trong đơn vị quản lý bộ nhớ
Cách thức hoạt động của Zapscape được ẩn giấu bên trong Bộ quản lý bộ nhớ (MMU) của KVM và cách hypervisor xử lý bảng trang khi một máy ảo khách (L1) đóng vai trò là hypervisor cho một máy ảo khách con khác (L2). Vấn đề nằm ở lỗi thứ tự logic trong quá trình xử lý lỗi trang. Trong các đường dẫn mã kernel, việc kiểm tra "gốc lỗi thời" được thực hiện trước hàm truy xuất trang, thay vì sau đó.
Trình tự không chính xác này kích hoạt một kịch bản sử dụng sau khi đã giải phóng bộ nhớ kinh điển . Trong quá trình phục hồi, KVM có thể loại bỏ thư mục gốc mà nó đang sử dụng và đánh dấu nó là không hợp lệ. Tuy nhiên, vì quá trình kiểm tra trạng thái đã chạy, hệ thống tiếp tục xây dựng các ánh xạ dưới một thư mục gốc không còn hợp lệ. Điều thú vị là, vấn đề sắp xếp này đã tồn tại trong mã nguồn từ năm 2008, nhưng nó trở nên nghiêm trọng và có thể bị khai thác sau khi phát hành nhân Linux 5.9 vào tháng 7 năm 2020 , khi một chỉ thị được đưa ra mà hệ thống đơn giản là ngừng thực thi.
Yêu cầu và giới hạn
Để có thể khai thác lỗ hổng Zapscape, môi trường phải đáp ứng các yêu cầu rất cụ thể. Đầu tiên, ảo hóa lồng nhau phải được bật trong mô-đun KVM, cấu hình này cho phép kiến trúc ba tầng (L0, L1 và L2). Kẻ tấn công cần bắt đầu cuộc tấn công từ lớp L1 , điều này yêu cầu quyền root trên máy ảo đó. Từ đó, kẻ tấn công thao túng các chế độ bộ nhớ trong khi hoạt động của máy ảo con L2 buộc máy chủ L0 phải bắt đầu truy xuất trang hạn ngạch, gây ra lỗi hỏng bộ nhớ.
Ở cấp độ phần cứng, các điều kiện khác nhau tùy thuộc vào nhà sản xuất. Trên các hệ thống AMD sử dụng bảng trang lồng nhau ( SVM ), lỗ hổng này đơn giản hơn và không yêu cầu bất kỳ tính năng bổ sung nào. Ngược lại, trên bộ xử lý Intel, kịch bản này yêu cầu máy ảo L1 phải có khả năng duyệt trang EPT bốn và năm cấp . Điều này giới hạn vectơ tấn công trên Intel ở các kiến trúc mới hơn, cụ thể là từ dòng Ice Lake-SP trở đi.
Điều đáng chú ý là, mặc dù bằng chứng công khai về khả năng xâm nhập đã thành công vào máy chủ trong môi trường được kiểm soát, các nhà nghiên cứu bảo mật đã báo cáo rằng trên một số nhân hệ điều hành được biên dịch lại, lỗ hổng này chỉ làm sập máy ảo của kẻ tấn công, hoạt động như một cuộc tấn công từ chối dịch vụ chứ không phải là một cuộc xâm nhập hoàn toàn.
Các biện pháp giảm thiểu, vá lỗi và chiến lược
Giải pháp cuối cùng cho vấn đề Zapscape đã xuất hiện trong kho lưu trữ Linux vào tháng 7 năm ngoái với một bản vá sửa lỗi thứ tự xác thực. Bản sửa lỗi này di chuyển việc kiểm tra thư mục gốc lỗi thời đến sau khi phân bổ trang MMU, đảm bảo rằng hypervisor không tạo ra các ánh xạ hoạt động dưới thư mục gốc đã bị xóa. Các bản sửa lỗi này đã được triển khai trong các nhánh kernel ổn định và đang được phân phối rộng rãi bởi nhiều bản phân phối khác nhau.
Đối với các quản trị viên không thể nâng cấp ngay lập tức, có những biện pháp khắc phục tạm thời rất hiệu quả. Hành động ưu tiên là vô hiệu hóa ảo hóa lồng nhau trên tất cả các máy chủ nếu không thực sự cần thiết bằng cách truyền tham số `nested=0` cho các mô-đun `kvm_amd` hoặc `kvm_intel` trong các tệp cấu hình modprobe. Biện pháp này yêu cầu tải lại mô-đun, điều đó có nghĩa là phải dừng bất kỳ máy ảo nào đang hoạt động.
Cuối cùng, nếu bạn muốn tìm hiểu thêm, bạn có thể xem chi tiết tại liên kết sau.