Memory Safety : opportunités et défis pour la cybersécurité logicielle de demain, partie 1

Les logiciels sont aujourd’hui omniprésents dans notre quotidien : qu’il s’agisse des véhicules électriques de dernière génération, de l’e-banking ou de systèmes vitaux. L’une des menaces les plus répandues en matière de sécurité pour ces systèmes réside dans une gestion défaillante de la mémoire. On parle dans ce contexte de « vulnérabilités de type memory safety ». De nouvelles failles de ce genre sont régulièrement découvertes. Résoudre le problème à sa racine constitue toutefois un défi majeur pour les développeur·euse·s comme pour les entreprises.*

Qu’entend-on par memory safety ? 

La memory safety décrit la capacité d’un logiciel à gérer de manière sûre et correcte l’allocation, l’utilisation et la libération de la mémoire vive (RAM). Elle est un élément central de la sécurité logicielle et demeure, malgré des années de recherche, l’une des sources de vulnérabilités les plus courantes dans les logiciels modernes [1].

La mémoire vive sert à stocker des données telles que les entrées utilisateur ou les résultats de calculs. Lorsqu’un programme est lancé, à la fois le code (les instructions exécutées par l’ordinateur) et les données (les informations traitées) sont chargés en mémoire. Comme l’illustre la figure 1, il n’existe pas de séparation stricte entre code et données en RAM [2].

Figure 1 : Données et code en mémoire vive

Les langages de programmation largement utilisés comme C ou C++ permettent une gestion manuelle de la mémoire. Celle-ci est généralement considérée comme extrêmement sujette aux erreurs : les programmes peuvent accéder involontairement à des zones mémoire non autorisées, ce qui peut être exploité par des attaquants, par exemple pour exécuter du code malveillant ou lire des données confidentielles. La fréquence élevée des vulnérabilités de type memory safety s’explique notamment par le fait que cette gestion manuelle reste largement employée dans ces langages [2].

Mais à quoi ressemblent ces failles dans la pratique ? Quelques exemples concrets permettent de mesurer l’ampleur du problème.

Vulnérabilités memory safety en pratique

Dans un rapport récemment publié, Kaspersky Security Services [3] a identifié plusieurs failles dans le dernier système d’infodivertissement de Mercedes-Benz. Parmi celles-ci figuraient des vulnérabilités liées à la memory safety, des faiblesses dans le système anti-vol ainsi que des possibilités de manipulation du firmware (logiciel intégré au matériel, assurant des fonctions essentielles). Cet exemple illustre que les problèmes de memory safety peuvent survenir même dans des systèmes d’usage quotidien. Pour les utilisateur·rice·s, cela peut se traduire par des dysfonctionnements critiques ou la perte de données personnelles. Par ailleurs, selon des rapports de Microsoft [4] et de Google [5], environ 70 % des vulnérabilités détectées dans leurs propres produits sont toujours imputables à des problèmes de memory safety.

Dans le cadre d’un travail de semestre du Bachelor Informatique à la BFH/TI, des données de la National Vulnerability Database (NVD) [6] ont été analysées. La NVD est une base de données publique recensant les vulnérabilités connues dans les logiciels et le matériel. La proportion des failles de la catégorie « Memory Safety » [7] a été comparée au nombre total de vulnérabilités. La statistique obtenue (figure 2) donne une vue d’ensemble représentative de ces vulnérabilités dans l’ensemble du paysage informatique : la part varie entre 15 et 20 % au cours des dix dernières années. Il s’agit d’un taux significatif, et la part réelle pourrait être sensiblement plus élevée.

Figure 2 :Analyse de la NVD sur les vulnérabilités de type memory safety

Quelles pistes permettent toutefois de résoudre – ou du moins de réduire – ce problème ?

Approches pour améliorer la memory safety 

Pour éviter les vulnérabilités de type memory safety, il est recommandé d’écrire le code dans des langages dits memory safe. L’importance du sujet est soulignée, par exemple, par une annonce récente de la Maison-Blanche [8]. Des langages tels que Python, Java ou C# gèrent automatiquement la mémoire grâce à un garbage collector, un mécanisme qui nettoie et réorganise la mémoire inutilisée en arrière-plan. Cela nécessite cependant des ressources supplémentaires, ce qui rend ces langages peu adaptés à des systèmes proches du matériel ou fortement contraints, comme les systèmes embarqués (ordinateurs spécialisés intégrés dans des produits tels que des voitures ou des appareils électroménagers). Dans ces cas, le contrôle direct de la mémoire fourni par C/C++ reste indispensable.

