Selon une étude de Consumer Reports, les développeurs du secteur public et du secteur de l’industrie devraient s’engager à utiliser des langages à mémoire sécurisée pour le développement de nouveaux produit et de nouveaux outils. Et identifier les bibliothèques et les paquets les plus critiques pour passer à des langages à mémoire sécurisée.
L’organisation s’est interrogée sur les mesures à prendre pour favoriser l’adoption de langages « sans risque pour la mémoire », comme Rust, au détriment d’options telles que C et C++. Consumer Reports explique vouloir s’attaquer aux « menaces qui pèsent sur l’ensemble de l’industrie et qui ne peuvent être résolues par le comportement des utilisateurs ou même par le choix des clients » et a identifié le « manque de sécurité de la mémoire » comme l’un de ces problèmes.
Le rapport, Future of Memory Safety, examine les défis liés à l’adoption des langages à mémoire sécurisée dans les universités, les niveaux de méfiance à l’égard de ces langages, et leur introduction dans les bases de code écrites dans d’autres langages.
« Une occasion en or » pour les professeurs d’informatique
Au cours des deux dernières années, de plus en plus de projets ont commencé à adopter progressivement Rust pour les bases de code écrites en C et C++ afin de rendre le code plus sûr pour la mémoire. Parmi eux, on trouve des initiatives de Meta, le projet Android Open Source de Google, le projet Chromium et le noyau Linux.
En 2019, Microsoft a révélé que 70 % des bogues de sécurité qu’il avait corrigés au cours des 12 dernières années étaient des problèmes de sécurité de la mémoire. Ce chiffre était élevé car Windows était écrit principalement en C et C++. Depuis lors, l’Agence nationale de sécurité (NSA) a recommandé aux développeurs d’opérer un changement stratégique en délaissant le C++ au profit du C#, de Java, de Ruby, de Rust et de Swift.
L’évolution vers des langages à mémoire sécurisée – notamment, mais pas seulement, vers Rust – a même incité le créateur du C++, Bjarne Stroustrup, et ses pairs, à élaborer un plan pour la « sécurité du C++ ». Les développeurs aiment le C++ pour ses performances et il domine toujours les systèmes embarqués. Le C++ est toujours beaucoup plus utilisé que le Rust, mais les deux sont des langages populaires pour la programmation de systèmes.
Le rapport souligne que les professeurs d’informatique ont ici une « occasion en or d’expliquer les dangers » les dangers de problèmes de mémoire et pourraient, par exemple, augmenter le poids des erreurs de sécurité de la mémoire dans l’évaluation des notes. Mais il ajoute que l’enseignement de certaines parties de certains cours en Rust pourrait ajouter une « complexité non essentielle » et qu’il existe une perception selon laquelle Rust est plus difficile à apprendre, alors que le C semble être une valeur sûre pour l’employabilité future de nombreux étudiants.
Comment introduire un nouveau langage dans une base de code existante
Pour surmonter la croyance des programmeurs selon laquelle les langages à mémoire sécurisée sont plus difficiles, il faudrait expliquer que ces langages « obligent les programmeurs à réfléchir à des concepts importants qui améliorent en fin de compte la sécurité et les performances de leur code », note le rapport.
Le rapport aborde également la question de savoir comment introduire un nouveau langage dans une base de code existante. Le projet du noyau Linux ne réécrit pas le code du noyau existant, mais active Rust pour certains pilotes dans un premier temps. L’équipe chargée de la sécurité de Chromium active prudemment le langage Rust lorsque cela s’avère judicieux d’un point de vue commercial et développe également des fonctions de sécurité de la mémoire pour le code C++ dans Chrome. Le projet Android Open Source pousse Rust de manière plus agressive. Dans Android 13, 21 % du nouveau code est écrit en Rust, mais le code C et C++ reste dominant.
Le rapport indique que les entreprises devraient faire preuve de transparence quant aux causes des bogues, en fournissant des informations détaillées sur les failles de sécurité afin d’aider les chercheurs et les experts du secteur à déterminer le pourcentage de vulnérabilités dues à la sécurité de la mémoire.
Pas assez d’informations pour relier la cause d’une faille à un langage particulier
Mais il sera difficile de savoir par où commencer, car les divulgations de vulnérabilités ne fournissent généralement pas assez d’informations pour relier la cause d’une faille à un langage particulier. « Par exemple, les bulletins de sécurité d’Apple ne fournissent actuellement pas assez de détails pour distinguer les vulnérabilités de mémoire induites par le C/C++ des bogues logiques », note le rapport.
Le rapport reconnaît par ailleurs que l’industrie est convaincue qu’il n’existe pas les incitations sociales et commerciales nécessaires pour s’attaquer pleinement à un problème de cette ampleur.
Il imagine également un monde où les réglementations en matière de supply chain « sans risque pour la mémoire » existent bel et bien. Aujourd’hui, note le rapport, il est impossible d’acheter des routeurs donc le code est entièrement écrits dans des langages à mémoire sécurisée. De tels produits n’existent pas.
Pour favoriser l’adoption de l’utilisation de langages sûrs pour la mémoire, on pourrait demander aux développeurs de dresser la liste des mesures d’atténuation de la sécurité de la mémoire utilisées par un logiciel, ainsi qu’une approche de type « étiquette nutritionnelle » pour indiquer le pourcentage de code couvert par les langages sûrs, les audits, le fuzzing, le sandboxing, etc.
Source : « ZDNet.com »