Checkpoint đề xuất kỹ thuật bảo vệ Safe-Linking, khiến việc khai thác lỗ hổng trở nên khó khăn hơn

Công ty trạm kiểm soát trình bày Cơ chế bảo vệ Liên kết an toàn, gây khó khăn cho việc tạo ra các khai thác thao túng định nghĩa hoặc sửa đổi con trỏ thành bộ đệm được phân bổ khi thực hiện lệnh gọi malloc. Liên kết an toàn không chặn hoàn toàn khả năng khai thác lỗ hổng, nhưng với chi phí tối thiểu, nó làm phức tạp đáng kể việc tạo ra một số loại khai thác nhất định, vì ngoài lỗi tràn bộ đệm có thể khai thác, cần phải tìm một lỗ hổng khác gây rò rỉ thông tin về vị trí của heap trong bộ nhớ.

Các bản vá triển khai Liên kết an toàn đã được chuẩn bị cho Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) và Google TCMalloc, đồng thời cũng được đề xuất để nâng cấp khả năng bảo vệ trong Chrome (trong
Từ năm 2012, Chrome đã tích hợp sẵn kỹ thuật bảo vệ MaskPtr nhằm giải quyết vấn đề tương tự, nhưng giải pháp từ Checkpoint cho thấy hiệu suất cao hơn).
Các bản vá được đề xuất đã được phê duyệt để phân phối trong bản phát hành tháng 8 Glibc 3.32 và Liên kết an toàn sẽ được bật theo mặc định. uClibc-NG hỗ trợ Liên kết an toàn đã vào có trong bản phát hành 1.0.33 và được bật theo mặc định. Những thay đổi trong gperftools (tcmalloc cũ) Đã được chấp nhận, nhưng sẽ được cung cấp dưới dạng tùy chọn trong bản phát hành trong tương lai.

Các nhà phát triển TCMalloc (tcmalloc mới) từ chối chấp nhận thay đổi, với lý do hiệu suất bị suy giảm nghiêm trọng và cần phải bổ sung thêm các thử nghiệm mở rộng để thường xuyên kiểm tra xem mọi thứ có hoạt động như mong đợi hay không. Thử nghiệm của các kỹ sư Checkpoint cho thấy phương pháp Liên kết an toàn không dẫn đến tiêu thụ thêm bộ nhớ và hiệu suất khi thực hiện các thao tác trên đống chỉ giảm trung bình 0.02% và trong trường hợp xấu nhất là 1.5% (để so sánh, chi phí chung trong phương pháp được sử dụng trong Chrome được ước tính là “nhỏ hơn 2%”). Bao gồm
Liên kết an toàn dẫn đến 2-3 lệnh lắp ráp bổ sung được thực thi mỗi lần free() được gọi và 3-4 lệnh mỗi lần malloc() được gọi. Không cần phải chạy các giai đoạn khởi tạo và tạo giá trị ngẫu nhiên.

Checkpoint đề xuất kỹ thuật bảo vệ Safe-Linking, khiến việc khai thác lỗ hổng trở nên khó khăn hơn

Liên kết an toàn có thể được sử dụng không chỉ để cải thiện tính bảo mật của các triển khai vùng nhớ heap khác nhau mà còn để thêm các biện pháp kiểm soát tính toàn vẹn cho bất kỳ cấu trúc dữ liệu nào sử dụng danh sách con trỏ được liên kết đơn lẻ được đặt bên cạnh bộ đệm. Phương pháp này rất đơn giản để thực hiện và chỉ yêu cầu thêm một macro và áp dụng nó cho các con trỏ tới khối tiếp theo trong mã (ví dụ: đối với Glibc thay đổi chỉ một vài dòng mã). Phương pháp này có những thay đổi sau:

+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))

+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- nextp = p->fd;
+ nextp = REVEAL_PTR(p->fd);
...

Bản chất của phương pháp là sử dụng dữ liệu ngẫu nhiên từ cơ chế ngẫu nhiên hóa địa chỉ ASLR (mmap_base) để bảo vệ các danh sách liên kết đơn lẻ như Fast-Bins và TCache. Trước khi áp dụng con trỏ tới phần tử tiếp theo trong danh sách cho giá trị, nó thực hiện chuyển đổi mặt nạ và kiểm tra căn chỉnh trang. Con trỏ được thay thế bằng kết quả của thao tác "(L >> PAGE_SHIFT) XOR (P)", trong đó P là giá trị của con trỏ và L là vị trí bộ nhớ nơi con trỏ được lưu trữ.

Checkpoint đề xuất kỹ thuật bảo vệ Safe-Linking, khiến việc khai thác lỗ hổng trở nên khó khăn hơn

Khi sử dụng trong hệ thống ASLR (Ngẫu nhiên hóa bố cục không gian địa chỉ) một phần của L bit có địa chỉ cơ sở heap chứa các giá trị ngẫu nhiên được sử dụng làm khóa để mã hóa P (được trích xuất bằng thao tác dịch chuyển 12 bit cho các trang 4096 byte). Thao tác này làm giảm nguy cơ chiếm quyền điều khiển con trỏ khi khai thác, vì con trỏ không được lưu trữ ở dạng ban đầu và việc thay thế nó đòi hỏi kiến ​​thức về phân bổ vùng nhớ heap. Ngoài ra, mã vá lỗi còn chứa một kiểm tra bổ sung về căn chỉnh khối, không cho phép kẻ tấn công thay thế con trỏ bằng giá trị chưa được căn chỉnh và yêu cầu kiến ​​thức về số lượng bit được căn chỉnh, điều này trên hệ thống 64 bit còn cho phép chặn. 15 trong số 16 nỗ lực tấn công không tính đến sự liên kết .

Phương pháp này có hiệu quả để bảo vệ chống lại các cuộc tấn công sử dụng việc viết lại con trỏ một phần (thay đổi byte thấp), viết lại con trỏ hoàn chỉnh (chuyển hướng đến mã của kẻ tấn công) và thay đổi vị trí danh sách tại một địa chỉ chưa được căn chỉnh. Ví dụ: cho thấy việc sử dụng Liên kết an toàn trong malloc sẽ cho phép chặn việc khai thác gần đây xác định bởi cùng các nhà nghiên cứu lỗ hổng CVE-2020-6007 trong đèn thông minh Philips Hue Bridge, do tràn bộ đệm và cho phép bạn giành quyền kiểm soát thiết bị.

Nguồn: opennet.ru

Thêm một lời nhận xét