Android 13 là phiên bản Android đầu tiên có hầu hết mã mới được thêm vào phiên bản bằng ngôn ngữ an toàn cho bộ nhớ.
Thông qua một bài đăng trên blog, các kỹ sư của Google công bố bản tóm tắt các kết quả đầu tiên của phần giới thiệu Hỗ trợ phát triển Rust trên Android.
Trong Android 13, khoảng 21% mã mới được biên dịch Tổng hợp được viết bằng Rust và 79% bằng C/C++, là kho lưu trữ AOSP (Dự án mã nguồn mở Android), nơi phát triển mã nguồn cho nền tảng Android, có khoảng 1,5 triệu dòng mã Rust.
Mật mã cung cấp bởi AOSP nó liên quan đến 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 qua HTTP3, khung ảo hóa AVF (Khung ảo hóa Android), ngăn xếp thử nghiệm cho Bluetooth và Wi-Fi.
Trong dòng với chiến lược được thông qua ở trên để giảm nguy cơ lỗ hổng lỗi bộ nhớ, Cho đến nay, Rust chủ yếu được sử dụng để 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 công nhất.
Khi số lượng mã không an toàn bộ nhớ mới xâm nhập vào Android đã giảm, số lỗ hổng bảo mật bộ nhớ cũng giảm theo. Từ năm 2019 đến 2022, nó đã giảm từ 76% xuống còn 35% trong tổng số lỗ hổng Android. Năm 2022 đánh dấu năm đầu tiên các lỗ hổng bảo mật bộ nhớ không chiếm phần lớn các lỗ hổng Android.
Mục tiêu chung của việc chuyển toàn bộ nền tảng sang Rust không được đặt ra và mã cũ vẫn ở trong C/C++ và việc chống lại các lỗi trong đó được thực hiện bằng cách sử dụng các thử nghiệm làm mờ, phân tích tĩnh và sử dụng các kỹ thuật tương tự. sử dụng loại MiraclePtr (liên kết trên các con trỏ thô, thực hiện kiểm tra bổ sung để truy cập các vùng bộ nhớ được giải phóng), hệ thống cấp phát 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 (Bộ khử trùng địa chỉ được hỗ trợ bởi phần cứng) , GWP-ASAN và KFENCE.
Về số liệu thống kê về bản chất của những lỗ hổng trên nền tảng Android, người ta quan sát thấy rằng như giảm số lượng mã mới hoạt động với bộ nhớ theo cách không an toàn, nó cũng làm giảm số lỗ hổng do lỗi khi làm việc với bộ nhớ.
Ví dụ: tỷ lệ lỗ hổng do vấn đề 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ề số lượng tuyệt đối, 223 lỗ hổng liên quan đến bộ nhớ đã được xác định vào năm 2019, 150 lỗ hổng vào năm 2020, 100 vào năm 2021 và 85 vào năm 2022. không tìm thấy). 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ị.
Cho đến nay, không có lỗ hổng bảo mật bộ nhớ nào được phát hiện trong mã Rust của Android.
Chúng tôi không hy vọng con số đó sẽ mãi mãi ở mức XNUMX, nhưng với khối lượng mã Rust mới trên hai phiên bản Android và các thành phần nhạy cảm với bảo mật nơi nó được sử dụng, đó là một kết quả đáng kể. Nó cho thấy rằng Rust đang phục vụ mục đích dự định của nó là ngăn chặn nguồn lỗ hổng Android phổ biến nhất.
Vì các lỗ hổng liên quan đến bộ nhớ thường nguy hiểm nhất, 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 đề quan trọng và các vấn đề có thể bị khai thác từ xa. Đồng thời, động lực phát hiện các lỗ hổng không liên quan đến làm việc với bộ nhớ đã ở mức xấp xỉ như nhau trong 4 năm qua - 20 lỗ hổng mỗi tháng.
Tỷ lệ các vấn đề nguy hiểm so với các lỗ hổng do lỗi bộ nhớ gây ra cũng giống nhau (nhưng khi số lỗ hổng giảm thì số vấn đề nguy hiểm cũng giảm theo).
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 với bộ nhớ theo cách không an toàn và số lỗ hổng liên quan đến bộ nhớ (tràn bộ đệm, quyền 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 của rằng sự chú ý chính trong thực hiện các kỹ thuật lập trình an toàn nó nên được trao cho mã mới và không viết lại mã hiện có, vì hầu hết các lỗ hổng được xác định đều nằm trong mã mới.
Fuente: https://security.googleblog.com/