La National Security Agency (NSA) a publié des conseils pour aider les développeurs et les opérateurs de logiciels à prévenir et à atténuer les problèmes de sécurité de la mémoire logicielle, qui représentent une grande partie des vulnérabilités exploitables. La fiche d'information sur la cybersécurité « Sécurité de la mémoire logicielle » souligne comment les cyberacteurs malveillants peuvent exploiter les problèmes de mauvaise gestion de la mémoire pour accéder à des informations sensibles, promulguer l'exécution de code non autorisé et causer d'autres impacts négatifs.« Les problèmes de gestion de la mémoire sont exploités depuis des décennies et sont encore trop courants aujourd'hui », a déclaré Neal Ziring, directeur technique de la cybersécurité. « Nous devons utiliser systématiquement des langages sécurisés pour la mémoire et d'autres protections lors du développement de logiciels afin d'éliminer ces faiblesses des cyberacteurs malveillants ».
La société moderne s'appuie fortement sur l'automatisation basée sur les logiciels, faisant implicitement confiance aux développeurs pour écrire des logiciels qui fonctionnent de la manière attendue et ne peuvent pas être compromis à des fins malveillantes. Alors que les développeurs effectuent souvent des tests rigoureux pour préparer la logique des logiciels à des conditions surprenantes, les vulnérabilités logicielles exploitables sont encore souvent basées sur des problèmes de mémoire. Les exemples incluent le débordement d'une mémoire tampon et l'exploitation des problèmes liés à la façon dont le logiciel alloue et désalloue la mémoire.
Microsoft a révélé lors d'une conférence en 2019 que, de 2006 à 2018, 70 % de leurs vulnérabilités étaient dues à des problèmes de sécurité de la mémoire. Google a également trouvé un pourcentage similaire de vulnérabilités de sécurité de la mémoire sur plusieurs années dans Chrome. Les cyber-acteurs malveillants peuvent exploiter ces vulnérabilités pour l'exécution de code à distance ou d'autres effets indésirables, qui peuvent souvent compromettre un appareil et être la première étape des intrusions réseau à grande échelle. Les langages couramment utilisés, tels que C et C++, offrent une grande liberté et une grande flexibilité dans la gestion de la mémoire tout en s'appuyant fortement sur le développeur pour effectuer les vérifications nécessaires sur les références mémoire.
De simples erreurs peuvent conduire à des vulnérabilités exploitables basées sur la mémoire. Les outils d'analyse logicielle peuvent détecter de nombreux cas de problèmes de gestion de la mémoire et les options d'environnement d'exploitation peuvent également fournir une certaine protection, mais les protections inhérentes offertes par les langages logiciels sécurisés pour la mémoire peuvent prévenir ou atténuer la plupart des problèmes de gestion de la mémoire.
La NSA recommande d'utiliser un langage sécurisé pour la mémoire lorsque cela est possible. Bien que l'utilisation de protections supplémentaires pour les langages non sécurisés pour la mémoire et l'utilisation de langages sécurisés pour la mémoire n'offrent pas une protection absolue contre les problèmes de mémoire exploitables, elles offrent une protection considérable.
Par conséquent, la communauté logicielle globale du secteur privé, du milieu universitaire et du gouvernement américain a lancé des initiatives visant à orienter la culture du développement logiciel vers l'utilisation de langages sécurisés dans la gestion de la mémoire.
Le problème de la sécurité de la mémoire
La façon dont un programme logiciel gère la mémoire est essentielle pour prévenir de nombreuses vulnérabilités et garantir la robustesse d'un programme. L'exploitation d'une gestion de la mémoire médiocre ou négligente peut permettre à un cyberacteur malveillant d'accomplir des actes néfastes, tels que planter le programme à volonté ou modifier les instructions du programme en cours d'exécution pour faire ce que l'acteur désire. Même des problèmes inexploitables avec la gestion de la mémoire peuvent entraîner des résultats de programme incorrects, une dégradation des performances du programme au fil du temps ou des plantages de programme apparemment aléatoires.
La sécurité de la mémoire est une vaste catégorie de problèmes liés à la façon dont un programme gère la mémoire. Un problème courant est appelé « débordement de tampon », où les données sont accessibles en dehors des limites d'un tableau. D'autres problèmes courants concernent l'allocation de mémoire. Les langages peuvent allouer de nouveaux emplacements de mémoire pendant l'exécution d'un programme, puis désallouer la mémoire, également appelée libération ou libération de la mémoire, plus tard lorsque la mémoire n'est plus nécessaire. Mais si cela n'est pas fait avec soin par le développeur, de la nouvelle mémoire peut être allouée encore et encore au fur et à mesure que le programme s'exécute. Par conséquent, la mémoire n'est pas toujours libérée lorsqu'elle n'est plus nécessaire, ce qui entraîne une fuite de mémoire qui pourrait entraîner le programme à manquer de mémoire disponible.
En raison d'erreurs logiques, les programmes peuvent également tenter d'utiliser la mémoire qui a été libérée, ou même de libérer de la mémoire qui a déjà été libérée. Un autre problème peut survenir lorsque les langages autorisent l'utilisation d'une variable qui n'a pas été initialisée, ce qui fait que la variable utilise la valeur précédemment définie à cet emplacement en mémoire. Enfin, un autre problème difficile est appelé une condition de concurrence. Ce problème peut se produire lorsque les résultats d'un programme dépendent de l'ordre de fonctionnement de deux parties du programme accédant aux mêmes données. Tous ces problèmes de mémoire sont des occurrences beaucoup trop courantes.
En exploitant ces types de problèmes de mémoire, les acteurs malveillants, qui ne sont pas liés par les attentes normales d'utilisation du logiciel, peuvent découvrir qu'ils peuvent entrer des entrées inhabituelles dans le programme, provoquant l'accès, l'écriture, l'allocation ou la désallocation de la mémoire de manière inattendue. Dans certains cas, un acteur malveillant peut exploiter ces erreurs de gestion de la mémoire pour accéder à des informations sensibles, exécuter du code non autorisé ou provoquer d'autres impacts négatifs. Puisqu'il peut falloir beaucoup d'expérimentation avec des entrées inhabituelles pour en trouver une qui provoque une réponse inattendue, les acteurs peuvent utiliser une technique appelée "fuzzing" pour créer de manière aléatoire ou intelligente une multitude de valeurs d'entrée dans le programme jusqu'à ce qu'on en trouve une qui provoque le plantage du programme.
Les progrès des outils et des techniques de fuzzing ont facilité la recherche d'entrées problématiques pour les acteurs malveillants ces dernières années. Une fois qu'un acteur découvre qu'il peut faire planter le programme avec une entrée particulière, il examine le code et travaille pour déterminer ce qu'une entrée spécialement conçue pourrait faire. Dans le pire des cas, une telle entrée pourrait permettre à l'acteur de prendre le contrôle du système sur lequel le programme s'exécute.
Langages sécurisés dans la gestion de la mémoire
L'utilisation d'un langage sécurisé pour la mémoire peut aider à empêcher les programmeurs d'introduire certains types de problèmes liés à la mémoire. La mémoire est gérée automatiquement dans le cadre du langage informatique ; il ne repose pas sur l'ajout de code par le programmeur pour implémenter des protections de mémoire. Le langage institue des protections automatiques en utilisant une combinaison de vérifications au moment de la compilation et de l'exécution. Ces fonctionnalités inhérentes au langage protègent le programmeur contre l'introduction involontaire d'erreurs de gestion de la mémoire. C#, Go, Java, Ruby, Rust et Swift sont des exemples de langage sécurisé pour la mémoire.
Même avec un langage sécurisé pour la mémoire, la gestion de la mémoire n'est pas entièrement sécurisée pour la mémoire. La plupart des langages de mémoire sécurisés reconnaissent que les logiciels doivent parfois exécuter une fonction de gestion de mémoire non sécurisée pour accomplir certaines tâches. En conséquence, des classes ou des fonctions sont disponibles qui sont reconnues comme non sécurisées pour la mémoire et permettent au développeur d'effectuer une tâche de gestion de la mémoire potentiellement dangereuse. Certains langages exigent que tout ce qui n'est pas sûr en mémoire soit explicitement annoté comme tel pour que le développeur et tous les réviseurs du programme sachent qu'il n'est pas sûr. Les langages sécurisés pour la mémoire peuvent également utiliser des bibliothèques écrites dans des langages non sécurisés pour la mémoire et peuvent donc contenir des fonctionnalités de mémoire non sécurisées. Bien que ces façons d'inclure la mémoire ne soient pas sûres et subvertissent la sécurité inhérente à la mémoire, elles aident à localiser où des problèmes de mémoire pourraient exister, permettant un examen plus approfondi de ces sections de code.
Les langages varient dans leur degré de sécurité de la mémoire institué par des protections et des atténuations inhérentes. Certains langages n'offrent qu'une sécurité de mémoire relativement minimale alors que certains langages sont très stricts et offrent des protections considérables en contrôlant la manière dont la mémoire est allouée, accessible et gérée. Pour les langages avec un niveau extrême de protection inhérente, un travail considérable peut être nécessaire pour obtenir simplement le programme à compiler en raison des vérifications et des protections.
La sécurité de la mémoire peut être coûteuse en matière de performances et de flexibilité. La plupart des langages mémoire sécurisés nécessitent une sorte de récupération de place pour récupérer la mémoire qui a été allouée, mais qui n'est plus nécessaire au programme. Il existe également une surcharge de performances considérable associée à la vérification des limites de chaque accès à la baie qui pourrait potentiellement se trouver en dehors de la baie.
Alternativement, un impact similaire sur les performances peut exister dans un langage non sécurisé en mémoire en raison des vérifications qu'un développeur ajoute au programme pour effectuer la vérification des limites et d'autres protections de gestion de la mémoire. Les coûts supplémentaires liés à l'utilisation de langages non sécurisés pour la mémoire incluent une corruption de mémoire difficile à diagnostiquer et des plantages occasionnels des programmes ainsi que de potentielles exploitations des vulnérabilités d'accès à la mémoire. Il n'est pas anodin de faire passer une infrastructure de développement logiciel mature d'un langage informatique à un autre. Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage.
Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera.
Source : NSA
Et vous ?
Que pensez-vous des conseils de la NSA ? Y en a-t-il que vous appliquez déjà ? Que pensez-vous du fait que l'agence préconise l'utilisation des langages de programmation sécurisés pour la mémoire comme C#, Go, Java, Ruby, Rust et Swift ? « Les développeurs qualifiés doivent être formés dans un nouveau langage et il y a un coup d'efficacité lors de l'utilisation d'un nouveau langage. Les développeurs doivent endurer une courbe d'apprentissage et se frayer un chemin à travers toutes les erreurs de « débutant ». Alors qu'une autre approche consiste à embaucher des développeurs compétents dans un langage sécurisé pour la mémoire, ils auront eux aussi leur propre courbe d'apprentissage pour comprendre la base de code existante et le domaine dans lequel le logiciel fonctionnera ». Qu'en pensez-vous ? Êtes-vous d'accord avec l'agence ? 
Envoyé par Padget
