4 pièce(s) jointe(s)
Google rapporte une baisse des vulnérabilités liées à la sécurité de la mémoire sur Android grâce à Rust
Google fait état d'une baisse des vulnérabilités liées à la sécurité de la mémoire sur Android à mesure que l'utilisation de Rust augmente
elles seraient passées de 223 en 2019 à 85 en 2022
Dans une étude publiée jeudi, Google a déclaré que les vulnérabilités liées à la sécurité de la mémoire sur Android sont en constante baisse depuis la prise en charge de Rust par le projet Android Open Source Project (AOSP). Plus précisément, le nombre de vulnérabilités annuelles liées à la sécurité de la mémoire serait passé de 223 à 85 entre 2019 et 2022. Elles représentent désormais 35 % du total des vulnérabilités d'Android contre 76 % il y a quatre ans. En outre, Google a fait remarquer que "2022 est la première année où les vulnérabilités de sécurité de la mémoire ne représentent pas une majorité des vulnérabilités d'Android".
Impacts de la prise en charge de Rust pour le développement d'Android
« Depuis plus de dix ans, les vulnérabilités liées à la sécurité de la mémoire ont toujours représenté plus de 65 % des vulnérabilités dans l'ensemble des produits et de l'industrie. Sur Android, nous observons désormais quelque chose de différent : une baisse significative des vulnérabilités liées à la sécurité de la mémoire et une baisse associée de la gravité de nos vulnérabilités », note Google. L'étude a examiné les vulnérabilités signalées dans le bulletin de sécurité Android, qui comprend les vulnérabilités critiques/de haute gravité signalées par le biais de notre programme de récompense des vulnérabilités (VRP) et les vulnérabilités signalées en interne.
Jeffrey Vander Stoep de Google a rapporté que cet examen a révélé que le nombre de vulnérabilités de sécurité de la mémoire a considérablement diminué au cours des dernières années/versions. Comme le montre le graphique ci-dessous, de 2019 à 2022, le nombre annuel de vulnérabilités de sécurité de la mémoire serait passé de 223 à 85. Il note que cette baisse coïncide avec un changement dans l'utilisation des langages de programmation, qui délaissent les langages non sécurisés en matière de mémoire. Android 13 est la première version d'Android où la majorité du nouveau code ajouté à la version est dans un langage à mémoire sécurisée.
Comme la quantité de nouveau code non sécurisé par la mémoire entrant dans Android a diminué, le nombre de vulnérabilités de sécurité de la mémoire a également diminué. Selon l'étude, 2019 à 2022, il serait passé de 76 % à 35 % du total des vulnérabilités d'Android. C'est la première que les vulnérabilités de sécurité liées à la mémoire ne représentent pas la majorité des vulnérabilités d'Android. Rust représente 21 % de l'ensemble du nouveau code natif d'Android 13, y compris la pile Ultra-wideband (UWB), le DNS sur HTTP3, Keystore2, le framework de virtualisation d'Android (AVF) et "divers autres composants et leurs dépendances open source."
Google considère qu'il est significatif qu'il n'y ait eu aucune vulnérabilité de sécurité mémoire découverte dans le code Rust d'Android jusqu'à présent dans Android 12 et 13. « Bien qu'une corrélation ne signifie pas nécessairement un lien de causalité, il est intéressant de noter que le pourcentage de vulnérabilités causées par des problèmes de sécurité de la mémoire semble être en corrélation assez étroite avec le langage de développement utilisé pour le nouveau code. Bien sûr, il peut y avoir d'autres facteurs contributifs ou des explications alternatives », indique Stoep de Google dans un billet de blogue publié jeudi.
« La densité historique des vulnérabilités est supérieure à 1/kLOC (1 vulnérabilité par millier de lignes de code) dans de nombreux composants C/C++ d'Android (par exemple, médias, Bluetooth, NFC, etc.). 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. L'utilisation de Rust dans Android nous permet d'optimiser la sécurité et la santé du système avec moins de compromis », a déclaré Google. L'entreprise a mis en avant les gains de mémoire obtenus avec la nouvelle pile UWB et la nouvelle implémentation DNS-over-HTTP/3.
En outre, ce changement constitue une rupture majeure par rapport aux tendances observées dans l'ensemble de l'industrie. Elles persistent depuis plus d'une décennie (et probablement plus longtemps encore) malgré des investissements substantiels dans l'amélioration des langages à mémoire non sécurisée. Google a également évoqué dans son billet de blogue les vulnérabilités non liées à la sécurité de la mémoire, ainsi que ses projets. « Notre objectif n'est pas de convertir le C/C++ existant en Rust, mais plutôt de transférer le développement de nouveaux codes vers des langages à mémoire sécurisée au fil du temps », note Google.
Observations sur les vulnérabilités non liées à la sécurité de la mémoire
À ce stade, Google a annoncé que le nombre de vulnérabilités signalées dans le bulletin est resté relativement stable au cours des quatre dernières années, à environ 20 par mois, alors même que le nombre de vulnérabilités liées à la sécurité de la mémoire a considérablement diminué. Selon Google, les vulnérabilités de sécurité liées à la mémoire représentent de manière disproportionnée des vulnérabilités les plus graves. En 2022, bien qu'elles ne représentent que 36 % des vulnérabilités dans le bulletin de sécurité, les vulnérabilités de sécurité liées à la mémoire représentaient 86 % de nos vulnérabilités de sécurité de gravité critique.
De plus, les vulnérabilités de sécurité liées à la mémoire représentent 89 % de nos vulnérabilités exploitables à distance. Selon l'étude, au cours des dernières années, les vulnérabilités de sécurité de la mémoire ont représenté 78 % des vulnérabilités confirmées exploitées "dans la nature" sur les appareils Android. Le rapport estime que la diminution du nombre de vulnérabilités liées à la sécurité de la mémoire s'accompagne d'une diminution correspondante de la gravité des vulnérabilités : « avec la diminution des vulnérabilités les plus graves, nous constatons une augmentation des rapports concernant des types de vulnérabilités moins graves ».
Par exemple, environ 15 % des vulnérabilités en 2022 sont des vulnérabilités DoS (nécessitant une réinitialisation de l'appareil en usine). Cela représente une baisse du risque de sécurité. «Comme il est plus difficile de trouver et d'exploiter les vulnérabilités liées à la sécurité de la mémoire, les chercheurs en sécurité se concentrent sur d'autres types de vulnérabilités. Peut-être que le nombre total de vulnérabilités découvertes est principalement limité par le temps total que les chercheurs consacrent à leur découverte. Ou peut-être existe-t-il une autre explication que nous n'avons pas envisagée », a déclaré Google.
« Dans tous les cas, nous espérons que si notre communauté de chercheurs en vulnérabilités trouve moins de ces vulnérabilités puissantes et polyvalentes, il en va de même pour les adversaires », a ajouté l'entreprise. Par ailleurs, bien que la majorité du code existant dans Android soit en C/C++, la plupart des API d'Android sont implémentées en Java. Cela signifie que Java est représenté de manière disproportionnée dans la surface d'attaque d'Android accessible par les applications. Ainsi, la plupart de la surface d'attaque qui est accessible par les applications n'est pas sensible aux bogues de corruption de mémoire.
« Cela signifie également que nous nous attendons à ce que Java soit surreprésenté lorsque nous examinons les vulnérabilités non liées à la sécurité de la mémoire. Il est important de noter cependant que les types de vulnérabilités que nous observons en Java sont principalement des bogues logiques et généralement moins graves. À l'avenir, nous étudierons comment le système de types plus riche de Rust peut aider à prévenir les types courants de bogues logiques », a déclaré Google. Parlant de l'avenir, Google a déclaré que l'abandon du C/C++ est un défi, mais cela progresse. L'utilisation de Rust se développe sur la plateforme Android.
« Pour atteindre les objectifs d'amélioration de la sécurité, de la stabilité et de la qualité d'Android, nous devons être en mesure d'utiliser Rust partout dans la base de code où le code natif est nécessaire. Nous implémentons les HALs de l'espace utilisateur en Rust. Nous ajoutons le support de Rust dans les applications de confiance. Nous avons migré les microprogrammes des VM dans le cadre de la virtualisation d'Android vers Rust. Avec l'arrivée du support de Rust dans Linux 6.1, nous sommes impatients d'apporter la sécurité mémoire au noyau, en commençant par les pilotes du noyau », a déclaré Google.
« À mesure qu'Android passe de C/C++ à Java/Kotlin/Rust, nous nous attendons à ce que le nombre de vulnérabilités liées à la sécurité de la mémoire continue de diminuer. Vivement un avenir où les bogues de corruption de la mémoire sur Android seront rares », a conclu Google.
Source : Google
Et vous ?
:fleche: Que pensez-vous des conclusions de l'étude de Google ?
:fleche: Que pensez-vous de la prise en charge de Rust pour le développement d'Android ?
Voir aussi
:fleche: Google annonce la prise en charge du langage Rust pour le développement d'Android, l'intérêt est de résoudre les problèmes de sécurité de la mémoire
:fleche: Google soutient un projet Linux visant à rendre Android et Chrome OS plus difficiles à pirater, tout en militant pour l'utilisation de Rust dans le code du noyau
:fleche: Le langage de programmation Rust gagne en popularité parmi les développeurs et fait son entrée dans le top 20, selon Tiobe. Python, Java, C et C++ s'accaparent à eux seuls de 55% de parts de marché
:fleche: Rust est devenu si populaire qu'une équipe dédiée a été présentée pour la définition du style de codage Rust par défaut, afin que les développeurs se sentent le plus à l'aise possible
