{"id":19876,"date":"2022-12-16T12:14:32","date_gmt":"2022-12-16T10:14:32","guid":{"rendered":"https:\/\/www.kaspersky.fr\/blog\/?p=19876"},"modified":"2022-12-16T12:14:32","modified_gmt":"2022-12-16T10:14:32","slug":"the-long-road-to-memory-safety","status":"publish","type":"post","link":"https:\/\/www.kaspersky.fr\/blog\/the-long-road-to-memory-safety\/19876\/","title":{"rendered":"Le long chemin \u00e0 parcourir pour avoir une m\u00e9moire vive s\u00fbre"},"content":{"rendered":"

En novembre 2022, l\u2019Agence nationale de la s\u00e9curit\u00e9 am\u00e9ricaine a publi\u00e9 un communiqu\u00e9<\/a> sur la s\u00e9curit\u00e9 de la m\u00e9moire vive (RAM). Si vous lisez les autres communiqu\u00e9s<\/a> que la NSA a publi\u00e9 \u00e0 ce sujet, vous allez constater qu\u2019ils se concentrent principalement sur le chiffrement des donn\u00e9es, sur la protection de la boucle de production ou sur tout autre probl\u00e8me d\u2019organisation. Il est assez inhabituel pour l\u2019agence de s\u2019adresser directement aux d\u00e9veloppeurs de programmes. Mais, puisqu\u2019elle l\u2019a fait, cela signifie qu\u2019il s\u2019agit de quelque chose d\u2019important. En quelques mots, la NSA demande aux d\u00e9veloppeurs de programmes d\u2019utiliser des langages de programmation dont l\u2019architecture implique une meilleure s\u00e9curit\u00e9 lorsqu\u2019il s\u2019agit de travailler avec la m\u00e9moire vive. Ce qui signifie qu\u2019ils ne doivent plus utiliser C et C++. Autrement, il est conseill\u00e9 d\u2019adopter certaines mesures pour tester les vuln\u00e9rabilit\u00e9s des programmes et \u00e9viter qu\u2019elles ne soient exploit\u00e9es.<\/p>\n

Ces indications sont \u00e9videntes pour les programmeurs et le communiqu\u00e9 de la NSA ne leur est pas directement adress\u00e9. Il concerne plut\u00f4t les membres de la direction ou des affaires. Le communiqu\u00e9 a \u00e9t\u00e9 r\u00e9dig\u00e9 avec des termes que les entreprises peuvent comprendre. Tentons notre chance et analysons les arguments pr\u00e9sent\u00e9s dans ce communiqu\u00e9 sans \u00eatre trop techniques.<\/p>\n

La s\u00e9curit\u00e9 de la m\u00e9moire<\/h2>\n

Ouvrons notre dernier rapport<\/a> sur l\u2019\u00e9volution des menaces lors du 3\u00e8me<\/sup> trimestre de 2022 et analysons les vuln\u00e9rabilit\u00e9s les plus souvent utilis\u00e9es pour lancer des attaques informatiques. Nous trouvons d\u2019abord la vuln\u00e9rabilit\u00e9 CVE-2018-0802<\/a>, d\u00e9couverte en 2018, du composant Equation Editor de la suite bureautique Microsoft Office. Elle est due \u00e0 un traitement incorrect des fichiers en m\u00e9moire et l\u2019ouverture d\u2019un document malveillant Microsoft Word peut provoquer l\u2019ex\u00e9cution d\u2019un code arbitraire. La vuln\u00e9rabilit\u00e9 CVE-2022-2294<\/a>, du composant WebRTC du navigateur Google Chrome, est particuli\u00e8rement appr\u00e9ci\u00e9e par les escrocs. Cette faille provoque l\u2019ex\u00e9cution d\u2019un code arbitraire \u00e0 la suite d\u2019un probl\u00e8me de d\u00e9passement de m\u00e9moire\u00a0tampon<\/a>. Une autre vuln\u00e9rabilit\u00e9, CVE-2022-2624<\/a>, se trouve dans l\u2019outil de visualisation de PDF de Chrome et peut \u00e9galement provoquer un d\u00e9passement de m\u00e9moire\u00a0tampon.<\/p>\n

\u00c9videmment, certaines vuln\u00e9rabilit\u00e9s ne sont pas dues \u00e0 une m\u00e9moire vive non s\u00e9curis\u00e9e, mais c\u2019est le cas de beaucoup. Le communiqu\u00e9 de la NSA fait r\u00e9f\u00e9rence aux statistiques<\/a> de Microsoft et explique que les erreurs de gestion de la m\u00e9moire sont \u00e0 l\u2019origine de 70 % des vuln\u00e9rabilit\u00e9s d\u00e9couvertes.<\/p>\n

Selon les statistiques de Microsoft, les deux tiers des vuln\u00e9rabilit\u00e9s sont dus \u00e0 des bugs de m\u00e9moire. <a href=\"https:\/\/github.com\/Microsoft\/MSRC-Security-Research\/blob\/master\/presentations\/2019_02_BlueHatIL\/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf\" target=\"_blank\">Source<\/a>.

Selon les statistiques de Microsoft, les deux tiers des vuln\u00e9rabilit\u00e9s sont dus \u00e0 des bugs de m\u00e9moire. Source<\/a>.<\/p><\/div>\n

\u00a0<\/p>\n

Pourquoi\u00a0? Si le probl\u00e8me des fuites de m\u00e9moire est si grave, pourquoi n\u2019arrivons-nous pas \u00e0 nous organiser et \u00e0 \u00e9crire un code qui n\u2019est plus vuln\u00e9rable\u00a0? L\u2019origine du probl\u00e8me se trouve dans l\u2019utilisation des langages de programmation C et C++. Leur architecture donne beaucoup de libert\u00e9 aux programmeurs lorsqu\u2019ils travaillent avec la m\u00e9moire vive. Pourtant, cette libert\u00e9 s\u2019accompagne de responsabilit\u00e9s. Les programmeurs C\/C++ doivent mettre en place des m\u00e9canismes pour que l\u2019\u00e9criture et la lecture des donn\u00e9es soient s\u00fbres. D\u2019autre part, des langages de programmation de haut niveau comme C#, Rust, Go et autres s\u2019en occupent. Le fait est que, lorsque le code source du programme est compil\u00e9, les outils qui s\u2019occupent de la s\u00e9curit\u00e9 de la m\u00e9moire doivent \u00eatre automatiquement ajout\u00e9s afin que les programmeurs n\u2019aient pas \u00e0 s\u2019en occuper. Rust utilise d\u2019autres moyens afin d\u2019am\u00e9liorer la s\u00e9curit\u00e9, comme la restriction d\u2019un code potentiellement dangereux ou la compilation pendant l\u2019affichage d\u2019une erreur au programmeur.<\/p>\n

\u00c9videmment, il est impossible de tout simplement abandonner C\/C++ puisque ces langages sont indispensables pour effectuer certaines t\u00e2ches, comme lorsque le code est n\u00e9cessaire pour un MCU ou tout autre appareil ayant des limites en termes de puissance informatique et de taille de la m\u00e9moire. D\u2019autres aspects sont identiques et les langages de programmation de haut niveau peuvent donner lieu \u00e0 des programmes voraces en ressources. Les statistiques relatives aux menaces courantes nous montrent que les attaques s\u2019en prennent plus souvent aux programmes grand public (comme les navigateurs et les \u00e9diteurs de texte) qui s\u2019ex\u00e9cutent sur des ordinateurs tr\u00e8s puissants (par rapport au MCU, \u00e9videmment).<\/p>\n

Changer le langage de programmation ne suffit pas<\/h2>\n

La NSA en a conscience. Un gigantesque logiciel de base de donn\u00e9es \u00e9crit dans des langages de programmation non s\u00e9curis\u00e9s ne peut pas \u00eatre transf\u00e9r\u00e9 dans un autre langage du jour au lendemain. M\u00eame si nous parlons d\u2019\u00e9crire un logiciel de z\u00e9ro, il y a certainement une \u00e9quipe, une infrastructure et des m\u00e9thodes de d\u00e9veloppement bien \u00e9tablies selon un langage de programmation sp\u00e9cifique.<\/p>\n

\u00c0 titre de comparaison, imaginez qu\u2019on vous demande d\u2019abandonner votre domicile parce qu\u2019il a \u00e9t\u00e9 construit il y a plusieurs ann\u00e9es de cela. Vous savez que la structure est solide et que le logement ne va s\u2019effondrer que s\u2019il y a un tremblement de terre, d\u2019autant que vous \u00eates habitu\u00e9 \u00e0 vivre ici. L\u2019\u00e9quipe de d\u00e9veloppement de Google Chrome a publi\u00e9 un article<\/a> qui stipule clairement qu\u2019il est impossible de passer imm\u00e9diatement \u00e0 un langage de programmation (dans ce cas, Rust) o\u00f9 la s\u00e9curit\u00e9 fait partie de l\u2019architecture. Ils pourront le faire \u00e0 l\u2019avenir. Ils ont besoin d\u2019autres solutions pour le moment.<\/p>\n

Ce m\u00eame article des d\u00e9veloppeurs de Google Chrome explique pourquoi vous ne pouvez pas simplement modifier le code de s\u00e9curit\u00e9 C\/C++. Ces langages de programmation n\u2019ont pas \u00e9t\u00e9 cr\u00e9\u00e9s pour r\u00e9soudre tous les probl\u00e8mes de compilation en un seul coup. C\u2019est pourquoi le communiqu\u00e9 de la NSA propose deux mesures comme alternative :<\/p>\n