Google : Après avoir utilisé Rust, nous avons réduit les vulnérabilités de sécurité de la mémoire Android

0 0

Google : Après avoir utilisé Rust, nous avons réduit les vulnérabilités de sécurité de la mémoire Android

Google : Après avoir utilisé Rust, nous avons réduit les vulnérabilités de sécurité de la mémoire Android

La décision de Google d’utiliser Rust pour le nouveau code d’Android afin de réduire les défauts liés à la mémoire semble porter ses fruits. Les vulnérabilités de la sécurité de la mémoire dans Android ont été réduites de plus de moitié – une étape qui coïncide avec le passage de Google du C et du C++ au langage de programmation sécurisé pour la mémoire, Rust.

C’est la première année que les vulnérabilités de sécurité de la mémoire ne sont pas la plus grande catégorie de failles de sécurité, et survient un an après que Google a fait de Rust la valeur par défaut pour le nouveau code dans le projet Open Source Android (AOSP).

Parmi les autres langages sécurisés en mémoire que Google a utilisés pour Android, citons Java et Kotlin compatible Java. C et C++ sont toujours des langages dominants dans AOSP, mais Android 13 est la première version où la plupart du nouveau code provient de langages sécurisés en mémoire. Après que Google l’a adopté pour AOSP en avril 2021, Rust représente désormais environ 21 % du nouveau code. Le projet du noyau Linux a adopté cette année Rust comme nouveau deuxième langage officiel du C.

La version 10 d’Android de 2019 comportait 223 bogues de sécurité de la mémoire, tandis qu’Android 13 présentait 85 problèmes de sécurité de la mémoire connus.

Au cours de cette période, les vulnérabilités de sécurité de la mémoire sont passées de 76 % à 35 % des vulnérabilités totales d’Android, Remarques Jeffrey Vander Stoep, ingénieur en logiciel de sécurité Android. Avec cette baisse des vulnérabilités de sécurité de la mémoire, Google constate également une baisse des failles critiques et exploitables à distance.

Vander Stoep note que ce changement n’a pas été motivé par « l’héroïsme » – juste les développeurs utilisant les meilleurs outils pour le travail. L’équipe Android prévoit d’intensifier l’utilisation de Rust, bien qu’il ne soit pas prévu de se débarrasser de C et C++ pour la programmation de ses systèmes.

« Si je devais identifier une seule caractéristique qui rend cela possible, je dirais » l’humilité « . Il y a une volonté à tous les niveaux de l’équipe Android de dire » Comment pouvons-nous faire mieux? ainsi que le courage de suivre et d’apporter des changements, y compris des changements systémiques », il a noté dans un tweet.

« Cependant, l’humilité doit aller dans les deux sens. Rust ne résout pas tous les problèmes, et il y a des domaines où C/C++ continuera d’être l’option la plus pratique pour le développement, au moins pendant un certain temps. Ce n’est pas grave.

« Nous travaillerons à réduire cela au fil du temps tout en continuant à augmenter notre utilisation de Rust et en continuant à investir et à déployer des améliorations de C/C++. »

La corrélation n’équivaut pas à la causalité, note Vander Stoep, mais le pourcentage de bogues de sécurité de la sécurité de la mémoire – qui dominent les bogues de gravité élevée – correspond étroitement aux langages utilisés pour le nouveau code.

Les outils de sécurité tels que le fuzzing ont également eu un impact important sur les bogues de sécurité de la mémoire, explique Google.

« Nous continuons d’investir dans des outils pour améliorer la sécurité de notre C/C++. Au cours des dernières versions, nous avons introduit l’allocateur renforcé Scudo, HWASAN, GWP-ASAN et KFENCE sur les appareils Android de production. Nous avons également augmenté notre couverture fuzzing sur notre base de code existante. Les vulnérabilités trouvées à l’aide de ces outils ont contribué à la fois à la prévention des vulnérabilités dans le nouveau code ainsi que des vulnérabilités trouvées dans l’ancien code qui sont incluses dans l’évaluation ci-dessus. Ce sont des outils importants et d’une importance cruciale pour notre C/ Code C++. Cependant, ceux-ci n’expliquent pas à eux seuls l’important changement dans les vulnérabilités que nous constatons, et d’autres projets qui ont déployé ces technologies n’ont pas vu de changement majeur dans la composition de leurs vulnérabilités. aux langages sécurisés en mémoire est un facteur majeur », écrit Vander Stoep.

Il poursuit en notant que dans Android 13, il y a 1,5 million de lignes de code Rust au total, ce qui représente environ 21 % de tout le nouveau code. À ce jour, Google n’a détecté aucune vulnérabilité de sécurité de la mémoire dans le code Rust d’Android.

« Cela démontre que Rust remplit son objectif de prévention de la source de vulnérabilités la plus courante d’Android. La densité de vulnérabilité historique est supérieure à 1/kLOC (1 vulnérabilité pour mille lignes de code) dans de nombreux composants C/C++ d’Android (par exemple, médias, Bluetooth , NFC, etc.). Sur la base de cette densité historique de vulnérabilités, il est probable que l’utilisation de Rust ait déjà empêché des centaines de vulnérabilités d’atteindre la production », note Vander Stoep.

Google considère l’abandon du C/C++ comme un défi, mais poursuit le projet pour Android. Cependant, il ne passe pas à Rust pour Chrome.

Pour Android, cependant, Google implémente des couches d’abstraction matérielle (HAL) de l’espace utilisateur dans Rust et ajoute la prise en charge de Rust dans les applications de confiance. Il a également migré le micrologiciel de la machine virtuelle dans le cadre de virtualisation Android vers Rust. Et avec la prise en charge de Rust dans la version 6.1 du noyau Linux, Google apporte la sécurité de la mémoire au noyau, en commençant par les pilotes du noyau.

Laisser un commentaire

Votre adresse email ne sera pas publiée.

Abonnez-vous à notre newsletter
Inscrivez-vous ici pour recevoir les dernières nouvelles, mises à jour et offres spéciales directement dans votre boîte de réception.
Vous pouvez vous désabonner à tout moment

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More