Depuis plus d'un demi-siècle, les ingénieurs en logiciel savent que des acteurs malveillants peuvent exploiter une catégorie de défauts logiciels appelés "vulnérabilités de sécurité de la mémoire" pour compromettre des applications et des systèmes. Au cours de cette période, les experts ont à maintes reprises mis en garde contre les problèmes liés aux failles de sécurité de la mémoire. Un code à mémoire non sécurisée a même entraîné une panne majeure de l'internet en 1988.Quelle est l'ampleur du problème de l'insécurité de la mémoire ? Dans un billet de blog, Microsoft indique que "~70 % des vulnérabilités auxquelles Microsoft attribue chaque année un CVE [Common Vulnerability and Exposure] continuent d'être des problèmes de sécurité de la mémoire". De même, Google indique que "le projet Chromium constate qu'environ 70 % de nos bogues de sécurité graves sont des problèmes de sécurité de la mémoire". Mozilla signale que dans une analyse des vulnérabilités de sécurité, "sur les 34 bogues critiques/élevés, 32 étaient liés à la mémoire".
Ces vulnérabilités ne sont pas théoriques. Les attaquants les utilisent pour commettre des attaques contre des personnes réelles. Par exemple, l'équipe Project Zero de Google a analysé les vulnérabilités qui ont été utilisées dans la nature par des attaquants avant d'être signalées aux fournisseurs de logiciels (également appelées "zero-day vulnerabilities"
. Elle indique que "sur les 58 [vulnérabilités de ce type] de l'année, 39, soit 67 %, étaient des vulnérabilités liées à la corruption de la mémoire". Citizen Lab a découvert des logiciels espions utilisés contre des organisations de la société civile qui exploitaient des failles dans la sécurité de la mémoire.Dans quel autre secteur le marché tolérerait-il pendant des décennies des dangers aussi graves et bien compris pour les utilisateurs des produits ?
Au fil des ans, les ingénieurs en logiciel ont inventé de nombreuses solutions intelligentes, mais finalement insuffisantes, pour atténuer cette catégorie de vulnérabilité, notamment des outils tels que la randomisation de la mémoire et les techniques de sandboxing qui réduisent l'impact, et des outils d'analyse statique et dynamique du code qui réduisent l'occurrence. En plus de ces outils, les organisations ont consacré beaucoup de temps et d'argent à la formation de leurs développeurs pour qu'ils évitent les opérations de mémoire dangereuses. Il existe également plusieurs efforts parallèles visant à améliorer la sécurité de la mémoire du code C/C++ existant. Malgré ces efforts (et les coûts associés en termes de complexité, de temps et d'argent), l'insécurité de la mémoire a été le type le plus courant de défaut de sécurité des logiciels pendant des décennies.
Il existe cependant quelques domaines que tout éditeur de logiciels devrait étudier. Tout d'abord, il existe des mesures prometteuses d'atténuation de la sécurité de la mémoire au niveau du matériel. Le projet de recherche CHERI (Capability Hardware Enhanced RISC Instructions) utilise des processeurs modifiés pour donner aux langages à mémoire non sécurisée comme C et C++ une protection contre de nombreuses vulnérabilités largement exploitées. Une autre technologie assistée par le matériel se présente sous la forme d'extensions de marquage de la mémoire (MTE) disponibles dans certains systèmes. Bien que certaines de ces mesures d'atténuation basées sur le matériel soient encore en train de passer de la recherche à l'expédition de produits, de nombreux observateurs pensent qu'elles deviendront des éléments importants d'une stratégie globale visant à éliminer les vulnérabilités liées à la sécurité de la mémoire.
Deuxièmement, les entreprises devraient se pencher sur les langages de programmation à sécurité mémoire. La plupart des langages de programmation modernes autres que C/C++ sont déjà sans danger pour la mémoire. Ces langages gèrent la mémoire de l'ordinateur de manière à ce que le programmeur ne puisse pas introduire de vulnérabilités en matière de sécurité de la mémoire. Contrairement à d'autres mesures d'atténuation disponibles qui nécessitent un entretien constant (sous la forme de développement de nouvelles défenses, d'analyse des vulnérabilités ou de travail humain) aucun travail ne doit être effectué une fois que le code est écrit dans un langage de programmation à mémoire sécurisée pour le maintenir à l'abri des failles de la mémoire.
Ce qui manquait jusqu'à il y a quelques années, c'était un langage aussi rapide que le C/C++ avec des garanties intégrées de sécurité de la mémoire. En 2006, un ingénieur logiciel de Mozilla a commencé à travailler sur un nouveau langage de programmation appelé Rust. La version 1.0 de Rust a été officiellement annoncée en 2015. Depuis, plusieurs grands éditeurs de logiciels ont commencé à l'utiliser dans leurs systèmes, notamment Amazon, Facebook, Google, Microsoft, Mozilla et bien d'autres. Il est également pris en charge dans le développement du noyau Linux.
Différents produits nécessiteront des stratégies d'investissement différentes pour atténuer les codes dangereux pour la mémoire. L'équilibre entre les mesures d'atténuation C/C++, les mesures d'atténuation matérielles et les langages de programmation sans risque pour la mémoire peut même varier entre les produits d'une même entreprise. Aucune approche ne résoudra tous les problèmes pour tous les produits. La seule chose que les fabricants de logiciels ne peuvent pas faire, c'est ignorer le problème. L'industrie du logiciel ne doit pas rester inactive pendant encore une décennie.
Le livre blanc "Secure by Design" de la CISA présente trois principes fondamentaux pour les fabricants de logiciels : s'approprier les résultats en matière de sécurité des clients, adopter une transparence radicale et diriger les transformations en matière de sécurité depuis le sommet de l'organisation. Les solutions au problème de l'insécurité de la mémoire intégreront ces trois principes.
La CISA invite les fabricants de logiciels à faire de la réduction et de l'élimination des vulnérabilités de la sécurité de la mémoire de leurs gammes de produits un objectif d'entreprise de premier plan. Pour démontrer cet engagement, les entreprises peuvent publier une "feuille de route sur la sécurité de la mémoire" qui comprend des informations sur la manière dont elles modifient leur cycle de développement logiciel (SDLC) pour atteindre cet objectif. Une feuille de route peut inclure des détails tels que la date à partir de laquelle elle construira de nouveaux produits ou composants dans un langage de programmation sans danger pour la mémoire et des plans pour soutenir les initiatives de sécurité de la mémoire des bibliothèques open source qui font partie de leur chaîne d'approvisionnement.
L'insécurité de la mémoire est un fléau pour l'industrie du logiciel depuis des décennies et continuera d'être une source majeure de vulnérabilités et de dommages dans le monde réel jusqu'à ce que les principaux dirigeants des fabricants de logiciels fassent les investissements appropriés et s'approprient les résultats de leurs clients en matière de sécurité. À l'occasion de la semaine nationale du codage, nous espérons que les participants de l'ensemble de l'industrie du logiciel travailleront ensemble pour créer des logiciels plus sûrs dès leur conception, et la sécurité de la mémoire est la clé pour atteindre cet objectif.
Et vous ?
Quel est votre avis sur la sécurité de la mémoire dans nos logiciels actuels ? Pensez-vous que l'utilisation d'un langage comme Rust soit la solution ?Voir aussi :
La NSA exhorte les organisations à passer à des langages de programmation sécurisés dans la gestion de la mémoire pour éliminer un vecteur d'attaque souvent exploité par les cybercriminels La NSA et la CISA des États-Unis publient un guide pour renforcer la sécurité des clusters Kubernetes, en vue d'aider les entreprises à rendre leurs infrastructures plus résilientes « Choisir Rust est opter pour une meilleure sécurisation des logiciels qu'avec le C, mais une efficacité énergétique et une performance d'exécution que seul le C offre », d'après l'équipe AWS 
