La décision de Google d’utiliser Rust pour écrire le nouveau code d’Android afin de réduire les failles liées à la mémoire semble porter ses fruits. Les vulnérabilités liées à la sécurité de la mémoire dans Android ont été réduites de plus de la moitié – une étape importante qui coïncide avec le passage de Google du langage C et C++ au langage de programmation Rust.
C’est la première année que les vulnérabilités liées à la sécurité de la mémoire ne constituent pas la catégorie la plus importante de failles de sécurité. Et ce constat intervient un an après que Google a fait de Rust le langage par défaut pour le nouveau code de l’Android Open Source Project (AOSP).
Parmi les autres langages à sécurité mémoire utilisés par Google pour Android figurent Java et Kotlin, un langage compatible avec Java. Le C et le C++ restent les langages dominants dans AOSP, mais Android 13 est la première version où la plupart du nouveau code provient de langages à mémoire sécurisée. Après que Google l’a adopté pour AOSP en avril 2021, Rust représente désormais environ 21 % du nouveau code. Cette année, le projet de noyau Linux a adopté Rust comme nouveau deuxième langage officiel après le C.
Les vulnérabilités liées à la sécurité de la mémoire sont passées de 76 % à 35 % du total des vulnérabilités d’Android
La version 10 d’Android, datant de 2019, comptait 223 failles de sécurité liées à la mémoire, tandis qu’Android 13 compte 85 problèmes de sécurité de la mémoire connus.
Au cours de cette période, les vulnérabilités liées à la sécurité de la mémoire sont passées de 76 % à 35 % du total des vulnérabilités d’Android, note Jeffrey Vander Stoep, ingénieur logiciel spécialisé dans la sécurité d’Android. Avec cette baisse des vulnérabilités liées à la sécurité de la mémoire, Google constate également une diminution des failles critiques et exploitables à distance.
L’ingénieur note que ce changement n’est pas dû à des « actes héroïques », mais simplement au fait que les développeurs utilisent les meilleurs outils pour leur 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.
Rust et humilité
« 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 la force d’âme nécessaire pour aller jusqu’au bout et apporter des changements, y compris des changements systémiques », note-t-il dans un tweet.
« L’humilité doit aller dans les deux sens cependant. Rust ne résout pas tous les problèmes et, dans certains domaines, le C/C++ restera l’option la plus pratique pour le développement, du moins pendant un certain temps. Ce n’est pas grave. »
« Nous nous efforcerons de réduire cet aspect au fil du temps, tout en continuant à développer l’utilisation de Rust et à investir et à déployer des améliorations pour C/C++. »
Corrélation n’est pas synonyme de causalité, souligne Jeffrey Vander Stoep, mais le pourcentage de failles de sécurité liées à la sécurité de la mémoire – qui dominent les vulnérabilités de haute gravité – correspond étroitement aux langages utilisés pour le nouveau code.
Selon Google, les outils de sécurité tels que le fuzzing ont également eu un impact important sur les failles de sécurité de la mémoire.
Android 13 : 1,5 million de lignes de code Rust, soit 21 % du nouveau code
« Nous continuons à investir dans des outils visant à améliorer la sécurité de notre C/C++. Au cours des dernières versions, nous avons introduit Scudo, HWASAN, GWP-ASAN et KFENCE sur les appareils Android de production. Nous avons également augmenté notre couverture de fuzzing sur notre base de code existante. Les vulnérabilités découvertes à l’aide de ces outils ont contribué à la fois à la prévention des vulnérabilités dans le nouveau code et aux vulnérabilités découvertes dans l’ancien code. Ce sont des outils importants, et d’une importance critique pour notre code C/C++. Cependant, ils n’expliquent pas à eux seuls l’évolution importante des vulnérabilités que nous observons, et d’autres projets qui ont déployé ces technologies n’ont pas constaté de changement majeur dans la composition de leurs vulnérabilités. Nous pensons que le passage continu d’Android de langages peu sûrs pour la mémoire à des langages sûrs pour la mémoire est un facteur important », écrit Jeffrey Vander Stoep.
Il poursuit en indiquant 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. A ce jour, Google n’a pas constaté une seule vulnérabilité en matière de sécurité de la mémoire dans le code Rust d’Android.
« Cela démontre que Rust remplit son objectif de prévenir la source de vulnérabilité la plus courante d’Android. La densité historique des vulnérabilités est supérieure à 1/kLOC (1 vulnérabilité pour 1 000 lignes de code) dans de nombreux composants C/C++ d’Android (par exemple : médias, Bluetooth, NFC). Sur la base de cette densité de vulnérabilité historique, il est probable que l’utilisation de Rust a déjà empêché des centaines de vulnérabilités d’atteindre la production », note l’ingénieur.
Pas de Rust pour Chrome
Google considère que l’abandon de C/C++ est un défi, mais poursuit le projet pour Android. En revanche, il ne passe pas à Rust pour Chrome.
Pour Android, cependant, Google met en œuvre des couches d’abstraction matérielles (HAL – hardware abstraction layers) en Rust et ajoute le support de Rust dans les applications de confiance. Il a également fait migrer les microprogrammes des machines virtuelles dans le cadre de virtualisation d’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.
Pour aller plus loin sur la croissance de l’utilisation de Rust
Source : ZDNet.com
(function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/fr_FR/all.js#appId=243265768935&xfbml=1"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook-jssdk'));