Nếu bị khai thác, những lỗ hổng này có thể cho phép kẻ tấn công truy cập trái phép vào thông tin nhạy cảm hoặc thường gây ra sự cố
Cách đây vài ngày có thông báo rằng đó là một lỗ hổng được phát hiện trong hệ thống con mạng kernel Linux mà cho phép, ghi đè nội dung bộ nhớ của hạt nhân, bằng cách thao tác các ổ cắm mạng trong không gian người dùng.
Người ta đề cập rằng lỗ hổng bảo mật (đã được phân loại theo CVE-2023-42752) được phân loại là quan trọng và có thể được sử dụng để cho phép người dùng không có đặc quyền truy cập để chạy mã của bạn ở cấp hạt nhân.
Giới thiệu về lỗ hổng CVE-2023-42752
Như vậy, lỗi được phát hiện Nguyên nhân là do một thay đổi được giới thiệu trong nhân Linux phiên bản 6.2, nhưng người ta đề cập rằng thay đổi này cũng đã được đưa vào tất cả các nhánh LTS được hỗ trợ, do đó lỗ hổng Nó cũng xuất hiện trong các phiên bản cũ hơn của các nhánh hạt nhân ổn định được hỗ trợ.
Xin chào,
Gần đây tôi đã gặp phải tình trạng tràn số nguyên trong nhân Linux, dẫn đến vào kernel bằng cách phân bổ `skb_shared_info` trong không gian người dùng, tức là có thể khai thác trên các hệ thống không có sự bảo vệ SMAP khỏi `skb_shared_info` chứa các tham chiếu đến con trỏ hàm.
Tôi đã xác minh sự tồn tại của lỗ hổng ở cả nhánh chính và v6.1.y, nhiều phiên bản hơn có thể bị ảnh hưởng (có thể là tất cả các phiên bản ổn định)
Về nguyên nhân của vấn đề, người ta đề cập tràn số nguyên vẫn xảy ra trong hàm "alloc_skb" của nhân Linux, tín hiệu được sử dụng để cung cấp cấp phát bộ nhớ cho cấu trúc sk_buff (bộ đệm ổ cắm), được sử dụng để lưu trữ các gói mạng.
Lỗ hổng này có thể bị khai thác do sự cố dẫn đến tràn xảy ra do thiếu xác thực chính xác các tham số nhận được từ người dùng được sử dụng để tính toán kích thước bộ đệm. Một cuộc tấn công bởi người dùng không có đặc quyền yêu cầu quyền truy cập để tạo không gian tên người dùng, ví dụ, có thể được cung cấp trong các thùng chứa cách nhiệt.
Ảnh chụp màn hình mã
Nó được đề cập rằng: Hàm `kmalloc_reserve` làm tròn kích thước trong `PAGE_SIZE << get_order(size);` trong `kmalloc_size_roundup`. Vì 'size' là 'unsigned int`, logic làm tròn sẽ biến nó thành 0 nếu giá trị ban đầu lớn hơn, ví dụ như 0xffffded0. Kết quả là, "dữ liệu" thực sự sẽ trở thành `ZERO_SIZE_PTR`, là 0x10 thay vì 0. Vì việc xác minh không xem xét trường hợp này nên hạt nhân sẽ tiếp tục xử lý "dữ liệu" như thể chúng là một con trỏ tới hạt nhân hợp lệ.
Sau này, khi kernel cố gắng hoàn thiện đối tượng skb trong `__finalize_skb_around`, nó có mã: `shinfo = skb_shinfo(skb);`, là `skb->head+skb->end` trong đó `skb->head ` là 0x10 và `skb->end`
có kích thước lớn như 0xffffmed0. Kết quả là, `shinfo` trỏ tới một con trỏ vùng người dùng.
Điều đáng nói là lỗ hổng CVE-2023-42752 là cục bộ và không thể khai thác từ xa qua mạng, vì như chúng tôi đã đề cập ở trên, kẻ tấn công yêu cầu quyền truy cập để tạo không gian tên người dùng.
Trở lại năm 2010, tôi đã không nhận ra rằng những người dùng độc hại có thể đặt dev->mtu thành các giá trị tùy ý. Mtu này kể từ đó đã bị giới hạn ở 0x7fffffff, nhưng bất kể dev->mtu lớn đến mức nào, sẽ không có ý nghĩa gì khi igmpv3_newpack() phân bổ nhiều hơn IP_MAX_MTU và có nguy cơ tràn một số trường skb
Là giải pháp tạm thời Nên kích hoạt cơ chế bảo vệ SMAP (Ngăn chặn truy cập chế độ giám sát) trong kernel, giúp chặn sự cố.
Khi giải pháp cho vấn đề như vậy, điều này đã được vá và được phân phối trong các bản sửa lỗi ngăn chặn lỗ hổng trong các phiên bản khác nhau có hỗ trợ kernel, có đề cập rằng những thay đổi đã được chấp nhận trong các nhánh ổn định của kernel vào ngày 5 tháng XNUMX.
Cuối cùng, đối với quan tâm đến việc theo dõi sự điều chỉnh về lỗ hổng bảo mật, bạn có thể làm như vậy trên các trang của các bản phân phối khác nhau: Debian, Ubuntu, Gentoo, RHEL,mũ phớt và SUSE/mởSUSE.Bạn có thể kiểm tra chi tiết về lỗ hổng trong liên kết theo dõi.