Các kỹ sư của Google đã tóm tắt những kết quả đầu tiên của việc giới thiệu hỗ trợ phát triển bằng ngôn ngữ Rust vào nền tảng Android. Trong Android 13, khoảng 21% mã biên dịch mới được thêm vào được viết bằng Rust và 79% bằng C/C++. Kho lưu trữ AOSP (Dự án mã nguồn mở Android), nơi phát triển mã nguồn của nền tảng Android, chứa khoảng 1.5 triệu dòng mã Rust được liên kết với các thành phần mới như kho khóa mật mã Keystore2, ngăn xếp cho chip UWB (Ultra-Wideband) , triển khai giao thức DNS-over-HTTP3, khung ảo hóa AVF (Khung ảo hóa Android), các ngăn xếp thử nghiệm cho Bluetooth và Wi-Fi.
Theo chiến lược đã được áp dụng trước đây nhằm giảm nguy cơ lỗ hổng do lỗi khi làm việc với bộ nhớ, ngôn ngữ Rust hiện được sử dụng chủ yếu để phát triển mã mới và dần dần tăng cường bảo mật cho các thành phần phần mềm quan trọng và dễ bị tổn thương nhất. Không có mục tiêu chung là chuyển toàn bộ nền tảng sang Rust và mã cũ vẫn còn trong C/C++, và cuộc chiến chống lại các lỗi trong đó được thực hiện thông qua việc sử dụng thử nghiệm mờ, phân tích tĩnh và sử dụng để phát triển các kỹ thuật tương tự như sử dụng loại MiraclePtr (liên kết với các con trỏ thô, thực hiện các kiểm tra bổ sung để truy cập vào các vùng bộ nhớ được giải phóng), hệ thống phân bổ bộ nhớ Scudo (một sự thay thế an toàn cho malloc/free) và các cơ chế phát hiện lỗi khi làm việc với bộ nhớ HWAsan (AddressSanitizer được hỗ trợ bởi phần cứng), GWP-ASAN và KFENCE.
Đối với số liệu thống kê về bản chất của lỗ hổng trên nền tảng Android, cần lưu ý rằng khi mã mới hoạt động không an toàn với bộ nhớ giảm đi, số lượng lỗ hổng do lỗi khi làm việc với bộ nhớ cũng giảm theo. Ví dụ: tỷ lệ lỗ hổng do vấn đề về bộ nhớ gây ra đã giảm từ 76% vào năm 2019 xuống còn 35% vào năm 2022. Về con số tuyệt đối, 2019 lỗ hổng liên quan đến bộ nhớ đã được xác định vào năm 223, 2020 vào năm 150, 2021 vào năm 100 và 2022 vào năm 85 (tất cả các lỗ hổng được ghi nhận đều nằm trong mã C/C++; trong mã Rust, cho đến nay không có vấn đề tương tự nào. thành lập). Năm 2022 là năm đầu tiên các lỗ hổng liên quan đến bộ nhớ không còn thống trị.
Vì các lỗ hổng liên quan đến bộ nhớ thường nguy hiểm nhất nên số liệu thống kê tổng thể cũng cho thấy sự sụt giảm về số lượng các vấn đề nghiêm trọng và các vấn đề có thể bị khai thác từ xa. Đồng thời, động lực xác định các lỗ hổng không liên quan đến hoạt động với bộ nhớ vẫn ở mức gần như cũ trong 4 năm qua - 20 lỗ hổng mỗi tháng. Tỷ lệ các vấn đề nguy hiểm trong số các lỗ hổng do lỗi khi làm việc với bộ nhớ vẫn còn (nhưng vì số lượng các lỗ hổng đó giảm nên số lượng các vấn đề nguy hiểm cũng giảm).
Số liệu thống kê cũng theo dõi mối tương quan giữa số lượng mã mới hoạt động không an toàn với bộ nhớ và số lượng lỗ hổng liên quan đến bộ nhớ (tràn bộ đệm, truy cập vào bộ nhớ đã được giải phóng, v.v.). Quan sát này xác nhận giả định rằng trọng tâm khi triển khai các kỹ thuật lập trình an toàn là loại bỏ mã mới thay vì viết lại mã hiện có, vì phần lớn các lỗ hổng được xác định đều nằm trong mã mới.
Nguồn: opennet.ru