Điểm kiểm tra (nhà cung cấp toàn cầu các giải pháp bảo mật CNTT) phát hành vài ngày trước phần giới thiệu của cơ chế an toàn "Liên kết An toàn", mà gây khó khăn cho việc tạo ra các khai thác thao tác định nghĩa hoặc thay đổi con trỏ đến bộ đệm được cấp phát khi thực hiện một cuộc gọi malloc.
Cơ chế «Liên kết an toàn» mới 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 phức tạp hóa việc tạo ra một số danh mục khai thác nhất địnhNgoài lỗi tràn bộ đệm bị khai thác, cần tìm một lỗ hổng khác gây ra 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, cũng như đề xuất hiện đại hóa bảo vệ trong Chromium (từ năm 2012 Chromium đã được tích hợp với các giải pháp cho cùng một vấn đề) Kỹ thuật bảo vệ MaskPtr, nhưng giải pháp của Checkpoint cho thấy hiệu suất tốt hơn).
Các bản vá lỗi được đề xuất đã được chấp thuận để phân phối trong bản phát hành tháng 3.32 của Glibc 1.0.33 và Liên kết an toàn sẽ được bật theo mặc định. Trong uClibc-NG, hỗ trợ liên kết an toàn đã được bao gồm trong phiên bản XNUMX và được bật theo mặc định. Trong gperftools (tcmalloc cũ), các thay đổi được chấp nhận, nhưng sẽ được cung cấp như một tùy chọn trong bản phát hành trong tương lai.
Các nhà phát triển TCMalloc từ chối chấp nhận thay đổi, cvới thành công về hiệu suất mạnh mẽ và cần thêm các bài kiểm tra nâng cao để thường xuyên xác minh rằng mọi thứ đang hoạt động bình thường.
Các thử nghiệm được thực hiện bởi Các kỹ sư của điểm kiểm tra đã chỉ ra rằng phương pháp Liên kết An toàn không dẫn đến việc tiêu thụ thêm bộ nhớ và hiệu suất khi thực hiện các hoạt động đống trung bình chỉ giảm 0.02% và trong trường hợp xấu nhất là 1.5%
Việc bật Liên kết an toàn dẫn đến việc thực hiện thêm 2-3 lệnh trình hợp dịch với mỗi lệnh gọi tới free () và 3-4 lệnh khi gọi malloc (). Bắt đầu khởi tạo và tạo giá trị ngẫu nhiên là không bắt buộc.
Liên kết an toàn có thể được sử dụng không chỉ để tăng độ an toàn của các triển khai heap khác nhau, sino cũng để thêm kiểm tra tính toàn vẹn vào bất kỳ cấu trúc dữ liệu nào sử dụng danh sách các con trỏ được liên kết riêng lẻ nằm bên cạnh các bộ đệm.
Phương pháp nó rất đơn giản để triển khai 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 của mã (ví dụ: đối với Glibc, chỉ một vài dòng được thay đổi trong mã).
Bản chất của phương pháp là áp 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 được liên kết riêng lẻ như Fast-Bins và TCache. Trước khi áp dụng giá trị con trỏ cho mục tiếp theo trong danh sách, việc chuyển đổi mặt nạ và kiểm tra căn chỉnh được thực hiện dọc theo cạnh của trang bộ nhớ. Con trỏ được thay thế bằng kết quả của phép toán "(L >> PAGE_SHIFT) XOR (P)", trong đó P là giá trị của con trỏ và L là vị trí trong bộ nhớ nơi con trỏ này được lưu trữ.
Khi được sử dụng trong hệ thống ASLR (Address Space Layout Randomization), một số bit L có địa chỉ cơ sở của heap chứa các giá trị ngẫu nhiên được sử dụng làm khóa để mã hóa P (chúng được trích xuất bởi 12 bit cho 4096 byte trang).
Thao túng như vậy giảm nguy cơ nắm bắt một con trỏ trong một khai thác, Vì con trỏ không được lưu trữ ở dạng ban đầu và để thay thế nó, bạn cần biết thông tin về vị trí của đống.
Phương pháp này có hiệu quả trong việc bảo vệ chống lại các cuộc tấn công sử dụng định nghĩa lại một phần con trỏ (dịch chuyển byte thấp), hoàn thành việc viết lại các con trỏ (chuyển hướng đến mã của kẻ tấn công) và định vị lại danh sách theo hướng không thẳng hàng
Ví dụ: việc sử dụng Liên kết an toàn trong malloc sẽ chặn việc khai thác lỗ hổng CVE-2020-6007 được phát hiện gần đây bởi cùng các nhà nghiên cứu trong đèn nền thông minh Philips Hue Bridge do tràn bộ đệm và cho phép kiểm soát thiết bị.
Fuente: https://research.checkpoint.com