Dans un livre blanc, Google partage son point de vue sur la sécurité de la mémoire. Voici les raisons pour lesquelles Google publie ce livre blanc.Le projet zéro de Google indique que les vulnérabilités liées à la sécurité de la mémoire - défauts de sécurité causés par de subtiles erreurs de codage liées à la manière dont un programme accède à la mémoire - ont été "la norme pour attaquer les logiciels au cours des dernières décennies et c'est toujours la manière dont les attaquants réussissent". Leur analyse montre que deux tiers des exploits "0-day" détectés dans la nature utilisent des vulnérabilités liées à la corruption de la mémoire. Malgré des investissements substantiels pour améliorer les langages peu sûrs pour la mémoire, ces vulnérabilités continuent de figurer en tête des classes de vulnérabilités les plus couramment exploitées.
Dans ce document, Google examine les données, les défis liés à la sécurité de la mémoire, et discute des approches possibles pour atteindre la sécurité de la mémoire et leurs compromis. Elle y souligne également son engagement à mettre en œuvre plusieurs des solutions décrites dans le livre blanc, tout récemment avec une subvention de 1 000 000 dollars à la Rust Foundation, faisant ainsi progresser le développement d'un écosystème robuste de sécurité de la mémoire.
Pourquoi Google publie ce livre blanc maintenant ?
L'année 2022 a marqué le 50e anniversaire des vulnérabilités en matière de sécurité de la mémoire. Depuis lors, les risques liés à la sécurité de la mémoire sont devenus plus évidents. Comme d'autres, les données et recherches internes de Google sur les vulnérabilités montrent que les bogues liés à la sécurité de la mémoire sont très répandus et constituent l'une des principales causes de vulnérabilités dans les bases de code non sécurisées en termes de mémoire. Ces vulnérabilités mettent en danger les utilisateurs finaux, l'industrie et la société dans son ensemble. Google est encouragé par le fait que les gouvernements prennent également ce problème au sérieux, comme l'a montré la publication d'un document sur le sujet la semaine dernière par l'Office of the National Cyber Director (bureau du directeur national du cyberespace) des États-Unis.
Google :
En partageant nos idées et nos expériences, nous espérons inciter l'ensemble de la communauté et de l'industrie à adopter des pratiques et des technologies sans danger pour la mémoire, ce qui, en fin de compte, rendra la technologie plus sûre.
En partageant nos idées et nos expériences, nous espérons inciter l'ensemble de la communauté et de l'industrie à adopter des pratiques et des technologies sans danger pour la mémoire, ce qui, en fin de compte, rendra la technologie plus sûre.
Le point de vue de Google
Chez Google, ils ont des dizaines d'années d'expérience dans la résolution, à grande échelle, de grandes catégories de vulnérabilités qui étaient autrefois aussi répandues que les problèmes de sécurité de la mémoire. Leur approche, qu'ils appellent "Safe Coding", traite les constructions de codage sujettes à la vulnérabilité comme des dangers (c'est-à-dire indépendamment et en plus de la vulnérabilité qu'elles peuvent causer), et est centrée sur l'assurance que les développeurs ne rencontrent pas de tels dangers lors de leurs pratiques de codage régulières.
Sur la base de cette expérience, ils pensent qu'une sécurité élevée de la mémoire ne peut être obtenue que par une approche de conception sécurisée centrée sur l'adoption complète de langages offrant des garanties rigoureuses en matière de sécurité de la mémoire. Par conséquent, ils envisagent une transition progressive vers des langages à sécurité mémoire tels que Java, Go et Rust.
Au cours des dernières décennies, outre les vastes bases de code à mémoire sécurisée de Java et Go, Google a développé et accumulé des centaines de millions de lignes de code C++ qui sont utilisées activement et font l'objet d'un développement actif et continu. Cette très grande base de code existante pose des problèmes importants pour la transition vers la sécurité de la mémoire.
Google :
Nous ne voyons pas de voie réaliste pour une évolution du C++ vers un langage offrant des garanties rigoureuses de sécurité de la mémoire, y compris la sécurité temporelle. Une réécriture à grande échelle de tout le code C++ existant dans un langage différent, sûr pour la mémoire, semble très difficile et restera probablement impraticable.
Nous ne voyons pas de voie réaliste pour une évolution du C++ vers un langage offrant des garanties rigoureuses de sécurité de la mémoire, y compris la sécurité temporelle. Une réécriture à grande échelle de tout le code C++ existant dans un langage différent, sûr pour la mémoire, semble très difficile et restera probablement impraticable.
Les investissements de Google dans les langages à mémoire sécurisée
Google :
Nous investissons activement dans de nombreuses solutions décrites dans notre livre blanc et dans notre réponse à la demande de renseignements du gouvernement fédéral américain sur la sécurité des logiciels open source.
Nous investissons activement dans de nombreuses solutions décrites dans notre livre blanc et dans notre réponse à la demande de renseignements du gouvernement fédéral américain sur la sécurité des logiciels open source.
- Android a écrit plusieurs composants en Rust au cours des dernières années, ce qui a permis d'améliorer considérablement la sécurité. Dans le module UWB (Ultra-wideband) d'Android, cela a permis d'améliorer la sécurité du module tout en réduisant l'utilisation de la mémoire et les appels interprocéduraux.
- Chrome a commencé à livrer certaines fonctionnalités en Rust ; dans un cas, Chrome a pu sortir son générateur de code QR d'une sandbox en adoptant une nouvelle bibliothèque à mémoire sécurisée écrite en Rust, ce qui a permis d'améliorer à la fois la sécurité et les performances.
- Google a récemment annoncé l'octroi d'une subvention d'un million de dollars à la fondation Rust afin d'améliorer l'interopérabilité avec le code C++. Cela facilitera l'adoption progressive de Rust dans les bases de code existantes où la mémoire n'est pas sûre, ce qui sera essentiel pour permettre à un plus grand nombre de nouveaux développements de se produire dans un langage à mémoire sûre. Dans le même ordre d'idées, nous nous efforçons également de résoudre les attaques inter-langues qui peuvent se produire lorsque l'on mélange Rust et C++ dans le même binaire.
- Google investit dans la construction d'un écosystème open-source à mémoire sécurisée par l'intermédiaire du GISR Prossimo et du projet Alpha-Omega de l'OpenSSF. En 2021, nous avons financé les efforts visant à intégrer Rust au noyau Linux, ce qui nous permet désormais d'écrire des pilotes à mémoire sécurisée. Ce financement est également destiné à fournir des alternatives ou des mises à jour de bibliothèques open-source clés dans un langage à mémoire sécurisée, comme la fourniture d'une implémentation TLS à mémoire sécurisée.
Source : Sécuriser par la conception : compléter la transition vers des langages à mémoire sûre par des améliorations de la sécurité du code C++ existant, selon Google
Et vous ?
Pensez-vous que cet avis de Google est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
La Maison Blanche invite les développeurs à abandonner le C et le C++ pour passer à des langages comme le Rust, jugés supérieurs pour sécuriser les espaces mémoire des logiciels Les futurs logiciels devraient être sûrs pour la mémoire, les leaders de l'industrie soutiennent l'appel de la Maison Blanche à s'attaquer à la cause profonde de la plupart des pires cyber-attaques 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 
Envoyé par commandantFred
