Lỗ hổng Windows Kernel nghiêm trọng: Nguy cơ DoS từ Rust

Lỗ hổng Windows Kernel nghiêm trọng: Nguy cơ DoS từ Rust

Một lỗ hổng Windows kernel mới được phát hiện trong thành phần kernel Graphics Device Interface (GDI) dựa trên Rust của Microsoft, cho phép kẻ tấn công không có đặc quyền gây crash hoặc chiếm quyền điều khiển các hệ thống Windows.

Check Point Research (CPR) đã phát hiện ra vấn đề này vào tháng 1 năm 2025 và báo cáo cho Microsoft. Công ty đã khắc phục lỗi trong bản cập nhật xem trước KB5058499 (OS Build 26100.4202) ngày 28 tháng 5 năm 2025, với việc triển khai đầy đủ vào cuối tháng 6.

Nội dung
Phát hiện Lỗ hổng và Phân tích Kỹ thuật

Chiến dịch Fuzzing của Check Point Research
Cơ chế Gây Lỗi Kernel
Tác động và Mã Khai thác (PoC)
Phản ứng của Microsoft và Bản vá Bảo mật

Phát hiện Lỗ hổng và Phân tích Kỹ thuật

Chiến dịch Fuzzing của Check Point Research

Quá trình điều tra của CPR bắt đầu bằng một chiến dịch fuzzing tập trung vào các metafile của Windows. Fuzzing là kỹ thuật tiêm dữ liệu ngẫu nhiên hoặc không đúng định dạng vào phần mềm để tìm ra các điểm yếu.

Nhóm đã sử dụng WinAFL Pet để quản lý các tác vụ fuzzing quy mô vừa và BugId để phân tích các sự cố crash. Họ nhắm mục tiêu vào định dạng Enhanced Metafile Format (EMF) và biến thể EMF+ của nó, vốn nhúng các hướng dẫn vẽ cho các hàm GDI.

Các thử nghiệm ban đầu tạo ra các sự cố crash trong user-space và rò rỉ bộ nhớ. Tuy nhiên, sau một tuần, các máy thử nghiệm đã tự động khởi động lại do một sự cố BugCheck kernel.

Các nhà điều tra sau đó chuyển sang thu thập các bản ghi nhớ (memory dumps) và trích xuất các tệp seed đã bị biến đổi từ đĩa RAM bằng cách sử dụng MemProcFS.

Bằng cách chạy lại các mẫu này trong một thiết lập fuzzing đơn thể, họ có thể tái tạo sự cố crash một cách nhất quán trong vòng chưa đầy 30 phút, sau khoảng 380.000 lần biến đổi từ 836 tệp seed.

Cơ chế Gây Lỗi Kernel

Sự cố crash xảy ra trong driver win32kbase_rs.sys dựa trên Rust mới, trong quá trình gọi syscall NtGdiSelectClipPath.

Một kiểm tra giới hạn (bounds check) trong hàm region_from_path_mut() đã thất bại khi dữ liệu đường dẫn không đúng định dạng dẫn đến truy cập mảng ngoài giới hạn (out-of-bounds array access).

Lỗi logic phát sinh khi các bản ghi đường cong Bezier của EMF+ khai báo bốn điểm nhưng cung cấp mười bảy, gây tràn danh sách khối cạnh (edge block lists). Một lệnh gọi panic_bounds_check() đã kích hoạt lỗi Blue Screen of Death (BSOD).

Đây là một lỗ hổng bảo mật nghiêm trọng có thể dẫn đến gián đoạn hoạt động của hệ thống. Để biết thêm chi tiết về nghiên cứu của CPR, vui lòng tham khảo báo cáo Denial of Fuzzing: Rust in the Windows Kernel.

Tác động và Mã Khai thác (PoC)

CPR đã phát triển một script PowerShell proof-of-concept (PoC) để tải một metafile được tạo đặc biệt thông qua các hàm Graphics::FromImage()DrawImage(), vốn được thiết kế cho các tác vụ vẽ thông thường.

# Ví dụ giả định về một phần mã PoC
# Tải metafile độc hại
$metafile = "C:PathToMalformed.emf"
$image = [System.Drawing.Image]::FromFile($metafile)
$graphics = [System.Drawing.Graphics]::FromImage($image)

# Gọi hàm vẽ để kích hoạt lỗi
$graphics.DrawImage($image, 0, 0)

Từ một tài khoản có mức đặc quyền thấp, kẻ tấn công có thể liên tục gây crash các máy tính để bàn hoặc máy chủ trong một doanh nghiệp, dẫn đến tấn công từ chối dịch vụ (DoS) trên diện rộng, có khả năng gây mất dữ liệu và gián đoạn hoạt động.

Phản ứng của Microsoft và Bản vá Bảo mật

Microsoft đã phân loại lỗ hổng Windows kernel này là “denial of service” với mức độ nghiêm trọng trung bình và đã khắc phục thông qua các bản cập nhật không liên quan đến bảo mật vào tháng 6 năm 2025.

Phân tích kích thước tệp win32kbase_rs.sys cho thấy sự gia tăng từ 148 KB lên 164 KB, điều này cho thấy các kiểm tra giới hạn đã được tăng cường.

Bản cập nhật đã giới thiệu hai quy trình xử lý cạnh mới: add_edge_original()add_edge_new(), với các cờ tính năng runtime để chọn đường dẫn an toàn. Mặc dù bản vá bảo mật này đã tồn tại trong bản xem trước, cờ này vẫn bị vô hiệu hóa cho đến khi triển khai trong môi trường sản xuất.

Các nhà nghiên cứu bảo mật lập luận rằng bất kỳ đầu vào nào do người dùng kiểm soát mà dẫn đến BSOD đều nên được coi là một lỗ hổng. Trong trường hợp này, tính an toàn bộ nhớ của Rust đã ngăn chặn việc làm hỏng dữ liệu một cách âm thầm, nhưng lại mặc định gây crash hệ thống.

Một thiết kế mạnh mẽ hơn sẽ xử lý điều kiện ngoài giới hạn một cách uyển chuyển mà không làm ngừng toàn bộ hệ thống. Đây có thể là lỗ hổng bảo mật công khai đầu tiên trong các module kernel Rust của Windows. Điều này nhấn mạnh rằng mặc dù Rust cung cấp các đảm bảo an toàn mạnh mẽ, việc lựa chọn ngôn ngữ không thể thay thế cho các nguyên tắc kiểm thử và thiết kế nghiêm ngặt đối với lỗ hổng Windows kernel.

Ví dụ về một hệ thống báo động nhà phá hủy cả ngôi nhà để ngăn chặn kẻ xâm nhập nhấn mạnh nhu cầu về các biện pháp bảo mật có thể ngăn chặn các mối đe dọa mà không gây ra tác dụng phụ phá hủy. Khi mã Rust ngày càng được tích hợp vào các hệ thống quan trọng, các nhà phát triển phải duy trì các tiêu chuẩn kỹ thuật đặc biệt cao và dự đoán các trường hợp biên tinh vi để ngăn chặn gián đoạn trên quy mô lớn.