Android 13 est la première version d'Android où la plupart du nouveau code ajouté à la version est dans un langage sécurisé en mémoire.
Dans un article de blog, les ingénieurs de Google publié le résumé des premiers résultats de l'introduction Prise en charge du développement de Rust sur Android.
Sous Android 13, environ 21 % du nouveau code compilé L'agrégat est écrit en Rust et 79% en C/C++, étant le référentiel AOSP (Android Open Source Project), qui développe le code source de la plate-forme Android, qui compte environ 1,5 million de lignes de code Rust.
Le code fourni par l'AOSP il est lié à de nouveaux composants tels que le keystore cryptographique Keystore2, la pile pour les puces UWB (Ultra-Wideband), l'implémentation du protocole DNS sur HTTP3, le framework de virtualisation AVF (Android Virtualization Framework), les piles expérimentales pour le Bluetooth et le Wi-Fi.
On-line avec la stratégie adoptée ci-dessus pour réduire le risque de vulnérabilités d'erreur de mémoire, Jusqu'à présent, Rust a été utilisé principalement pour le développement de nouveaux codes et pour renforcer progressivement la sécurité des composants logiciels les plus vulnérables et les plus vitaux.
Alors que le nombre de nouveaux codes non sécurisés en mémoire entrant dans Android a diminué, le nombre de vulnérabilités de sécurité de la mémoire a également diminué. De 2019 à 2022, il est passé de 76% à 35% des vulnérabilités Android totales. 2022 marque la première année où les vulnérabilités de sécurité de la mémoire ne représentent pas la majorité des vulnérabilités d'Android.
L'objectif général de transférer l'intégralité de la plateforme vers Rust n'est pas fixé, et l'ancien code reste en C/C++, et la lutte contre les bogues s'y fait en utilisant des tests de fuzzing, des analyses statiques, et l'utilisation de techniques similaires. utilisation du type MiraclePtr (liaison sur des pointeurs bruts, qui effectue des vérifications supplémentaires pour accéder aux zones mémoire libérées), du système d'allocation de mémoire Scudo (un remplacement sûr de malloc/free) et des mécanismes de détection d'erreurs lors de l'utilisation de la mémoire HWAsan (Hardware Assisted AddressSanitizer) , GWP-ASAN et KFENCE.
En ce qui concerne les statistiques sur la nature de les vulnérabilités sur la plate-forme Android, on observe que comme diminue la quantité de nouveau code qui fonctionne avec la mémoire de manière non sécurisée, il diminue également le nombre de vulnérabilités causées par des erreurs lors de l'utilisation de la mémoire.
Par exemple, la proportion de vulnérabilités causées par des problèmes de mémoire est passée de 76 % en 2019 à 35 % en 2022. En chiffres absolus, 223 vulnérabilités liées à la mémoire ont été identifiées en 2019, 150 en 2020, 100 en 2021 et 85 en 2022. n'ont pas été trouvés). 2022 a été la première année où les vulnérabilités liées à la mémoire ont cessé de dominer.
À ce jour, aucune vulnérabilité de sécurité de la mémoire n'a été découverte dans le code Android Rust.
Nous ne nous attendons pas à ce que ce nombre reste à zéro pour toujours, mais étant donné le volume de nouveau code Rust sur deux versions d'Android et les composants sensibles à la sécurité où il est utilisé, c'est un résultat significatif. Cela montre que Rust remplit son objectif de prévenir la source la plus courante de vulnérabilités Android.
Étant donné que les vulnérabilités liées à la mémoire sont souvent les plus dangereuses, les statistiques globales montrent également une diminution du nombre de problèmes critiques et de problèmes pouvant être exploités à distance. Dans le même temps, la dynamique de détection des vulnérabilités non liées au travail avec la mémoire est à peu près au même niveau depuis 4 ans - 20 vulnérabilités par mois.
Le rapport entre les problèmes dangereux et les vulnérabilités causées par des erreurs de mémoire est également le même (mais à mesure que le nombre de vulnérabilités diminue, le nombre de problèmes dangereux diminue également).
Les statistiques suivent également la corrélation entre la quantité de nouveau code qui fonctionne avec la mémoire de manière non sécurisée et le nombre de vulnérabilités liées à la mémoire (débordements de tampon, accès à de la mémoire déjà libérée, etc.).
Ce constat confirmer l'hypothèse de que l'attention principale dans le mise en œuvre de techniques de programmation sécurisées il convient de le donner au nouveau code et non de réécrire l'existant, puisque la plupart des vulnérabilités identifiées se trouvent dans le nouveau code.
source: https://security.googleblog.com/