Nhà phát triển dự án Chrome 912 lỗ hổng nghiêm trọng và rủi ro cao được xác định trong các bản phát hành ổn định của Chrome kể từ năm 2015 và kết luận rằng 70% trong số đó là do mất an toàn bộ nhớ (lỗi khi làm việc với con trỏ trong mã C/C++). Một nửa trong số những vấn đề này (36.1%) là do truy cập vào bộ đệm sau khi giải phóng bộ nhớ liên kết với nó (use-after-free).
Khi thiết kế Chrome ban đầu người ta đã , có thể xảy ra lỗi trong mã, do đó, người ta nhấn mạnh nhiều vào việc sử dụng tính năng cách ly hộp cát để hạn chế hậu quả của các lỗ hổng bảo mật. Hiện tại, khả năng sử dụng công nghệ này đã đạt đến giới hạn khả năng của chúng và việc phân chia sâu hơn thành các quy trình là không thực tế xét theo quan điểm tiêu thụ tài nguyên.
Để duy trì tính bảo mật của cơ sở mã, Google cũng thực thi "“, theo đó, bất kỳ mã được thêm vào nào cũng phải đáp ứng không quá hai trong số ba điều kiện: làm việc với dữ liệu đầu vào chưa được xác thực, sử dụng ngôn ngữ lập trình không an toàn (C/C++) và chạy với các đặc quyền nâng cao. Quy tắc này ngụ ý rằng mã để xử lý dữ liệu ngoài phải được giảm xuống mức đặc quyền tối thiểu (tách biệt) hoặc được viết bằng ngôn ngữ lập trình an toàn.
Để nâng cao hơn nữa tính bảo mật của cơ sở mã, một dự án đã được triển khai nhằm ngăn chặn lỗi bộ nhớ xuất hiện trong cơ sở mã. Có ba cách tiếp cận chính: tạo thư viện C++ với các chức năng vận hành bộ nhớ an toàn và mở rộng phạm vi của trình thu gom rác, sử dụng cơ chế bảo vệ phần cứng (Tiện ích gắn thẻ bộ nhớ) và viết các thành phần bằng các ngôn ngữ đảm bảo hoạt động an toàn với bộ nhớ (Java, Kotlin, JavaScript, Rust, Swift).
Dự kiến công việc sẽ tập trung vào hai lĩnh vực:
- Thay đổi đáng kể đối với quy trình phát triển C++, không loại trừ tác động tiêu cực đến hiệu suất (kiểm tra giới hạn bổ sung và thu gom rác). Thay vì con trỏ thô, người ta đề xuất sử dụng kiểu , cho phép bạn giảm thiểu các lỗi use-after-free có thể khai thác đối với các sự cố không gây ra mối đe dọa bảo mật mà không có tác động tiêu cực đáng chú ý đến hiệu suất, mức tiêu thụ bộ nhớ và độ ổn định.
- Việc sử dụng các ngôn ngữ được thiết kế để thực hiện kiểm tra an toàn bộ nhớ tại thời điểm biên dịch (sẽ loại bỏ tác động tiêu cực đến hiệu suất vốn có của các kiểm tra đó trong quá trình thực thi mã, nhưng sẽ dẫn đến chi phí bổ sung cho việc tổ chức tương tác mã bằng ngôn ngữ mới với mã trong C++).
Sử dụng thư viện an toàn cho bộ nhớ là cách đơn giản nhất nhưng cũng kém hiệu quả hơn. Viết lại code trong Rust được đánh giá là cách hiệu quả nhất nhưng cũng rất tốn kém.
Nguồn: opennet.ru