3 pièce(s) jointe(s)
La vulnérabilité "BatBadBut" a été découverte dans la bibliothèque standard Rust
La vulnérabilité "BatBadBut" a été découverte entre autres dans la bibliothèque standard Rust, mais elle affecte également Erlang, Go, Haskell, Java, Node.js, PHP, Python et Ruby
Une faille de sécurité critique, baptisée "BatBadBut", a été découverte entre autres dans la bibliothèque standard Rust, affectant toutes les versions antérieures à 1.77.2 sous Windows. La vulnérabilité, identifiée comme CVE-2024-24576, a un score CVSS de 10.0 et permet à un attaquant d'exécuter des commandes shell arbitraires en contournant le mécanisme d'échappement lors de l'invocation de fichiers batch avec l'API Command.
La vulnérabilité "BatBadBut" a été découverte par le chercheur en sécurité RyotaK et divulguée de manière responsable à l'équipe de sécurité de Rust, qui a donc expliqué comment l'équipe Rust a géré l'alerte, et patché la faille, ce qui n'est pas encore le cas sur tous les autres langages affectés.
Selon le billet de blog de RyotaK, le problème provient des règles complexes d'analyse de cmd.exe, l'invite de commande de Windows, qui est implicitement lancée lors de l'exécution de fichiers batch. La bibliothèque standard Rust ne parvient pas à échapper correctement les arguments de commande pour cmd.exe, ce qui permet l'injection potentielle de commandes.
Alors que les API Command::arg et Command::args de Rust garantissent que les arguments seront transmis tels quels au processus créé et ne seront pas évalués par un shell, la mise en œuvre sous Windows est plus complexe.
L'API Windows ne fournit qu'une seule chaîne de caractères contenant tous les arguments, laissant au processus créé la responsabilité de les diviser. La plupart des programmes utilisent la chaîne d'exécution standard argv en C, ce qui permet d'obtenir un comportement cohérent en matière de division des arguments. Cependant, cmd.exe possède sa propre logique de découpage des arguments, qui nécessite un échappement personnalisé par la bibliothèque standard Rust.
"Pour éviter l'exécution inattendue de fichiers batch, vous devriez envisager de déplacer les fichiers batch dans un répertoire qui n'est pas inclus dans la variable d'environnement PATH.", a noté RyotaK dans son billet de blog. "Dans ce cas, les fichiers batch ne seront pas exécutés à moins que le chemin d'accès complet ne soit spécifié, ce qui permet d'éviter l'exécution inattendue de fichiers batch."
L'équipe de sécurité de Rust a reconnu que la logique d'échappement existante dans la bibliothèque standard était insuffisante, ce qui permettait à des arguments malveillants de contourner l'échappement et d'entraîner une exécution arbitraire de l'interpréteur de commandes. La gravité de la vulnérabilité "BatBadBut" est considérée comme critique si des arguments non fiables sont transmis lors de l'invocation de fichiers batch sous Windows.
BatBadBut ne se limite pas à un seul identifiant CVE
Alors que l'attention s'est d'abord portée sur le langage de programmation Rust, il est apparu que la vulnérabilité "BatBadBut" ne se limite pas à un seul identifiant CVE. La vulnérabilité affecte plusieurs langages de programmation et outils, chacun se voyant attribuer un identifiant CVE différent en fonction de la mise en œuvre et de l'impact spécifiques.
Outre CVE-2024-24576, qui concerne la bibliothèque standard Rust, "BatBadBut" englobe également CVE-2024-1874, CVE-2024-22423 (qui affecte yt-dlp avec un score de risque élevé de 8,3) et CVE-2024-3566 (qui affecte Haskell, Node.js, Rust, PHP et yt-dlp). Cela met en évidence la nature étendue de la vulnérabilité et la nécessité pour les développeurs d'évaluer leurs applications et dépendances à travers différents langages de programmation et outils.
Atténuation
Pour remédier à la vulnérabilité "BatBadBut", l'équipe Rust a publié la version 1.77.2, qui inclut un correctif pour le problème. Ce correctif améliore la robustesse du code d'échappement et modifie l'API Command pour qu'elle renvoie une erreur InvalidInput lorsqu'elle ne peut pas échapper un argument en toute sécurité. Cette erreur sera émise lors du lancement du processus.
Pour les développeurs qui implémentent leur propre échappement ou qui ne gèrent que des entrées fiables sous Windows, la méthode CommandExt::raw_arg peut être utilisée pour contourner la logique d'échappement de la bibliothèque standard.
Il est important de noter que la vulnérabilité n'affecte que le code Rust fonctionnant sous Windows qui exécute des fichiers batch avec des arguments non fiables. Les autres plateformes ou utilisations de Windows ne sont pas concernées.
La communauté Rust a exprimé sa gratitude à RyotaK pour avoir divulgué la vulnérabilité de manière responsable, à Simon Sawicki (Grub4K) pour avoir identifié certaines des règles d'échappement adoptées, et aux membres du projet Rust qui ont aidé à développer le correctif, à le réviser et à coordonner le processus de divulgation.
Il est fortement conseillé aux développeurs utilisant Rust sur Windows de mettre à jour vers la version 1.77.2 dès que possible afin de réduire le risque d'attaques potentielles par injection de commandes. Il est essentiel de s'assurer que les entrées non fiables sont correctement validées et assainies avant d'être transmises en tant qu'arguments à des fichiers batch.
État des lieux sur les autres langages de programmation affectés
Sources : Équipe Rust, "BatBadBut: You can't securely execute commands on Windows" (RyotaK, chercheur en sécurité)
Et vous ?
:fleche: Quelle lecture faites-vous de cette situation ?
Voir aussi :
:fleche: Comment Rust améliore la sécurité de son écosystème : la Rust Foundation publie un rapport sur ce que leur initiative de sécurité a accompli au cours des six derniers mois de 2023
:fleche: « Choisir Rust est opter pour une meilleure sécurisation des logiciels qu'avec le C, mais une efficacité énergétique et une performance d'exécution que seul le C offre », d'après l'équipe AWS
Je savais que tu allais réagir :-)
Citation:
Envoyé par
Uther
C'est assez ironique d'avouer ne pas très bien comprendre le problème dont on parle, et en même temps de conclure que le problème vient des développeurs qui ne comprennent pas bien l’outil qu'ils utilisent.
Nuance, j'ai dis que je n'avais pas tout compris, car pas le temps, mais ne pas tout comprendre ne veux pas dire "rien" comprendre ;-) J'en ai compris assez (dans mon humble jugement) pour me faire mon opinion sur le sujet. Mais je n'ai pas la science infuse, et je vais tenter une autre approche pour défendre mon point de vue.
Citation:
Envoyé par
Uther
Plus sérieusement, bien sur que les développeurs se doivent de maitriser les API qu'ils utilisent. Mais pour cela, encore faudrait-il qu'il puissent se renseigner sur leur comportement. Le fait que la fonction CreateProcess de l'API Win32 fasse appel à cmd.exe et surtout que les paramètres sont interprétés comme une ligne de commande, n'est pas documenté officielement.
Difficile de reprocher aux développeur de ne pas connaitre un comportement non documenté.
Je vais prendre une métaphore. Tu te ballades dans la foret (dans ce cas, on pourrait dire la jungle), tu as faim, et tu vois un champignon. Tu n'as pas avec toi le "petit manuel des champignons dangereux" (et que même si tu l'as, tu ne trouve rien sur ce champignon), que fais-tu ? Perso, je ne mange pas le champignon... Remplace foret par développement, champignon par API, et le manuel par la documentation.
Donc oui, utiliser quelque chose dont on ne connait pas le résultat, c'est une erreur du développeur. Mon opinion est peut-être biaisée par mon vécu, je ne demande pas a avoir raison hein. Si des devs veulent utiliser un UB (comme notre discussion à propos de la sécurité du code entre Rust et C), c'est normal que des choses indéfinies peuvent se produire quelque fois ;-)
Citation:
Envoyé par
Uther
Microsoft peut difficilement corriger ça sans risquer de casser la compatibilité.
Mais à défaut de corriger la fonction CreateProcess, ils devraient au moins correctement la documenter pour indiquer qu'elle fait appel à cmd.exe pour les fichiers de commande et que ça implique des règles d’échappement différentes et bien plus complexes.
Je suis d'accord avec toi, une compagnie comme Microsoft se devrait d'avoir une documentation clair et net sur tout ce qu'ils produisent. Je suis aussi d'accord qu'ils ne peuvent pas "casser la compatibilité". C'est (je pense) un comportement (pas forcément mauvais, mais disons différent de ce que à quoi les devs sont habitués) qui a été "fait", il doit y avoir bien longtemps. Mais je ne suis pas certains que les devs lisent la documentation de chaque API. Pas le temps, pas pensé, oublié, ...
Il y a 3 coupables ici selon moi (par ordre d'importance):
1 - Les créateurs d'un langage "mainstream" utilisent mal une API,
2 - Les devs utilisent une API qu'ils ne maîtrisent pas,
3 - Microsoft a mal documenté la fonctionnalité.
Certains langages semblent ne pas avoir le soucis. Soit parce qu'ils n'utilisent pas cette API, soit parce qu'ils savaient (et ont trouvé quelque part une information à ce sujet), soit parce qu'ils ont eu du bol, comme avec les UB ;-)
Ce qui serait intéressant, c'est:
1 - De savoir depuis combien de temps ce "problème" existe,
2 - Et pourquoi on ne le découvre que maintenant ?
3 - Je ne me penche pas sur le pourquoi un compilateur "récent" pour un langage "récent" (non, je ne vise personne ;-)) a besoin d'utiliser une fonctionnalité reposant sur cmd.exe qui date de DOS 1.0...
Et je te rassures, je n'ai pas mangé de champignon :-)
Bonne fin de journée, et "Peace & Love", comme d'habitude.
je comprend bien ton point de vue...
... Tu n'es pas le principal coupable, je comprend très bien qu'on puisse se faire avoir de la sorte. On sait très bien qu'on ne peut pas vérifier tout tout le temps. Et même si on tente de le faire, c'est loin d'être évident. Je peux comprendre tous les arguments qui repoussent la faute sur la mauvaise documentation de microsoft, mais, comme tu le dis toi même, tu n'es pas développeur. Dans mon domaine, tout est plus "limité" et donc tout est hyper contrôlé, et je comprend que tout le monde ne vit pas dans le même domaine que le mien.
Je comprend que tu développes sans être développeur (ce n'est pas une critique), mais je pense que je ne me laisserais pas opérer par mon garagiste, ni que je ferais réparer ma voiture par mon chirurgien. Il y a parfois des choses incroyables qui sont "tolérées" quant on parle de "développement" et qui ne serait même pas envisagées dans un autre domaine.
Bah, c'est que du codage pensent certains qui sont au-dessus de nous, comme si c'était pas un domaine compliqué, puisque l'enfant de 10 ans de la RH a réussi a la dépanner pour une erreur dans une formule d'un tableau excel. Elle voulait la casse en rouge quand le montant était négatif. Le petit a regardé, et a su lui colorier sa casse correctement. Nickel, parfait, le voilà avec un diplôme de super informaticien qui sait tout sur tout. Maman l'a fait imprimer en encadrer par le voisin du cousin de la soeur de sa nièce (un cador en informatique, il joue toujours sur son C64), car chez elle, ça n'imprimait pas...
Avec ironie, si ce n'était pas dramatique, on voit avec boeing ce qui arrive quand les choses ne sont pas faites en prenant un maximum de sécurité, ni par des personnes compétentes, ni avec le temps pour bien faire.
Je suppose que tu ne monterais pas dans un avion piloté par un gus qui a fait 3h de deltaplane :-) Mais en "informatique", on trouve normal qu'une équipe qui développe un compilateur (donc pas des manchots à la base je suppose) qui sera utilisé partout dans le monde, utilise quelque chose dont elle n'a aucune idée du résultat. La documentation est une excuse trop facile, et si elle n'est pas bonne, bah, pas grave, on comprend pas mais "ça va aller"... Et on va pas faire de test, on a pas le temps. Non, je pense que la réalité, c'est qu'ils n'ont même pas chercher à lire la doc, l'intellisence a certainement proposé une fonction après 3 caractère, et hop, on passe dessus... Je ne chercherais pas plus loin la "cause" de cette affaire.
Et bientôt, quand une IA pondra un brol en assemblant des morceaux, si ça fait tomber l'avion, ce sera la faute à qui ? Pas à un manque de documentation, ils ont pompés le moindre byte disponible sur internet :-)
Le tout a prendre avec humour hein ;-)
Peace & Love.
oui, je suis d'accord... mais... (y'a toujours un mais :-))
Le dev final (celui qui utilise le compilateur), je suis d'accord avec toi. Mais ça dépend du domaine... (logiciel embarqué devant atteindre le zéro défaut dans mon domaine, on a eu cette discussion il y'a qlq semaine).
Je conçois très bien que tout le monde ne travail pas sur des logiciel critiques, et que oui, il faut faire un minimum confiance.
Les "devs" responsables du compilateur, eux, j'ai du mal à leur trouver une excuse, même si ça peut arriver, personne n'est a l'abris de faire une bêtise. Mais quand même, ils livrent un outil "critique", puisque l'on va utiliser leur compilateur de part le monde. Certains langages et leur compilateur n'ont apparemment pas le soucis, c'est donc qu'ils ont chercher/trouver/compris la doc et/ou surement fait un test.
Si je prends ton exemple avec l'image, le dev qui utilise un logiciel fait pour manipuler les images, il lui fait confiance. Il ne va pas tout vérifier, je l'accepte sans soucis.
Mais les devs du logiciel en question, c'est pas "par erreur" qu'ils ajoutent un watermark. Soit c'est ce qu'ils veulent et ils "trompent" leurs utilisateurs (qui perdrons leur confiance), soit c'est vraiment "par erreur" (admettons) et là, pour un logiciel de traitement d'image, tester que la sortie correspond à ce que l'on veut est un minimum je pense.
Si word n'imprime pas ce la secrétaire a tapé, je ne mets pas en cause cette dernière, mais word et donc microsoft. On est bien d'accord ? C'est pareil avec le compilo.
Mais comme ça a été découvert sur Rust, qui a comme argument une meilleur sécurité, ça me fais un peur rire :-)
Tu sais depuis quand elle existe cette faille ? A mon avis, depuis un certains temps je pense, et peut-être moins sur des langages plus anciens dont les équipes connaissaient le comportement de cmd.exe ? Je n'affirme rien, je demande ton avis et/ou si tu as des infos à ce sujet ?
Je n'aime pas vraiment les discussions par chat/mail/sms. On peut vite mal comprendre (ou mal s'expliquer) ou penser que l'autre abuse ou prend un ton qui ne passe pas... Je t'assure que si je donne cette impression, c'est pas le but que je recherche. On a tous des vécus et des expériences différentes. Moi je suis certainement tatillon sur certains soucis par "déformation professionnel" :oops:
BàT. et... peace & love :D
