Les ingénieurs de Google ont résumé les premiers résultats de l'introduction du support du développement en langage Rust dans la plate-forme Android. Dans Android 13, environ 21 % du nouveau code compilé ajouté est écrit en Rust et 79 % en C/C++. Le référentiel AOSP (Android Open Source Project), qui développe le code source de la plateforme Android, contient environ 1.5 million de lignes de code Rust associées à de nouveaux composants tels que le magasin de clés cryptographiques Keystore2, une pile pour puces UWB (Ultra-Wideband) , implémentation du protocole DNS-over-HTTP3, du framework de virtualisation AVF (Android Virtualization Framework), piles expérimentales pour Bluetooth et Wi-Fi.
Conformément à la stratégie précédemment adoptée visant à réduire le risque de vulnérabilités causées par des erreurs de travail avec la mémoire, le langage Rust est actuellement utilisé principalement dans le développement de nouveau code et pour renforcer progressivement la sécurité des composants logiciels les plus vulnérables et les plus vitaux. Il n'y a pas d'objectif général de transférer l'ensemble de la plateforme vers Rust et l'ancien code reste en C/C++, et la lutte contre les erreurs s'effectue grâce à l'utilisation de tests de fuzzing, d'analyses statiques et à l'utilisation dans le développement de techniques similaires à en utilisant le type MiraclePtr (liaison sur des pointeurs bruts, vérifications supplémentaires pour accéder aux zones de mémoire libérées), le 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 du travail avec la mémoire HWAsan (Hardware-assisted AddressSanitizer), GWP-ASAN et KFENCE.
En ce qui concerne les statistiques sur la nature des vulnérabilités de la plate-forme Android, il convient de noter qu'à mesure que le nouveau code fonctionnant de manière non sécurisée avec la mémoire diminue, le nombre de vulnérabilités causées par des erreurs lors du travail avec la mémoire diminue. Par exemple, la part des 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, 2019 vulnérabilités liées à la mémoire ont été identifiées en 223, 2020 en 150, 2021 en 100 et 2022 en 85 (toutes les vulnérabilités notées étaient dans le code C/C++ ; dans le code Rust, il n'y a pas eu de problèmes similaires jusqu'à présent). trouvé). 2022 a été la première année au cours de laquelle les vulnérabilités liées à la mémoire ont cessé de dominer.
Étant donné que les vulnérabilités liées à la mémoire sont généralement 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 d'identification des vulnérabilités non liées au travail avec la mémoire est restée à peu près au même niveau au cours des 4 dernières années - 20 vulnérabilités par mois. La part des problèmes dangereux parmi les vulnérabilités causées par des erreurs lors du travail avec la mémoire demeure également (mais à mesure que le nombre de ces 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 de manière non sécurisée avec la mémoire et le nombre de vulnérabilités liées à la mémoire (débordements de tampon, accès à la mémoire déjà libérée, etc.). Cette observation confirme l’hypothèse selon laquelle, lors de la mise en œuvre de techniques de programmation sécurisée, l’accent devrait être mis sur la suppression du nouveau code plutôt que sur la réécriture du code existant, puisque la majeure partie des vulnérabilités identifiées se trouvent dans le nouveau code.
Source: opennet.ru