Les analystes accueillent favorablement les conseils de la NSA aux développeurs pour adopter des langages sécurisés pour la mémoire

Les analystes de la sécurité ont accueilli la semaine dernière une recommandation de la National Security Agency (NSA) des États-Unis demandant aux développeurs de logiciels d'envisager d'adopter des langages tels que C #, Go, Java, Ruby, Rust et Swift pour réduire les vulnérabilités liées à la mémoire dans le code.

La NSA les a décrits comme des langages « sans danger pour la mémoire » qui gèrent automatiquement la mémoire dans le cadre du langage informatique. Ils ne comptent pas sur le programmeur pour implémenter la sécurité de la mémoire et utilisent à la place une combinaison de vérifications du temps de compilation et d'exécution pour se protéger contre les erreurs de mémoire, a déclaré la NSA.

Le cas des langages sécurisés pour la mémoire

L'avis quelque peu inhabituel de la NSA du 10 novembre indiquait des langages largement utilisés tels que C et C ++ comme dépendre trop des programmeurs de ne pas commettre d'erreurs liées à la mémoire, ce qui, a-t-il noté, continue d'être la principale cause de vulnérabilités de sécurité dans les logiciels. Études antérieures—une par Microsoft en 2019 et un autre de Google en 2020 liés à son navigateur Chrome - par exemple, les deux ont trouvé que 70% des vulnérabilités étaient des problèmes de sécurité de la mémoire, a déclaré la NSA.

"Les langages couramment utilisés, tels que C et C++, offrent beaucoup de liberté et de flexibilité dans la gestion de la mémoire tout en s'appuyant fortement sur le programmeur pour effectuer les vérifications nécessaires sur les références mémoire", a déclaré la NSA. Cela se traduit souvent par des vulnérabilités exploitables liées à de simples erreurs telles que des erreurs de dépassement de mémoire tampon, des problèmes d'allocation de mémoire et des conditions de concurrence.

C #, Go, Java, Ruby, Rust, Swift et d'autres langages sécurisés pour la mémoire n'éliminent pas complètement le risque de ces problèmes, a déclaré la NSA dans son avis. La plupart d'entre eux, par exemple, incluent au moins quelques classes ou fonctions qui ne sont pas sûres pour la mémoire et permettent au programmeur d'effectuer une fonction de gestion de la mémoire potentiellement dangereuse. Les langages sécurisés pour la mémoire peuvent parfois également inclure des bibliothèques écrites dans des langages contenant des fonctions de mémoire potentiellement dangereuses.

Mais même avec ces mises en garde, les langages sécurisés en mémoire peut aider à réduire les vulnérabilités des logiciels résultant d'une gestion de la mémoire médiocre et négligente, a déclaré la NSA.

Tim Mackey, stratège principal en matière de sécurité au Synopsys Cybersecurity Research Center, se félicite de la recommandation de la NSA. L'utilisation de langages sécurisés en mémoire devrait, en fait, être la valeur par défaut pour la plupart des applications, dit-il. "Pour des raisons pratiques, compter sur les développeurs pour se concentrer sur les problèmes de gestion de la mémoire au lieu de programmer de nouvelles fonctionnalités intéressantes représente une taxe sur l'innovation", dit-il. Avec les langages de programmation sécurisés en mémoire et les frameworks associés, ce sont les auteurs du langage qui assurent une bonne gestion de la mémoire et non les développeurs d'applications, explique Mackey.

Le quart de travail peut être difficile

Le passage d'un environnement de développement logiciel mature d'un langage à un autre peut être difficile, a reconnu la NSA. Les programmeurs devront apprendre le nouveau langage, et il y aura probablement des erreurs de débutant et des problèmes d'efficacité au cours du processus. L'étendue de la sécurité de la mémoire disponible peut également varier considérablement selon la langue. Certains peuvent n'offrir qu'une sécurité minimale de la mémoire, tandis que d'autres offrent des protections considérables concernant l'accès, l'allocation et la gestion de la mémoire.

En outre, les organisations devront réfléchir à l'ampleur du compromis qu'elles sont prêtes à faire entre la sécurité et les performances. "La sécurité de la mémoire peut être coûteuse en termes de performances et de flexibilité", a averti la NSA. "Pour les langages avec un niveau extrême de protection inhérente, un travail considérable peut être nécessaire pour simplement faire compiler le programme en raison des vérifications et des protections."

Il y a une myriade de variables en jeu lorsque l'on essaie de porter une application d'un langage à un autre, explique Mike Parkin, ingénieur technique senior chez Vulcan Cyber. "Dans le meilleur des cas, le changement est simple et une organisation peut l'accomplir relativement sans douleur", déclare Parkin. "Dans d'autres, l'application s'appuie sur des fonctionnalités qui sont triviales dans la langue d'origine mais nécessitent un développement important et coûteux pour être recréées dans la nouvelle."

L'utilisation de langages sécurisés en mémoire ne remplace pas non plus la nécessité de tests logiciels appropriés, prévient Mackey. Ce n'est pas parce qu'un langage de programmation est sécurisé en mémoire que le langage ou les applications développées dessus sont exempts de bogues.

Passer d'un langage de programmation à un autre est une proposition risquée à moins que vous n'ayez du personnel qui comprenne déjà à la fois l'ancien langage et le nouveau, dit Mackey. « Une telle migration est mieux effectuée lorsque l'application passe par une mise à jour de version majeure ; sinon, il est possible que des bogues involontaires soient introduits dans le cadre de l'effort de migration », note-t-il.

Mackey suggère aux organisations d'envisager d'utiliser des microservices lorsqu'il s'agit de changer de langue. "Avec une architecture de microservices, l'application est décomposée en un ensemble de services conteneurisés", explique Mackey. "Du point de vue d'un langage de programmation, rien n'exige en soi que chaque microservice soit programmé dans le même langage de programmation que les autres services au sein de la même application."

Faire le déménagement

Des données récentes de Statista montrent que de nombreux développeurs utilisent déjà langues considérées comme sûres pour la mémoire. Près des deux tiers (65.6 %), par exemple, utilisent JavaScript, près de la moitié (48.06 %) utilisent Python, un tiers utilisent Java et près de 28 % utilisent C#. Dans le même temps, une proportion importante utilise encore des langages non sécurisés tels que C++ (22.5 %) et C (19.25 %).

"Je pense que de nombreuses organisations ont déjà abandonné C/C++ non seulement pour des raisons de sécurité de la mémoire, mais aussi pour la facilité globale de développement et de maintenance", déclare Johannes Ullrich, doyen de la recherche au SANS Technology Institute. "Mais il y aura toujours des bases de code héritées qui devront être maintenues pendant de nombreuses années à venir."

L'avis de la NSA offrait peu d'informations sur ce qui aurait pu motiver sa recommandation à ce stade. Mais John Bambenek, principal chasseur de menaces chez Netenrich, conseille aux organisations de ne pas l'ignorer. "Les vulnérabilités et les attaques de mémoire sont omniprésentes depuis les années 1990, donc en général, c'est un bon conseil", dit-il. "Cela étant dit, comme cela vient de la NSA, je pense que ce conseil devrait prendre une urgence supplémentaire et est motivé par les connaissances qu'ils ont et que nous n'avons pas."