Android 13 ialah versi pertama Android yang kebanyakan kod baharu yang ditambahkan pada versi adalah dalam bahasa yang selamat memori.
Melalui catatan blog, jurutera Google mengeluarkan ringkasan keputusan pertama daripada pengenalan Sokongan pembangunan karat pada Android.
Pada Android 13, kira-kira 21% daripada kod baharu disusun Agregat ditulis dalam Rust dan 79% dalam C/C++, sebagai repositori AOSP (Android Open Source Project), yang membangunkan kod sumber untuk platform Android, yang mempunyai kira-kira 1,5 juta baris kod Rust.
Kodnya disediakan oleh AOSP ia berkaitan dengan komponen baharu seperti stor kunci kriptografi Keystore2, tindanan untuk cip UWB (Ultra-Wideband), pelaksanaan protokol DNS melalui HTTP3, rangka kerja virtualisasi AVF (Rangka Kerja Maya Maya), tindanan percubaan untuk Bluetooth dan Wi-Fi.
Selaras dengan strategi yang diguna pakai di atas untuk mengurangkan risiko kelemahan ralat ingatan, Sehingga kini Rust telah digunakan terutamanya untuk pembangunan kod baharu dan secara beransur-ansur mengukuhkan keselamatan komponen perisian yang paling terdedah dan penting.
Memandangkan bilangan kod memori-tidak selamat baharu yang memasuki Android telah berkurangan, bilangan kelemahan keselamatan memori juga telah berkurangan. Dari 2019 hingga 2022, ia menurun daripada 76% kepada 35% daripada jumlah kelemahan Android. 2022 menandakan tahun pertama bahawa kelemahan keselamatan memori tidak mengambil kira sebahagian besar kelemahan Android.
Matlamat umum untuk memindahkan keseluruhan platform kepada Rust tidak ditetapkan, dan kod lama kekal dalam C/C++, dan memerangi pepijat di dalamnya dilakukan dengan menggunakan ujian kabur, analisis statik dan penggunaan teknik yang serupa. penggunaan jenis MiraclePtr (mengikat pada penunjuk mentah, yang melakukan pemeriksaan tambahan untuk mengakses kawasan memori yang dibebaskan), sistem peruntukan memori Scudo (penggantian selamat untuk malloc/free) dan mekanisme pengesanan ralat apabila bekerja dengan memori HWAsan (Hardware Assisted AddressSanitizer) , GWP-ASAN dan KFENCE.
Berkenaan statistik tentang sifat kelemahan pada platform Android, diperhatikan bahawa sebagai mengurangkan jumlah kod baharu yang berfungsi dengan memori dengan cara yang tidak selamat, ia juga mengurangkan bilangan kelemahan yang disebabkan oleh ralat semasa bekerja dengan memori.
Sebagai contoh, bahagian kelemahan yang disebabkan oleh isu ingatan menurun daripada 76% pada tahun 2019 kepada 35% pada tahun 2022. Dalam jumlah mutlak, 223 kelemahan berkaitan memori telah dikenal pasti pada tahun 2019, 150 pada tahun 2020, 100 pada tahun 2021 dan 85 pada tahun 2022. tidak dijumpai). 2022 adalah tahun pertama kelemahan berkaitan memori tidak lagi dikuasai.
Sehingga kini, tiada kelemahan keselamatan memori ditemui dalam kod Android Rust.
Kami tidak menjangkakan nombor itu kekal pada sifar selama-lamanya, tetapi memandangkan jumlah kod Rust baharu merentas dua versi Android dan komponen sensitif keselamatan tempat ia digunakan, ini merupakan hasil yang ketara. Ia menunjukkan bahawa Rust memenuhi tujuan yang dimaksudkan untuk menghalang sumber kerentanan Android yang paling biasa.
Sejak itu kelemahan yang berkaitan dengan ingatan selalunya adalah yang paling berbahaya, statistik keseluruhan juga menunjukkan penurunan dalam bilangan isu kritikal dan isu yang boleh dieksploitasi dari jauh. Pada masa yang sama, dinamik pengesanan kelemahan yang tidak berkaitan dengan kerja dengan memori berada pada tahap yang lebih kurang sama selama 4 tahun yang lalu - 20 kelemahan setiap bulan.
Nisbah isu berbahaya kepada kelemahan yang disebabkan oleh ralat ingatan juga adalah sama (tetapi apabila bilangan kelemahan berkurangan, bilangan masalah berbahaya juga berkurangan).
Statistik juga menjejaki korelasi antara jumlah kod baharu yang berfungsi dengan memori dengan cara yang tidak selamat dan bilangan kelemahan berkaitan memori (limpahan penimbal, akses kepada memori yang telah dibebaskan, dsb.).
Pemerhatian ini mengesahkan andaian yang menjadi perhatian utama dalam pelaksanaan teknik pengaturcaraan selamat ia harus diberikan kepada kod baharu dan bukan untuk menulis semula yang sedia ada, kerana kebanyakan kelemahan yang dikenal pasti berada dalam kod baharu.
Fuente: https://security.googleblog.com/