Le long chemin à parcourir pour avoir une mémoire vive sûre

En novembre 2022, l’Agence nationale de la sécurité américaine a publié un communiqué sur la sécurité de la mémoire vive (RAM). Si vous lisez les autres communiqués que la NSA a publié à ce sujet, vous allez constater qu’ils se concentrent principalement sur le chiffrement des données, sur la protection de la boucle de production ou sur tout autre problème d’organisation. Il est assez inhabituel pour l’agence de s’adresser directement aux développeurs de programmes. Mais, puisqu’elle l’a fait, cela signifie qu’il s’agit de quelque chose d’important. En quelques mots, la NSA demande aux développeurs de programmes d’utiliser des langages de programmation dont l’architecture implique une meilleure sécurité lorsqu’il s’agit de travailler avec la mémoire vive. Ce qui signifie qu’ils ne doivent plus utiliser C et C++. Autrement, il est conseillé d’adopter certaines mesures pour tester les vulnérabilités des programmes et éviter qu’elles ne soient exploitées.

Ces indications sont évidentes pour les programmeurs et le communiqué de la NSA ne leur est pas directement adressé. Il concerne plutôt les membres de la direction ou des affaires. Le communiqué a été rédigé avec des termes que les entreprises peuvent comprendre. Tentons notre chance et analysons les arguments présentés dans ce communiqué sans être trop techniques.

La sécurité de la mémoire

Ouvrons notre dernier rapport sur l’évolution des menaces lors du 3^ème trimestre de 2022 et analysons les vulnérabilités les plus souvent utilisées pour lancer des attaques informatiques. Nous trouvons d’abord la vulnérabilité CVE-2018-0802, découverte en 2018, du composant Equation Editor de la suite bureautique Microsoft Office. Elle est due à un traitement incorrect des fichiers en mémoire et l’ouverture d’un document malveillant Microsoft Word peut provoquer l’exécution d’un code arbitraire. La vulnérabilité CVE-2022-2294, du composant WebRTC du navigateur Google Chrome, est particulièrement appréciée par les escrocs. Cette faille provoque l’exécution d’un code arbitraire à la suite d’un problème de dépassement de mémoire tampon. Une autre vulnérabilité, CVE-2022-2624, se trouve dans l’outil de visualisation de PDF de Chrome et peut également provoquer un dépassement de mémoire tampon.

Évidemment, certaines vulnérabilités ne sont pas dues à une mémoire vive non sécurisée, mais c’est le cas de beaucoup. Le communiqué de la NSA fait référence aux statistiques de Microsoft et explique que les erreurs de gestion de la mémoire sont à l’origine de 70 % des vulnérabilités découvertes.

Selon les statistiques de Microsoft, les deux tiers des vulnérabilités sont dus à des bugs de mémoire. Source.

Pourquoi ? Si le problème des fuites de mémoire est si grave, pourquoi n’arrivons-nous pas à nous organiser et à écrire un code qui n’est plus vulnérable ? L’origine du problème se trouve dans l’utilisation des langages de programmation C et C++. Leur architecture donne beaucoup de liberté aux programmeurs lorsqu’ils travaillent avec la mémoire vive. Pourtant, cette liberté s’accompagne de responsabilités. Les programmeurs C/C++ doivent mettre en place des mécanismes pour que l’écriture et la lecture des données soient sûres. D’autre part, des langages de programmation de haut niveau comme C#, Rust, Go et autres s’en occupent. Le fait est que, lorsque le code source du programme est compilé, les outils qui s’occupent de la sécurité de la mémoire doivent être automatiquement ajoutés afin que les programmeurs n’aient pas à s’en occuper. Rust utilise d’autres moyens afin d’améliorer la sécurité, comme la restriction d’un code potentiellement dangereux ou la compilation pendant l’affichage d’une erreur au programmeur.

