Cảnh báo của Mimikatz: Lỗ hổng leo quyền đặc quyền mức độ cao trên Linux, tạm ngừng ba mô-đun để khẩn cấp khắc phục

Mikhail First Chief Information Security Officer 23pds vào ngày 8 tháng 5 đã công bố rằng hệ thống Linux tồn tại một lỗ hổng nâng cao đặc quyền nghiêm trọng có tên Dirty Frag. Các chi tiết đầy đủ và mã khai thác đã được công khai, cho phép bất kỳ người dùng địa phương có đặc quyền thấp nào có thể trực tiếp nhận quyền quản trị root trên hệ thống bị ảnh hưởng mà không cần điều kiện cụ thể nào của hệ thống. Biện pháp giảm thiểu khẩn cấp là tắt ba mô-đun esp4, esp6 và rxrpc.

Vì sao Dirty Frag lại nguy hiểm đến vậy: Lỗi logic, tỷ lệ thành công cao, không có bản vá

Dirty Frag thuộc nhóm lỗi logic xác định, không phải kiểu tấn công không ổn định dựa vào điều kiện đua tranh, vì vậy tỷ lệ thành công cực cao và có thể tái hiện ổn định. Kẻ tấn công chỉ cần chạy một chương trình nhỏ là có thể ngay lập tức lấy quyền root trên hệ thống mục tiêu; toàn bộ quá trình không làm sập nhân (core) và rất khó bị các công cụ giám sát thông thường phát hiện.

Lỗ hổng được các nhà nghiên cứu bảo mật trình lên đội ngũ lõi Linux vào ngày 30 tháng 4, nhưng trước khi công việc vá lỗi hoàn tất, một “bên thứ ba không liên quan” đã rò rỉ sớm thông tin chi tiết và mã khai thác, khiến lệnh cấm bảo mật buộc phải được gỡ bỏ. Cộng đồng an ninh nhìn nhận điều này có nghĩa là kẻ tấn công độc hại có thể đã đang chủ động khai thác lỗ hổng.

Về nguyên lý kỹ thuật, cơ chế của Dirty Frag tương tự với lỗ hổng Copy Fail vốn đang gây tác hại rộng rãi trong lĩnh vực máy chủ Linux: đều triển khai tấn công bằng cách chèn bộ mô tả mô tả bộ nhớ đệm trang (page cache descriptors) vào thao tác zero-copy. Lỗ hổng gốc “xfrm-ESP Page-Cache Write” được đưa vào từ commit nhân năm 2017 cac2661c53f3; do Ubuntu đã vá lỗ hổng này thông qua AppArmor, PoC đã liên kết với lỗ hổng thứ hai “RxRPC Page-Cache Write” (commit 2dc334f1a63a), nhằm đảm bảo cuộc tấn công vẫn hiệu quả trên hệ thống Ubuntu.

Phạm vi ảnh hưởng: Danh sách các bản phân phối Linux phổ biến đã xác nhận

Đã xác nhận các bản phân phối Linux bị ảnh hưởng (một phần) :

· Ubuntu 24 và Ubuntu 26 (bao gồm AppArmor, thông qua lỗ hổng thứ hai để vượt qua)

· Arch Linux (phiên bản đã cập nhật cũng đã được xác nhận bị ảnh hưởng)

· RHEL (Red Hat Enterprise Linux)

· OpenSUSE

· CentOS Stream

· Fedora

· AlmaLinux

· CachyOS (phiên bản nhân 7.0.3-1-cachyos đã xác nhận có thể kích hoạt)

· WSL2 (Windows Subsystem for Linux) cũng đã xác nhận bị ảnh hưởng

Biện pháp giảm thiểu khẩn cấp: Các lệnh cụ thể để tắt ba mô-đun

Trước khi bản vá chính thức được phát hành, cách giảm thiểu hiệu quả nhất là tắt ba mô-đun esp4, esp6 và rxrpc. Cả ba mô-đun này đều liên quan đến chức năng mạng IPSec; trừ khi bản thân máy chủ là máy khách IPSec hoặc máy chủ, nếu không việc tắt gần như không ảnh hưởng đến hoạt động bình thường.

Chạy các lệnh sau để hoàn tất việc tắt mô-đun: sh -c “printf ‘install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n’ > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true”

Sau khi chạy xong, hãy theo dõi sát sao các thông báo bảo mật của từng bản phân phối Linux. Ngay khi bản cập nhật chính thức được phát hành, hãy triển khai cập nhật hệ thống ngay lập tức.

Câu hỏi thường gặp

Lỗ hổng Dirty Frag hiện đã có bản vá chính thức chưa?

Tính đến hiện tại, phía chính thức vẫn chưa phát hành bất kỳ bản vá nào, và cũng chưa thấy các commit khắc phục trên nhánh chính của nhân Linux. Nguyên nhân là vì lệnh cấm bảo mật đã bị phá vỡ sớm trước khi hoàn tất việc chuẩn bị bản vá, dẫn đến việc chi tiết lỗ hổng được công khai khi công việc sửa chưa xong. Quản trị viên hệ thống cần theo dõi sát sao các thông báo bảo mật của bản phân phối Linux, và sau khi bản vá phát hành thì triển khai ngay.

Việc tắt các mô-đun esp4, esp6 và rxrpc có ảnh hưởng đến hoạt động bình thường của máy chủ không?

Ba mô-đun này chủ yếu liên quan đến giao thức IPSec. Trừ khi máy chủ bản thân là máy khách hoặc máy chủ IPSec (tức là dùng để liên lạc mã hóa ở lớp mạng), còn lại việc tắt gần như không ảnh hưởng đến các nghiệp vụ phổ biến như dịch vụ Web, cơ sở dữ liệu, nút mã hóa… Đây là phương án giảm thiểu khẩn cấp an toàn nhất và có mức ảnh hưởng thấp nhất hiện nay.

Vì sao lần này lỗ hổng lại được công khai trong khi chưa có bản vá?

Thông lệ trong ngành là “công bố có trách nhiệm” — sau khi nhà nghiên cứu bảo mật gửi lỗ hổng cho nhà sản xuất, thường họ sẽ chờ đến khi bản vá hoàn tất rồi mới công bố chi tiết. Lần này lỗ hổng được trình vào ngày 30 tháng 4, nhưng “một bên thứ ba không liên quan” đã rò rỉ sớm thông tin chi tiết, phá vỡ lệnh cấm. Các nhà nghiên cứu suy đoán rằng kẻ tấn công độc hại có thể đã chủ động khai thác lỗ hổng, và đây cũng là nguyên nhân khiến lệnh cấm cuối cùng bị gỡ bỏ.