Kees Cook, cựu giám đốc sysadmin tại kernel.org và lãnh đạo nhóm bảo mật Ubuntu, hiện đang làm việc tại Google để bảo vệ Android và ChromeOS, đã phát hành một tập hợp các bản vá lỗi ngẫu nhiên hóa các phần bù của ngăn xếp hạt nhân khi xử lý các cuộc gọi hệ thống. Các bản vá cải thiện bảo mật hạt nhân bằng cách thay đổi vị trí ngăn xếp, lhoặc điều đó làm cho các cuộc tấn công ngăn xếp khó khăn hơn nhiều và ít thành công hơn
Ý tưởng ban đầu cho bản vá thuộc về dự án PaX RANDKSTACK. Vào năm 2019, Elena Reshetova, một kỹ sư tại Intel, đã cố gắng tạo ra một bản triển khai ý tưởng này, phù hợp để đưa vào thành phần chính của nhân Linux.
Sau đó, sáng kiến được thực hiện bởi Kees Cook người đã trình bày cách triển khai phù hợp cho phiên bản chính của hạt nhân và có các bản vá được lên kế hoạch cho phiên bản 5.13 của Linux.
Chế độ này sẽ bị tắt theo mặc định và để kích hoạt nó, tham số dòng lệnh hạt nhân được cung cấp "Randomize_kstack_offset = on / off»Và cài đặt CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, Ngoài ra, chi phí bật chế độ được ước tính làm mất hiệu suất khoảng 1%.
Bản chất của biện pháp bảo vệ được đề xuất là chọn độ lệch ngăn xếp ngẫu nhiên trên mỗi lệnh gọi hệ thống, điều này làm phức tạp việc xác định bố cục ngăn xếp trong bộ nhớ ngay cả khi thông tin địa chỉ được nhận, vì địa chỉ cơ sở của ngăn xếp sẽ thay đổi trong lần gọi tiếp theo.
Không giống như việc triển khai PaX RANDK STACK, trong các bản vá được đề xuất để đưa vào nhân, ngẫu nhiên không được thực hiện ở giai đoạn đầu, nhưng sau khi thiết lập cấu trúc pt_regs, điều này khiến không thể sử dụng các phương pháp dựa trên ptrace để xác định độ lệch ngẫu nhiên trong một cuộc gọi hệ thống chạy dài.
Khi các biện pháp bảo vệ ngăn xếp hạt nhân Linux không ngừng được cải thiện (ánh xạ ngăn xếp dựa trên vmap với các trang bảo vệ, loại bỏ thread_info, STACKLEAK), những kẻ tấn công đã phải tìm ra những cách mới để khai thác của chúng hoạt động.
Họ có và tiếp tục dựa vào thuyết xác định ngăn xếp hạt nhân, trong các tình huống mà VMAP_STACK và THREAD_INFO_IN_TASK_THER chúng không liên quan. Ví dụ: các cuộc tấn công gần đây sau đây sẽ bị cản trở nếu bù đắp ngăn xếp không xác định giữa các lệnh gọi hệ thống
Mục đích của hàm randomize_kstack_offset là thêm một phần bù ngẫu nhiên sau khi pt_regs đã được đẩy lên ngăn xếp và trước khi phần còn lại của ngăn xếp luồng được sử dụng trong quá trình xử lý lệnh gọi hệ thống và thay đổi nó mỗi khi một quy trình đưa ra lệnh gọi hệ thống. Nguồn của sự ngẫu nhiên hiện được xác định bởi kiến trúc (nhưng x86 sử dụng byte thấp của rdtsc ()).
Có thể có những cải tiến trong tương lai đối với các nguồn entropy khác nhau, nhưng nằm ngoài phạm vi của bản vá này. Ngoài ra, để tăng thêm tính khó dự đoán, các hiệu số mới được chọn khi kết thúc các lệnh gọi hệ thống (thời gian trong đó sẽ ít dễ đo lường hơn từ không gian người dùng so với thời điểm nhập lệnh gọi hệ thống) và chúng được lưu trữ trong một biến mỗi CPU, để thời gian tồn tại của giá trị không bị ràng buộc rõ ràng với một tác vụ duy nhất.
Không có thay đổi rõ ràng nào cho điều này trên x86 vì trình bảo vệ ngăn xếp đã bị vô hiệu hóa vô điều kiện đối với đơn vị biên dịch, nhưng thay đổi này là bắt buộc trong arm64. Thật không may, không có thuộc tính nào có thể được sử dụng để tắt trình bảo vệ ngăn xếp cho các chức năng cụ thể. So sánh với hàm PaX RANDKSTACK: Hàm RANDKSTACK ngẫu nhiên hóa vị trí bắt đầu của ngăn xếp (cpu_current_top_of_stack), nghĩa là, nó bao gồm vị trí của cấu trúc pt_regs trên ngăn xếp.
Ban đầu, bản vá này theo cùng một cách tiếp cận, nhưng trong các cuộc thảo luận gần đây, nó đã được xác định là có ít giá trị như thể chức năng ptrace có sẵn cho kẻ tấn công, bạn có thể sử dụng PTRACE_PEEKUSR để đọc / ghi các phần bù khác nhau cho cấu trúc pt_regs, quan sát hành vi bộ nhớ cache của các truy cập pt_regs và tìm phần bù chồng ngẫu nhiên.
Cuối cùng, nó được đề cập rằng triển khai ban đầu hỗ trợ bộ xử lý ARM64 và x86 / x86_64.