Évidemment, il est impossible de tout simplement abandonner C/C++ puisque ces langages sont indispensables pour effectuer certaines tâches, comme lorsque le code est nécessaire pour un MCU ou tout autre appareil ayant des limites en termes de puissance informatique et de taille de la mémoire. D’autres aspects sont identiques et les langages de programmation de haut niveau peuvent donner lieu à des programmes voraces en ressources. Les statistiques relatives aux menaces courantes nous montrent que les attaques s’en prennent plus souvent aux programmes grand public (comme les navigateurs et les éditeurs de texte) qui s’exécutent sur des ordinateurs très puissants (par rapport au MCU, évidemment).

Changer le langage de programmation ne suffit pas

La NSA en a conscience. Un gigantesque logiciel de base de données écrit dans des langages de programmation non sécurisés ne peut pas être transféré dans un autre langage du jour au lendemain. Même si nous parlons d’écrire un logiciel de zéro, il y a certainement une équipe, une infrastructure et des méthodes de développement bien établies selon un langage de programmation spécifique.

À titre de comparaison, imaginez qu’on vous demande d’abandonner votre domicile parce qu’il a été construit il y a plusieurs années de cela. Vous savez que la structure est solide et que le logement ne va s’effondrer que s’il y a un tremblement de terre, d’autant que vous êtes habitué à vivre ici. L’équipe de développement de Google Chrome a publié un article qui stipule clairement qu’il est impossible de passer immédiatement à un langage de programmation (dans ce cas, Rust) où la sécurité fait partie de l’architecture. Ils pourront le faire à l’avenir. Ils ont besoin d’autres solutions pour le moment.

Ce même article des développeurs de Google Chrome explique pourquoi vous ne pouvez pas simplement modifier le code de sécurité C/C++. Ces langages de programmation n’ont pas été créés pour résoudre tous les problèmes de compilation en un seul coup. C’est pourquoi le communiqué de la NSA propose deux mesures comme alternative :

• Tester le code pour détecter d’éventuelles vulnérabilités avec des techniques d’analyse dynamiques et statiques ;
• Utiliser des fonctionnalités qui empêchent l’exploitation d’une erreur dans le code même si elle existe déjà.

Les défis de ce changement

Les experts techniques sont, dans l’ensemble, d’accord avec la NSA. Les experts ont diverses opinions quant à la façon dont ce changement aux langages de programmation de haut niveau doit se faire lorsque ce besoin est nécessaire, notamment pour des raisons de sécurité. Tout d’abord, il convient de comprendre que si ce changement se fait, il faudra compter plusieurs années. Ensuite, une telle évolution a un coût et certaines entreprises ne sont pas prêtes à l’assumer. Le problème de la mémoire non sécurisée avec des langages de programmation ayant un niveau d’abstraction bas est un problème généralisé. Il est nécessaire d’avoir une solution radicale, mais ne vous attendez pas à voir les développeurs programmer en C#, Java, Ruby, Rust ou Swift d’un jour à l’autre. C’est comme si vous demandiez à toute one ville ou à tout un pays de devenir… végétarien, ou de faire tout autre changement radical, du jour au lendemain.

Enfin, même si le problème de la mémoire non sécurisée est colossal, il est loin d’être le seul lorsqu’il s’agit de la sécurité d’un programme. Depuis que l’industrie informatique existe, c’est-à-dire plusieurs décennies, il n’a pas été possible de créer un système universel et complètement sûr pour toutes les tâches (sauf pour les solutions hautement spécialisées). D’un point de vue professionnel, il convient d’investir dans les nouvelles technologies (en développant les compétences nécessaires et en engageant des spécialistes qui ont de l’expérience) et de protéger au maximum les technologies existantes. Quant au développement de programmes, il pourrait s’agir de nouveaux langages de programmation et de nouvelles technologies pour tester le code existant. Quant aux autres entreprises, elles devraient investir dans de nouvelles technologies pour se protéger contre les attaques informatiques et tester constamment la force de l’infrastructure existante. En d’autres termes, une approche globale de la sécurité est optimale et le restera pendant longtemps.