Khai thác các tham chiếu null trong nhân Linux
Mới đây, các nhà nghiên cứu từ nhóm Google Project Zero đã thông báo rằng họ đã phát triển một phương pháp để khai thác các lỗ hổng trong nhân Linux do việc truy cập con trỏ NULL gây ra.
Cho đến nay, các vấn đề liên quan đến nhân hệ điều hành về việc truy cập con trỏ NULL vẫn chưa nhận được sự quan tâm đúng mức , vì người ta cho rằng việc biến những vấn đề đó thành các cuộc tấn công dẫn đến leo thang đặc quyền hoặc thực thi mã của chính mình là không thực tế (việc ánh xạ các tiến trình không có đặc quyền đến vùng địa chỉ thấp hơn trong không gian địa chỉ là bị cấm).
Theo nguyên tắc chung, những lỗi như vậy dẫn đến việc nhân hệ điều hành tạo ra cảnh báo "oops", sau đó các tác vụ gây ra sự cố sẽ được hoàn thành và trạng thái được khôi phục mà không cần phải dừng hệ thống.
Phương pháp tấn công mới dựa trên việc xử lý các trạng thái "oops" , có thể dẫn đến việc tăng giá trị của bộ đếm tham chiếu (refcount), từ đó có thể gây ra hiện tượng tràn bộ đếm và giải phóng bộ nhớ liên kết với refcount.
Trong trường hợp này, việc khai thác được giảm xuống thành các thao tác điển hình của các cuộc tấn công sử dụng sau khi sử dụng miễn phí (tình huống phát sinh khi số tham chiếu của đối tượng trở thành XNUMX, bộ nhớ được giải phóng, nhưng trên thực tế có các liên kết đang hoạt động trỏ đến bộ nhớ được giải phóng).
Hiện tại, khi nhân Linux kích hoạt lỗi truy cập con trỏ null từ bên trong ngữ cảnh tiến trình, nó sẽ tạo ra một thông báo lỗi "oops" , khác với lỗi "kernel panic". Lỗi "kernel panic" xảy ra khi nhân xác định rằng không có cách nào an toàn để tiếp tục thực thi và do đó phải dừng tất cả quá trình thực thi. Tuy nhiên, nhân không dừng tất cả quá trình thực thi trong trường hợp lỗi "oops"; thay vào đó, nhân cố gắng khôi phục tốt nhất có thể và tiếp tục thực thi.
Hủy bỏ hội nghị một con trỏ NULL được sử dụng ở đây như một cách để tạo trạng thái "rất tiếc" theo cách được kiểm soát. Vấn đề là phải mất khoảng 232 cuộc gọi trạng thái "rất tiếc" để đạt đến mức tràn refcount 32 bit.
Về mặt thực tế, cần khoảng tám ngày liên tục tạo ra các trạng thái không đúng vị trí (OOP) để thực hiện một cuộc tấn công sử dụng lỗ hổng được đề xuất. Nếu thành công, lỗ hổng này cho phép bạn thực thi mã của mình ở cấp độ nhân hệ điều hành.
Quy ước con trỏ NULL được sử dụng trong quá trình khai thác đã được khắc phục vào tháng XNUMX, nhưng vì các sự cố tương tự không phải là hiếm và trước đây được coi là lỗi chứ không phải lỗ hổng, các nhà phát triển sẽ bổ sung biện pháp bảo vệ chung cho nhân Linux để ngăn chặn các cuộc tấn công thao túng việc tạo ra "rất tiếc". ."
Trong trường hợp của một tác vụ, điều đó có nghĩa là loại bỏ ngăn xếp hạt nhân hiện có và chuyển trực tiếp tới make_task_dead gọi do_exit. Hạt nhân cũng sẽ đăng lên dmesg nhật ký "sự cố" và dấu vết hạt nhân cho biết trạng thái của hạt nhân khi xảy ra lỗi. Điều này có vẻ như là một lựa chọn kỳ lạ khi bộ nhớ bị hỏng rõ ràng; tuy nhiên, mục đích là làm cho các lỗi kernel dễ dàng phát hiện và ghi lại hơn theo triết lý rằng một hệ thống đang chạy dễ gỡ lỗi hơn nhiều so với một hệ thống đang hoạt động.
Cụ thể , Kernel 6.2 bao gồm các thay đổi để giới hạn số lần lỗi "oops" tối đa . Sau khi đạt đến giới hạn, được đặt mặc định là 10.000 lần lỗi (bạn có thể thay đổi giá trị này bằng tham số oops_limit nếu muốn), kernel sẽ bắt đầu chuyển sang trạng thái "panic", tiếp theo là khởi động lại, điều này sẽ không cho phép số lần lặp cần thiết để đặt lại refcount về 0.
Người ta cũng lên kế hoạch rằng hạn chế sẽ được chuyển sang các nhánh nhân đã phát hành trước đó nhưng vẫn được hỗ trợ, cũng như các gói nhân của các bản phân phối phổ biến.
Cuối cùng, nếu bạn muốn tìm hiểu thêm về vấn đề này , bạn có thể xem chi tiết tại liên kết sau.