Lỗ hổng Linux kernel lộ file root cho người dùng thường, cùng giải pháp ModuleJail

Công nghệ18 tháng 5, 2026·6 phút đọc

Một lỗ hổng nghiêm trọng trong Linux kernel (CVE-2026-46333) cho phép người dùng thông thường truy cập các tệp tin chỉ dành cho root, bao gồm cả khóa SSH. Bài viết cũng đề xuất giải pháp ModuleJail nhằm hạn chế bề mặt tấn công của các module kernel.

Lỗ hổng Linux kernel lộ file root cho người dùng thường, cùng giải pháp ModuleJail

Một lỗ hổng mới trong nhân Linux đã trao cho người dùng cục bộ không có quyền hạn một cách để xem xét các tệp tin mà họ không bao giờ được phép đọc, bao gồm cả những bí mật chỉ dành cho root như khóa SSH. Lỗi này ảnh hưởng đến nhiều dòng kernel LTS từ phiên bản 5.10 trở lên, mặc dù bản sửa lỗi đã sẵn sàng – đồng thời có một đề xuất mới nhằm giảm thiểu khả năng xảy ra các sự cố tương tự trong tương lai.

Những gì nhà cung cấp phân tích FOSS Metabase từng gọi một cách đáng nhớ là "kỷ nguyên khai thác" (strip-mining era) của bảo mật mã nguồn mở vẫn tiếp diễn. Lần này, thủ phạm là CVE-2026-46333, một lỗ hổng kernel cục bộ cho phép người dùng không có đặc quyền đọc các tệp tin mà họ không nên truy cập, bao gồm cả những tệp thường chỉ dành cho root. Do đó, một kẻ tấn công đã có quyền truy cập đăng nhập vào máy bị ảnh hưởng có thể tiềm năng đánh cắp khóa SSH, tệp mật khẩu hoặc các thông tin xác thực bảo mật khác, như blog KnightLi giải thích.

Mặc dù có tên gọi chính thức, một bản demo khai thác trên GitHub gọi nó là ssh-keysign-pwn. Tên này không bắt tai bằng Copy Fail, Dirty Frag hay Fragnesia, nhưng chúng ta có thể nói một cách an toàn rằng đây không phải là một tháng tốt đẹp cho bảo mật.

Theo một báo cáo trên Linux Stans, lỗi này ảnh hưởng đến các phiên bản kernel LTS 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 và 7.0. Tin tốt là nó đã được sửa chữa: chính Linus Torvalds, trong commit 31e62c2, đã gọi bản sửa lỗi này là "ptrace: logic 'get_dumpable()' hợp lý hơn một chút".

Vấn đề này được báo cáo trên danh sách oss-security vào thứ Sáu bởi công ty tư vấn bảo mật Qualys, như được Brad Spengler từ grsecurity lưu ý trên X. Trong cùng một luồng thảo luận, Altan Baig đã chỉ ra rằng vấn đề cơ bản đã được Jann Horn báo cáo trên Danh sách thư Kernel Linux (Linux Kernel Mailing List) từ tận năm 2020. Vấn đề trong việc theo dõi các báo cáo bảo mật, mà Hoàng đế Penguin Torvalds mới đây đã mô tả, đáng buồn thay không phải là mới.

ModuleJail: Một biện pháp phòng thủ mới

Đây cũng dường như là thời điểm tốt để xem xét một biện pháp phòng thủ mới mà chúng tôi thấy khá thú vị: ModuleJail của Jasper Nuyens. Dòng đầu tiên của tệp README tóm tắt nó như sau:

Một script shell POSIX duy nhất thu nhỏ bề mặt tấn công kernel-module của máy chủ Linux bằng cách viết một danh sách đen (blacklist) modprobe.d cho mọi kernel module hiện không được sử dụng, trừ đi đường cơ sở tích hợp sẵn và danh sách trắng (whitelist) tùy chọn của quản trị viên. Không có daemon, không có thay đổi initramfs, không có AI bên trong công cụ. Một script, một lần chạy, một tệp blacklist.

Việc đề cập đến "không có AI bên trong công cụ" có thể là một sự tiết lộ, và bạn có thể thấy một tệp CLAUDE.md trong kho lưu trữ. Dù vậy, cách thức hoạt động của nó đủ đơn giản. Mặc dù Linux có nhân đơn nhất (monolithic kernel), nó là mô-đun: khi mã nguồn kernel được biên dịch, người hoặc công cụ xây dựng nó có thể chọn xem từng thành phần riêng lẻ được bao gồm (xây dựng vào tệp nhị phân), không bao gồm, hoặc biên dịch dưới dạng module, có thể được tải trên bay khi cần.

Vì kernel chủ yếu là trình điều khiển thiết bị, nên các nhà cung cấp bản phân phối thường biên dịch hầu hết các thành phần không thiết yếu dưới dạng kernel module – như wiki Arch giải thích. Đưa một module vào danh sách đen chỉ đơn giản là thêm tên của nó vào danh sách các module không được tải.

Việc đưa các module không sử dụng vào danh sách đen để tăng cường bảo mật không phải là ý tưởng mới. Nó có trong tài liệu RHEL 6, ví dụ, và một bài đăng trên blog DoHost từ năm ngoái mô tả nó như một biện pháp bảo mật.

ModuleJail đơn giản là tự động hóa quy trình này: nó đưa vào danh sách đen bất kỳ module nào hiện không được sử dụng. Có lẽ nó an toàn cho máy chủ, nhưng ít lý tưởng hơn cho máy tính xách tay hoặc máy mà bạn cần cắm phần cứng mới trên bay. Việc kết nối tai nghe USB, ví dụ, khá khác so với việc cắm một chiếc vào giắc cắm tai nghe. Trong khi thiết bị có giắc cắm sử dụng bộ điều khiển âm thanh hiện có của bạn, thì bằng cách kết nối một chiếc qua USB, bạn đang thêm hiệu quả một bộ điều khiển âm thanh mới – chỉ là bộ điều khiển đó kết nối qua USB.

ModuleJail đề cập rằng cách tiếp cận của nó tránh thay đổi initramfs. Một initramfs, giống như initrd, là một tệp chứa đĩa RAM tạm thời, để một kernel chung có thể tìm và tải các trình điều khiển nó cần cho hộp cụ thể mà nó đang chạy – thậm chí trước khi nó có thể tìm thấy SSD của máy và gắn kết phân vùng root.

Quay lại những năm 1990, như những ông già cộc cằn nhớ lại, việc biên dịch lại kernel của bạn là một phần tiêu chuẩn của việc bảo trì hệ thống định kỳ. Một lợi ích của việc xây dựng kernel tùy chỉnh cho máy tính của riêng bạn là loại bỏ nhu cầu về initramfs. Nếu tất cả các trình điều khiển đều được tích hợp sẵn, sẽ không cần giai đoạn tạm thời này, mặc dù như ArchWiki lưu ý, điều này giới hạn một số tính năng nâng cao mà systemd sử dụng.

Chúng tôi rất muốn thấy một số bản phân phối không sử dụng systemd kết hợp việc xác định các module thiết yếu tự động theo kiểu ModuleJail này, và sử dụng nó để xây dựng một kernel tùy chỉnh trên bay, sau đó loại bỏ việc sử dụng initramfs. (Có thể chỉ giữ lại kernel cài đặt bật tất cả các tùy chọn như một dự phòng khẩn cấp). Ngoại trừ một vài trường hợp đặc biệt như OpenZFS, điều này nên hoạt động trên hầu hết phần cứng – và làm cho cuộc sống đơn giản hơn, nhanh hơn và có lẽ an toàn hơn một chút.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