C’est ici qu’intervient le langage Rust, qui propose une approche innovante pour prévenir ces problèmes.

Rust à la rescousse ?

Publié en 2015, le langage Rust [9] s’est imposé dans de nombreux domaines. Il permet une programmation bas-niveau tout en garantissant la memory safety à la compilation et sans recourir à un garbage collector. Rust intègre des concepts modernes et impose des règles strictes empêchant l’apparition de vulnérabilités de ce type.

Rust gagne en importance dans diverses branches de l’IT et pourrait réduire sensiblement les failles de memory safety. L’expert en sécurité matérielle Pascal Mainini explique dans un entretien comment Rust pourrait renforcer la memory safety à l’avenir et dans quels domaines ce langage est particulièrement pertinent :

[Herren] : « Dans quels secteurs Rust va-t-il gagner en importance ? »

[Mainini] : « Rust est fondamentalement un langage universel, mais certains domaines l’adoptent plus rapidement que d’autres. On peut citer la programmation proche du matériel, mais aussi le cloud. Rust étant très performant, il contribue à l’efficacité énergétique lorsque des applications tournent sur des milliers de serveurs. Enfin, Rust est aujourd’hui le seul langage, aux côtés de C, pouvant être utilisé pour développer des pilotes du noyau Linux. »

Lire l’intégralité de l’entretien sur l’évolution de Rust.

Bilan et perspectives

Les vulnérabilités de type memory safety peuvent toucher n’importe quel type de système. Sur l’ensemble du paysage IT, la proportion connue oscille entre 15 et 20 %, bien moins que les 70 % souvent évoqués par Microsoft et Google. Il s’agit néanmoins d’un problème sérieux. Une protection complète exige d’importants efforts et ressources de la part des entreprises et des développeur·euse·s. À court terme, la tâche reste difficile, car le code existant devrait être migré vers des langages memory safe ou révisé en profondeur. De plus, ces vulnérabilités sont souvent complexes à détecter. Diverses pistes, comme de nouvelles méthodes de détection (notamment par l’IA) ou l’adoption de langages comme Rust, pourraient réduire les risques à l’avenir. Une chose est claire : le code devrait autant que possible être écrit dans des langages memory safe. Il est en outre essentiel de renforcer la sensibilisation des entreprises et des développeur·euse·s à cette problématique.

Références

[1] H. Okhravi, “Memory Safety,” IEEE Security & Privacy, Bd. 22, Nr. 4, pp. 13–15, Jul. 2024 [Online]. Zugriff: doi:10.1109/MSEC.2024.3409849

[2] C. Rohlf (2023, Sep. 26). Memory Safety: An Explainer [Webseite]. Zugriff: https://cset.georgetown.edu/article/memory-safety-an-explainer/, 18. Okt. 2025

[3] Kaspersky Security Services (2025, Jan. 17). Mercedes-Benz Head Unit security research report [Website]. Zugriff: https://securelist.com/mercedes-benz-head-unit-security-research/115218/, 19. Okt. 2025

[4] Microsoft Security Response Center (2019, Jul. 16). A proactive approach to more secure code [Webseite]. Zugriff: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/, 18. Okt. 2025

[5] The Chromium Projects (o.D.). Memory safety [Webseite]. Zugriff: https://www.chromium.org/Home/chromium-security/memory-safety/, 18. Okt. 2025

[6] B. Harold (2015). National Institute of Standards and Technology: National Vulnerability Database [Webseite]. Zugriff: https://nvd.nist.gov/, 18. Okt. 2025

[7]The Mitre Corporation (o.D.) Comprehensive Categorization: Memory Safety [Webseite]. Zugriff: https://cwe.mitre.org/data/definitions/1399.html#Vulnerability_Mapping_Notes_1399, 18. Okt. 2025

[8] The White House: PRESS RELEASE: Future Software Should Be Memory Safe [Archiviert]. Zugriff: https://web.archive.org/web/20240226175250/https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/, 31. Okt. 2025

[9] Rust Team (o.D.) Rust: A language empowering everyone to build reliable and efficient software [Webseite]. Zugriff: https://rust-lang.org/, 19. Okt. 2025