Amazon Web Services va, dans un effort conjoint avec la Fondation Rust, payer des développeurs pour vérifier 7500 fonctions non sécurisées de la bibliothèque Rust. C’est ce qui ressort d’une récente annonce qui ravive le débat sur la question de savoir si le Rust, initialement présenté comme un meilleur gage de sécurité pour les logiciels que C et C++, est en réalité plus sécurisé. Rust propose des moyens de contourner ses garanties de sécurité en utilisant le mot-clé "unsafe". La documentation précise à ce propos que « si Rust ne vous permettait pas d'effectuer des opérations non sécurisées, vous ne pourriez pas accomplir certaines tâches, comme interagir directement avec le système d'exploitation, bien qu'elle ajoute que vous utilisez cette possibilité à vos propres risques ». Les risques dont il est question comprennent le déréférencement de pointeurs nuls qui est une source courante de problèmes de sécurité.
C’est aussi ce que rapporte la fondation Rust lorsqu’elle souligne que 20 % des unités de compilation Rust s’appuient sur le mot-clé "unsafe" :
« Bien que Rust soit un outil puissant pour la sûreté de la mémoire et la sécurité, la puissance de ses contrôles de sécurité peut devenir limitante lorsque le programme ne peut pas réellement se tromper mais que le compilateur est incapable de le garantir lui-même ; le programmeur peut prouver l'impossibilité d'un comportement indéfini par des moyens qui ne sont pas à la disposition du compilateur. Dans ces cas, les programmeurs Rust utiliseront le mot-clé unsafe pour indiquer une fonction ou un segment de code ayant a) des considérations de sécurité supplémentaires ou b) des invariants qu'un programmeur doit suivre manuellement pour garantir la sécurité et qui ne sont pas nécessairement exprimés par Rust ou la fonction elle-même. Le mot-clé unsafe permet aux développeurs de déréférencer un pointeur brut, de modifier une variable statique mutable et, surtout, d'appeler des fonctions unsafe. »
La récente publication d’AWS va plus loin en soulignant que même si les développeurs n'utilisent que du code sûr, la plupart des applications dépendent toujours de la bibliothèque standard Rust dans laquelle on retrouve environ 7500 fonctions non sécurisées. Grosso modo, la publication d’Amazon suggère qu’une mauvaise utilisation de Rust peut conduire aux mêmes problèmes en matière de sécurisation de la mémoire des logiciels rencontrés avec des langages concurrents comme le C et le C++. En d’autres termes, la faille ultime se trouverait entre la chaise et le clavier et c’est le programmeur.
Verify the Safety of the Rust Standard Library https://t.co/d61FSp6EjR #rustlang #devops #programming
— Dinko Korunic (@dkorunic) November 22, 2024
Des initiatives comme Fil-C et Safe C++ ont vu le jour pour apporter une meilleure réponse aux problèmes de sécurisation de la mémoire des logiciels en C et C++
Les extensions Safe C++ visent à introduire des fonctionnalités de sécurité mémoire dans le langage C++. Ces extensions incluent des mécanismes comme le vérificateur d’emprunt (borrow checker) pour prévenir les erreurs d’utilisation après libération et des analyses d’initialisation pour garantir la sécurité des types. Ces outils permettent aux développeurs d’écrire du code plus sûr sans sacrifier les performances et la flexibilité du C++.
« Les langages de programmation C et C++ sont merveilleux. Il existe une tonne de codes écrits dans ces deux langages. Mais le C et le C++ sont des langages peu sûrs. De simples erreurs de logique peuvent amener un attaquant à contrôler la zone mémoire un pointeur et ce qui y est écrit, ce qui ouvre la voie à une exploitation facile. Beaucoup d'autres langages (Rust, Java, etc.) n'ont pas ce problème ! Mais j'aime le C. Et j'aime presque autant le C++. J'ai grandi avec eux. C'est une telle joie pour moi de d'utiliser les deux ! C'est pourquoi, pendant mon temps libre, j'ai décidé de créer mes propres langages C et C++ à mémoire sécurisée. Il s'agit d'un projet personnel et d'une expression de mon amour pour le C. Fil-C introduit la sécurité de la mémoire au cœur du C et du C++ », souligne Filip Pizlo de Epic Games à propos de Fil-C.
« Le projet vise une compatibilité à 100 % avec C et C++. Il suffit de compiler son code avec le compilateur pour obtenir du code sécurisé », d’après Pizlo. Ce dernier reconnaît néanmoins que « le principal obstacle à l'utilisation de Fil-C en production est la vitesse. Fil-C est actuellement environ 1,5 à 5 fois plus lent que le C traditionnel. »
Ces initiatives font surface dans un contexte de multiplications des appels au passage à des langages de programmation dits sécurisés et Rust s’impose au point d’être adopté pour lé développement du noyau Linux
Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau. Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.
En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.
De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.
Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.
Source : AWS
Et vous ?
Quel est votre expérience avec Rust en tant que langage de programmation et en particuluer avec les cas d'utilisation du mot-clé "unsafe" ? Les garanties de sécurisation de la mémoire qui sont attribuées à ce langage en comparaison au C et au C++ sont elles exagérées ? Le potentiel problème avec Rust n’est-il pas le même qu’avec C et C++ : la qualité des programmeurs ?Voir aussi :
Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents 
Envoyé par d_d_v
crachent dessus, généralement sans trop savoir de quoi il parlent. Je ne parle normalement pas de Rust dans les news qui ne parlent que de C++ si ce n'est pour rectifier quelqu'un qui dirait des erreur sur Rust.
