CISA: La plupart des projets open source critiques n’utilisent pas de code sécurisé en mémoire

Le Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis a publié une étude portant sur 172 projets open source clés et leur vulnérabilité aux défauts de mémoire.

Le rapport, cosigné par CISA, le Federal Bureau of Investigation (FBI), ainsi que des organisations australiennes (ASD, ACSC) et canadiennes (CCCS), fait suite au ” publié en décembre 2023, visant à sensibiliser à l’importance du code sécurisé en mémoire.

Sécurité de la mémoire

Les langages de programmation sécurisés en mémoire sont conçus pour prévenir les erreurs courantes liées à la mémoire telles que les débordements de tampon, les libérations après utilisation et autres types de corruption de mémoire.

Ils parviennent à cela en gérant automatiquement la mémoire au lieu de s’appuyer sur le programmeur pour mettre en œuvre des mécanismes sûrs d’allocation et de libération de mémoire.

Un exemple moderne d’un système de langage sûr est le vérificateur de propriété de Rust, qui élimine les courses de données. D’autres langages comme Golang, Java, C# et Python gèrent la mémoire via la collecte des déchets, récupérant automatiquement la mémoire libérée pour prévenir les exploitations.

Les langages non sécurisés en mémoire sont ceux qui ne fournissent pas de mécanismes de gestion de mémoire intégrés, chargeant le développeur de cette responsabilité et augmentant la probabilité d’erreurs. Des exemples de tels cas sont C, C++, Objective-C, Assembly, Cython et D.

Code open source largement utilisé non sécurisé

Le rapport présente une étude examinant 172 projets open source largement déployés, constatant que plus de la moitié contiennent du code non sécurisé en mémoire.

Les principales conclusions présentées dans le rapport sont résumées comme suit :

• 52 % des projets open source critiques analysés contiennent du code écrit dans des langages non sécurisés en mémoire.
• 55 % du total des lignes de code (LoC) de ces projets sont écrites dans des langages non sécurisés en mémoire.
• Les plus grands projets sont disproportionnellement écrits dans des langages non sécurisés en mémoire.
• Parmi les dix plus grands projets en termes de LoC totales, chacun a une proportion de LoC non sécurisées en mémoire supérieure à 26 %.
• La proportion médiane de LoC non sécurisées en mémoire dans ces grands projets est de 62,5 %, avec quatre projets dépassant 94 %.
• Même les projets écrits dans des langages sécurisés en mémoire dépendent souvent de composants écrits dans des langages non sécurisés en mémoire.

Certains exemples notables de l’ensemble examiné sont Linux (ratio de code non sécurisé 95 %), Tor (ratio de code non sécurisé 93 %), Chromium (ratio non sécurisé 51 %), MySQL Server (ratio non sécurisé 84 %), glibc (ratio 85 %), Redis (ratio 85 %), SystemD (65 %) et Electron (47 %).

CISA explique que les développeurs de logiciels sont confrontés à de multiples défis qui les obligent souvent à utiliser des langages non sécurisés en mémoire, tels que les contraintes de ressources et les exigences de performance.

Cela est particulièrement vrai lors de la mise en œuvre de fonctionnalités de bas niveau telles que le réseau, la cryptographie et les fonctions du système d’exploitation.

“Nous avons observé que de nombreux projets open source critiques sont partiellement écrits dans des langages non sécurisés en mémoire et une analyse limitée des dépendances indique que les projets héritent de code écrit dans des langages non sécurisés en mémoire via des dépendances,” .

“Lorsque les performances et les contraintes de ressources sont des facteurs critiques, nous avons constaté, et nous nous attendons à ce que l’utilisation continue de langages non sécurisés en mémoire soit maintenue.”

L’agence souligne également le problème des développeurs désactivant les fonctionnalités de sécurité de la mémoire, soit par erreur soit délibérément, pour répondre à des exigences spécifiques, ce qui entraîne des risques même lors de l’utilisation de blocs de construction théoriquement plus sûrs.

En fin de compte, CISA recommande aux développeurs de logiciels d’écrire un nouveau code dans des langages sécurisés en mémoire tels que Rust, Java et GO et de transitionner les projets existants, en particulier les composants critiques, vers ces langages.

De plus, il est recommandé de suivre les bonnes pratiques de codage, de gérer et d’auditer attentivement les dépendances, et de réaliser des tests continus, y compris des analyses statiques, dynamiques et des tests de fuzzing, pour détecter et résoudre les problèmes de sécurité de la mémoire.

Source de l’article