Theo De Raadt có kế hoạch tăng cường cơ chế bảo vệ bộ nhớ W^X (Write XOR Thực thi). Bản chất của cơ chế này là các trang bộ nhớ tiến trình không thể được truy cập đồng thời để ghi và thực thi. Do đó, mã chỉ có thể được thực thi sau khi việc ghi bị vô hiệu hóa và việc ghi vào trang bộ nhớ chỉ có thể được thực hiện sau khi việc thực thi bị vô hiệu hóa. Cơ chế W^X giúp bảo vệ các ứng dụng trong không gian người dùng khỏi các cuộc tấn công tràn bộ đệm thông thường, bao gồm cả lỗi tràn ngăn xếp và đang hoạt động trong OpenBSD .
Từ khi bắt đầu làm việc trên W^X, rõ ràng đây là một chặng đường dài vì có một số lượng đáng kể các ứng dụng sử dụng JIT. Việc triển khai JIT có thể được chia thành ba loại:
- Chuyển đổi bộ nhớ giữa trạng thái W và X, chấp nhận “chi phí” của lời gọi hệ thống .
- Tạo bí danh giữa một cặp ánh xạ W và X của cùng một bộ nhớ.
- Tùy chọn “bẩn” nhất là những tùy chọn yêu cầu mô hình bộ nhớ W|X cho phép ghi và thực thi đồng thời.
Hiện tại, có ít chương trình sử dụng tùy chọn thứ ba hơn đáng kể và có nhiều chương trình sử dụng tùy chọn thứ nhất và thứ hai hơn. Tuy nhiên, vì cần phải chạy các chương trình với W|X JIT (chủ yếu là Chrome và Iridum), nên tùy chọn gắn kết hệ thống tệp "wxallowed" đã được thêm vào, cho phép sử dụng bộ nhớ đồng thời cho cả việc ghi và thực thi, trong trường hợp nếu ELF thực thi được tệp được đánh dấu bằng điểm đánh dấu “wx Needed” và bản thân các ứng dụng cũng được bảo vệ bổ sung bằng các cơ chế и để giới hạn danh sách các lệnh gọi hệ thống được sử dụng và các phần của hệ thống tệp tương ứng có sẵn cho ứng dụng.
Để làm phức tạp thêm việc khai thác các lỗ hổng trong các ứng dụng như vậy, một cơ chế bổ sung được đề xuất , kiểm tra xem lệnh gọi hệ thống có được thực thi từ trang bộ nhớ có thể ghi hay không. Nếu trang có thể ghi được thì quá trình này buộc phải chấm dứt. Bằng cách này, kẻ tấn công sẽ không thể khai thác các cuộc gọi hệ thống và sẽ buộc phải cố gắng tìm các tiện ích cần thiết trong quá trình triển khai JIT hoặc thậm chí thực hiện công việc khó khăn hơn là phát hiện các cuống cuộc gọi hệ thống trực tiếp bên trong. .
Các quy trình Chrome/Iridium đã được bảo vệ khá đáng tin cậy bằng cách sử dụng cam kết và tiết lộ, nhưng việc loại bỏ khả năng sử dụng, chẳng hạn như lệnh gọi hệ thống write(2) rõ ràng có một số lợi thế, vì nó tạo thêm khó khăn cho kẻ tấn công. Tuy nhiên, khó khăn cũng có thể nảy sinh nếu việc triển khai JIT sử dụng lệnh gọi hệ thống gốc từ bộ nhớ W|X. Tuy nhiên, có lý do để hy vọng rằng điều này sẽ không xảy ra, vì ABI đã được thay đổi nhiều lần nhưng chưa có ai báo cáo vấn đề.
Các thay đổi đã có sẵn trong các ảnh chụp nhanh thông thường của chi nhánh OpenBSD-Current, mọi người quan tâm đều có thể thử nghiệm.
Tin tức liên quan về sự xuất hiện của chế độ trong Chrome/Iridium xứng đáng nhận được một bình luận riêng từ Theo . Theo quan điểm của anh ấy, điều này có thể chấp nhận được đối với một số mô hình sử dụng, nhưng có lẽ không phải dành cho tất cả, vì chế độ này rõ ràng sẽ làm tăng tải cho bộ xử lý. Hiện tại, Chrome hầu như sẽ hoạt động nếu bạn tắt "wxallowed" cho /usr/local, mặc dù có thể có vấn đề với một số tiện ích mở rộng (ghostery là một ví dụ). Bằng cách này hay cách khác, Theo hy vọng rằng công việc chính thức ở chế độ JITless sẽ được đưa vào trạng thái hoạt động đầy đủ trong tương lai gần.
Nguồn: opennet.ru