Bonjour 'Nal,
Une petite CVE lié à la librairie standard rust est tombée aujourd'hui: CVE-2022-21658
Une CVE dans ce langage parfait?
Avant le lacher de troll, parce qu'on est pas (encore trolldi), rust apporte des garanties sur la gestion de la mémoire, pas sur l'absence de bug!
Keski se passe?
Le problème rencontré est le suivant: une fonction d'effacement récursif (std::fs::remove_dir_all) est susceptible de se faire prendre de court par une race condition et effacer un répertoire sur lequel un utilisateur n'a pas les droits.
Pour reproduire le problème, il vous faut:
- un programme privilégié, écrit en rust et sur lequel vous pouvez faire exécuter la primitive remove_dir_all sur un répertoire de votre choix qu'on appelera temp.
- créer un symlink vers un répertoire "sensible" à l'intérieur de temp.
- attendre que votre programme privilégié efface le répertoire qu'il n'aurait pas du pouvoir effacer.
Kesk'on fait?
Il faut patcher la fonction dans le compilateur. Ca sera fait avec la prochaine 1.58.1 (il n'y aura pas de backport a priori). Et surtout, il faudra recompiler le programme privilégié avec cette nouvelle version du compilateur, les librairies étant statiquement compilés dans les binaires rust.
# pardon, j'ai ri
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Euh… sinon, pourquoi pas de backport ?
Et on sait dire quels programmes doivent être recompilés ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: pardon, j'ai ri
Posté par Misc (site web personnel) . Évalué à 4.
Je suppose que la politique du projet, c'est de ne pas avoir de version LTS/stable du compilateur, et de pousser à utiliser la dernière version.
Mais c'est une supposition.
Si tu as le code source, avec grep , vu que cargo télécharge tout le code donc tu va l'avoir dans le répertoire.
Si tu n'as pas le code, je pense que c'est mort, vu que je ne vois pas de symbole sur le binaire rust (zola) que j'ai regardé (mais il est peut être strippé par la distribution)
[^] # Re: pardon, j'ai ri
Posté par paulez (site web personnel) . Évalué à 3.
C'est dans la lib standard, pas téléchargé par Cargo à priori mais fourni directement par le compilateur.
Je ne sais en effet pas comment trouver si un programme est impacté, ça m'intéresse.
[^] # Re: pardon, j'ai ri
Posté par Misc (site web personnel) . Évalué à 3.
J'aurais du préciser, je parle de chercher les occurrences de la fonction en question.
Ceci dit, vu que la lib standard peut utiliser les fonctions de la lib standard, un grep qui ne retourne rien ne va pas être concluant.
[^] # Re: pardon, j'ai ri
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
En gros, on est bon pour recompiler tout ce qui a été mis dans la nature.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: pardon, j'ai ri
Posté par claudex . Évalué à 9.
Ça ce n'est pas le problème le plus grave pour moi. Le problème, c'est que si tu tombe sur un binaire dans 6 mois, tu ne sauras pas s'il est patché ou pas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pardon, j'ai ri
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Il faudra probablement se servir de l'astuce que tu as donnée L'autre truc serait de penser à changer le numéro de version et indiquer dans le changelog qu'on recompile avec telle version minimale de Rust.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: pardon, j'ai ri
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Tu peux faire ça dans Cargo ou je me trompe ?
[^] # Re: pardon, j'ai ri
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je ne connaissais pas (merci pour l'info) et c'est encore mieux (je trouve).
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: pardon, j'ai ri
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est pareil pour n'importe quel binaire. A moins de le décompiler et de l'analyser ligne à ligne, comment savoir s'il utilise bien la lib patché et pas une fonction maison?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pardon, j'ai ri
Posté par claudex . Évalué à 8.
Sauf que si tu utilise des bibliothèque dynamiques, il suffit de mettre à jour ta bibliothèque et de vérifier que les programmes qui tournent utilisent bien la lib qui est sur le fs et pas une ancienne version.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pardon, j'ai ri
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Rien ne prouve que le programme appelle bien la lib là où tu le penses !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: pardon, j'ai ri
Posté par claudex . Évalué à 3.
Je ne comprends, on parle d'un programme dont tu as les sources mais tu ne sais pas avec quel compiltateur il a été compilé. Si on parle d'un programme propriétaire, ben c'est au fournisseur du programme de te donner une procédure de mise à jour.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pardon, j'ai ri
Posté par Misc (site web personnel) . Évalué à 2.
Grosso modo.
Ensuite, je sais que c'est plus facile à dire qu'à faire, mais il vaut mieux avoir ce genre de faille et découvrir qu'il y a un souci et pousser à automatiser à plus ou moins moyen terme sans urgence que d'avoir une faille comme log4j et devoir tout recompiler rapidement.
[^] # Re: pardon, j'ai ri
Posté par aiolos . Évalué à 2.
C'est quoi la différence ? Mis à part la sévérité de la vulnérabilité en question.
[^] # Re: pardon, j'ai ri
Posté par Misc (site web personnel) . Évalué à 4.
Non, c'est la sévérité et son impact sur le traitement de la vulnérabilité.
Je pense que si tu dois d'un coup tout patcher rapidement avec la pression de ta hiérarchie parce que c'est la fin du monde, tu va faire plus de conneries. La, il y a un peu plus le temps de penser à un plan et de le mettre en place, ce qui permet d'avoir des discussions plus sereines.
[^] # Re: pardon, j'ai ri
Posté par aiolos . Évalué à 5.
Oui, c'est toujours mieux d'avoir une vuln difficile à exploiter sur toute sa prod qu'une vuln avec un gros impact sur toute sa prod…
[^] # Re: pardon, j'ai ri
Posté par Arkem . Évalué à 1.
S'il faut avoir le code pour compiler, maintenant, où va t-on…
[^] # Re: pardon, j'ai ri
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Vu le contexte (cf. la mention dans paragraphe précédent, puis binaire mis en regard dans le paragraphe incriminé) ; on comprend qu'il s'agit du code source (c'est un peu la même erreur que l'on fait en disant/écrivant source tout court) et non du code exécutable (pareil, j'évite de dire/écrire que c'est du code binaire sinon d'autres vont chipoter aussi…)
Maintenant, dans le sens où tu le prends, ce n'est pas une impossibilité non plus et ça s'est déjà vu sur des cas/structures d'exécutables assez simples. héhé.
Bon vendredi à toi aussi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: pardon, j'ai ri
Posté par Arkem . Évalué à 1.
Je sais, je m'imaginais juste avec amusement la procédure de recompilation du code après avoir déterminé qu'il en avait besoin… sans avoir les sources, mais je ne l'ai pas très bien exprimé…
[^] # Re: pardon, j'ai ri
Posté par barmic 🦦 . Évalué à 1.
Il pourrait y avoir une procédure pour patcher le binaire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: pardon, j'ai ri
Posté par freem . Évalué à 2.
Ce qui se fait d'ailleurs même pour des softs libres parfois.
# Cherie, ca va troller
Posté par groumly . Évalué à 10.
With enough eyes, all bugs are somebody else's problem, c'est bien ca la citation?
LOL. Bon ok, je sais, c'est facile de troller et tout, mais quand meme c'est fort de café la.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Cherie, ca va troller
Posté par Zenitram (site web personnel) . Évalué à 10.
Parfois il y a un gros loupé, ça peut arriver à tout le monde, perso je trouve pas mal de mettre aussi visible l'excuse publique et pas dans un petit coin dans un bug tracker, ce genre de publicité demande d'outrepasser l'égo ou la honte et ce n'est pas donné à tout le monde.
[^] # Re: Cherie, ca va troller
Posté par groumly . Évalué à 7. Dernière modification le 21 janvier 2022 à 09:17.
Je sais bien, c’était presque vendredi, et je me suis dit que faire une ouverture à pbpg entamerais trolldi en beauté.
(Mais quand même, ça pique)
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# La description n'est pas claire je trouve.
Posté par cg . Évalué à 10. Dernière modification le 21 janvier 2022 à 00:56.
Il faudrait plutôt dire, pour décrire le problème plus simplement, qu'un programme peut être amené à suivre un lien symbolique et effacer des fichiers en dehors de l’arborescence ciblée au départ.
Le fait que ça puisse être réalisé par un programme privilégié est la cerise sur le gâteau, mais déjà en soi c'est assez grave.
La gestion des permissions, quand à elle, reste correcte d'un point de vue système.
[^] # Re: La description n'est pas claire je trouve.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Merci pour la clarification. :-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: La description n'est pas claire je trouve.
Posté par Gof (site web personnel) . Évalué à 4.
En quoi est-ce grave pour un programme non privilégié ?
Un attaquer qui a déjà les même privilèges que le programme pourrait tout simplement supprimer les fichiers directement.
Le bug ne se manifeste que si un attaqueur essaye activement de produire une race condition en remplacent un répertoire par un lien symbolique en countinu.
[^] # Re: La description n'est pas claire je trouve.
Posté par Thomas Douillard . Évalué à 5.
Ça peut se produire par accident y compris si il n'y a pas d'attaquants, même si très rare.
[^] # Re: La description n'est pas claire je trouve.
Posté par cg . Évalué à 6.
Ça ne fait certes pas un CVE, mais ça fait un comportement inattendu avec un effet potentiellement catastrophique, un genre de bug critique quand même, sans être un trou de sécurité.
Quand tu as un bug dans ext4 et que tu perds tes données, tu vas pas dire que ce n'est pas grave.
Imagine que
rm -rse mette à suivre les liens symboliques ;).[^] # Re: La description n'est pas claire je trouve.
Posté par windu.2b . Évalué à 4.
Un coup à se retrouver avec le clavier qui se blo
[^] # Re: La description n'est pas claire je trouve.
Posté par Zenitram (site web personnel) . Évalué à 0.
Quel intérêt à un attaquant de provoquer la race condition sans la cerise sur le gâteau?
Est-ce que le cas arrive sans faire exprès?
[^] # Re: La description n'est pas claire je trouve.
Posté par claudex . Évalué à 8.
Provoquer la perte de données non désirée. Prenons l'exemple d'une application web. J'ai user1 et user2 qui ont chacun un dossier avec leur données (pas confidentielles mais qu'ils ne veulent pas perdre). user1 créé un lien symbolique dans son dossier qui pointe vers "../user2" et supprime son compte (ce qui supprime son dossier). user2 a perdu ses données.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La description n'est pas claire je trouve.
Posté par Gof (site web personnel) . Évalué à 10.
Mais il faut que user1 soit capable de créer un dossier et de le remplacer par un lien symbolique en boucle pendent la suppression du compte.
Je rappelle que rust ne suis pas les lien symbolique quand il supprime récursivement. Mais le code fait comme ça.
Il n'y a un problème que si quelqu'un a changer le répertoire $X pour devenir en lien symbolique entre l'étape 1. et 2.
[^] # Re: La description n'est pas claire je trouve.
Posté par kantien . Évalué à 4. Dernière modification le 21 janvier 2022 à 11:27.
Même là c'est douteux. Si les services de l'État viennent détruire ta maison, sous ce très pernicieux prétexte, que j'en ai mis l'ordre de mission sur leur bureau, je doute que tu considères que la gestion des permissions reste correcte d'un point de vue système. ;-)
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: La description n'est pas claire je trouve.
Posté par claudex . Évalué à 4.
Sauf que là, on n'est pas dans cette situation. On parle bien de supprimer des fichier auquel l'utilisateur qui les supprime a bien les droits de suppression.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La description n'est pas claire je trouve.
Posté par kantien . Évalué à 5.
Ce n'est pas ce que j'ai compris, et c'est tout l'intérêt de la race condition. Je mets un lien symbolique vers un répertoire sur lequel j'ai des droits, le code Rust vérifie que c'est bien le cas et accepte d'agir en mon nom (je le mandate), puis avant qu'il suive le lien pour en effacer le contenu, je change la destination vers un répertoire sur lequel je n'ai aucun droit et là paf le chien. La race condition est là : entre le check et l'effacement effectif.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: La description n'est pas claire je trouve.
Posté par HL . Évalué à 3. Dernière modification le 21 janvier 2022 à 13:34.
Je ne comprends pas comment c'est possible, pourquoi le système n'empêche pas cette suppression non autorisée ? L'appel système de suppression est fait en mode privilégié ?
(Je ne connais pas le domaine Rust.)
[^] # Re: La description n'est pas claire je trouve.
Posté par kantien . Évalué à 7.
Oui, c'est un problème d'escalation des privilèges, raison pour laquelle je parlais des services de l'État (qui eux peuvent, sous condition, exproprier et détruire la maison de n'importe qui).
Le problème existe lorsque ce code Rust est utilisé par un utilitaire système en mode privilégié, alors je peux me servir de lui pour effacer un répertoire sur lequel je n'ai aucun droit. Dans l'exemple qu'ils donnent, ce pourrait être un utilitaire qui fait le ménage dans
/tmp, alors en créant un lien symbolique dans/tmpje peux effacer tout ce que je veux avec les même droits que l'utilitaire.Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: La description n'est pas claire je trouve.
Posté par HL . Évalué à 3.
Oui, donc ce n'est pas l'utilisateur qui a demandé la suppression, c'était ce point qui m'étonnait. En fait, on dupe un utilitaire avec un lien symbolique via la situation de compétition (race condition).
[^] # Re: La description n'est pas claire je trouve.
Posté par cg . Évalué à 10. Dernière modification le 21 janvier 2022 à 21:46.
Je vais essayer d'expliquer le principe du race condition.
D'un côté, le programme "nettoyeur" a pour mission de supprimer les dossiers et fichiers qui sont plus vieux que 1 mois en dessous de
/var/spool/pad(par exemple). Les liens symboliques ne sont pas suivis mais sont supprimés. Ce programme tourne en root./var/spool/pad/contient un répertoire par utilisateur, comme ceci :D'un autre côté, les utilisateurs font un peu ce qu'il veulent dans leurs dossiers, mais ne peuvent en sortir.
Le nettoyeur va faire son scan de temps en temps et supprimer les vieux fichiers, en respectant la règle du mieux qu'il peut. Horreur, il a supprimé des fichiers en dehors de
/var/spool/pad/alice!Passons la scène au ralenti sur un IBM 8088 à 10MHz (1979) :
11h22 - Le nettoyeur scanne
/var/spool/pad/aliceet trouve un dossiercacaet un fichierpipi(alice est un peu sénile) qui ont plus d'un mois. Il note dans son carnet qu'il faudra les effacer. Etc pour les autres dossiers.11h23 - Alice supprime le dossier
cacaet le remplace par un lien vers/usr/bin/. (Elle n'est pas si sénile que ça semble-t-il).11h24 - Confiant, le nettoyeur rentre dans le dossier
cacaet supprime son contenu, qui est en fait/usr/bin.11h24 aussi - Fin du jeu :'( .
Le principe n'a rien de spécifique à Rust. C'est un bug, qui provoque un trou de sécurité.
[^] # Re: La description n'est pas claire je trouve.
Posté par HL . Évalué à 1. Dernière modification le 21 janvier 2022 à 22:58.
Merci pour l'explication détaillée.
En fait j'avais l'impression que ça ressemblait à une exécution de la commande rm en mode "suid" (chmod +s). Le vrai problème ici est il me semble le déréférencement du lien symbolique.
[^] # Re: La description n'est pas claire je trouve.
Posté par claudex . Évalué à 4.
Oui, mais c'est Rust qui fait la vérification, du point de vue du système, il a bien les droits de le faire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La description n'est pas claire je trouve.
Posté par kantien . Évalué à 3.
Encore heureux, sinon ce ne serait pas un bug dans la bibliothèque Rust mais dans le noyau.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: La description n'est pas claire je trouve.
Posté par groumly . Évalué à 4.
C’est une façon particulière de décrire le problème.
C’est une privilege escalation dans le sens ou l’attaquant arrive à faire des choses qu’il n’est pas censé pouvoir faire. Mais quand on dit privilège escalation, la plupart des gens comprennent que l’attaquant élève les privilèges de code qu’il contrôle, ce qui n’est pas le cas ici.
Rust ne va pas vérifier que la personne qui a “fait la requête” a le droit de l’effacer. Rust ne va rien vérifier du tout, par définition rust ne peut que vérifier que les permissions du binaries sont ok, pas celles de l’utilisateur. Le système va verifier que le binaire a les permissions pour effacer le répertoire, c’est tout. Tu ne mandate pas (forcément) le programme, il essaye juste d’effacer un répertoire avec les permissions qu’il a.
pour exploiter ça sur des données auxquelles l’attaquant n’a pas accès, il faut:
- un programme qui tourne sous un compte plus élevé que le sien (setuid ou autre)
- que le programme essaye d’effacer quelque chose donné par l’utilisateur
Le premier point, ça va. Le deuxième, sorti d’exceptions très rares (j’ai du mal à voir le cas d’usage, pour être honnête, sorti de choses genre deluser et assimilé), est un très gros problème de sécurité, même sans ce bug.
Un programme root ou assimilé qui accepte de détruire des données sur la requête de n’importe qui, c’est un accident qui attend d’arriver comme ils disent outre quebin.
Le fond du problème, c’est plutôt ça a mon avis.
Après, oui, ca reste un gros bug pas beau du tout, parce que même sans élévation de privilèges, effacer des données, c’est dangereux. Mais ta description du problème prête à malentendu.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: La description n'est pas claire je trouve.
Posté par kantien . Évalué à 3.
Effectivement, mais c'est parce qu'il y avait une incompréhension de ma part. Je pensais que le code Rust suivait les liens symboliques (ce qui eut été étrange et discutable, mais pourquoi pas) et donc qu'il faisait un test pour éviter l'élévation de privilège, test contourner ensuite par l'attaquant via la race condition. Mais l'attaque est en faite plus subtile que cela, comme décrit par Gof.
Là si je parlais de mandat accepté et donc de requête utilisateur, c'est parce que je prenais le point de vue de l'attaquant qui en jouant sur les liens symboliques construits (de son point de vue) une requête pour le programme cible, qui lui ne voit pas du tout cela comme une requête mais comme une action légitime de suppression de son point de vue. Que l'attaquant transforme un répertoire en lien symbolique, ou modifie la destination du lien, de son point de vue cela ne change rien : il construit une requête de suppression pour augmenter ses privilèges.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: La description n'est pas claire je trouve.
Posté par barmic 🦦 . Évalué à 3.
C'est l'objectif des serveurs de fichiers. Spawn un processus avec les droits de l'utilisateur ça peut être très couteux. Ensuite c'est tout le principe des attaques pour les quels ont te donne un nom de fichier qui peut déclencher une expansion qui pointe ailleurs que là où tu crois.
remove_dir_allprend en paramètre une chaine de caractère donc c'est à toi de t'assurer qu'elles sont propre, même si c'est pour supprimer l'avatar "groomly.jpg" d'un utilisateur.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La description n'est pas claire je trouve.
Posté par groumly . Évalué à 4.
Ca rejoins ce que je dit. Je pense que c’est pas abusif de dire qu’un serveur de fichier est plutôt sensible niveau sécurité.
Il me semble aussi que smbd spawn un process sous l’utilisateur qui se connecte pour faire ce qu’il a a faire. Donc pas root, ou assimilé.
Pareil pour le coup des expansions de path, ça fait quelques décennies qu’on sait que c’est un gros problème. On évite de faire ça en root, en général.
Si tu laisses un process root manipuler un fs sur des input utilisateurs, ça va te peter a la gueule un jour, que ta stdlib soit plombée ou impeccable.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: La description n'est pas claire je trouve.
Posté par barmic 🦦 . Évalué à 4.
C'était surtout pour répondre au "il n'y a aucune raison de supprimer quelque chose depuis une entrée utilisateur". Ça existe et ce n'est pas aussi à la marge que ce que tu avais l'air de dire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La description n'est pas claire je trouve.
Posté par kantien . Évalué à 5. Dernière modification le 23 janvier 2022 à 11:11.
Je dirais plutôt que suivre les liens symboliques, lors d'une suppression, irait à l'encontre de la sémantique qu'on leur donne; ils représentent des références sur les données contenues dans le répertoire cible. Si un ramasse-miette, lorsqu'il rencontre une référence, ne se contentait pas de simplement la supprimer mais supprimait aussi, au passage, les données référencées, ça poserait de sérieux problèmes en soi (quand bien même je suis le propriétaire légitime des données en question).
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: La description n'est pas claire je trouve.
Posté par Misc (site web personnel) . Évalué à 3.
Pourtant, l'avis d'expropriation est la ou on s’attend à le trouver, placardé dans le fond d'un classeur fermé à clé, coincé dans des lavabos désaffectés avec sur la porte la mention : Gare au léopard.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par Gof (site web personnel) . Évalué à 10. Dernière modification le 21 janvier 2022 à 08:28.
Par ailleurs, le problème existe dans quasiment tout les langages. Il semblerait que les implémentations de std:: filesystem::remove_all de GCC et clang ont exactement le même problème. Pareil pour la fonction équivalente dans Qt.
Et les languages qui ne proposent pas de fonction équivalente laisse l'implémentation au développeur qui a 99% de chance de faire la même erreur.
Bref, ça montre juste que la barre pour les annonce de sécurité de Rust est assez haute.
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par _seb_ . Évalué à 4.
J'ai peut être mal compris mais il me semble que non justement.
std:: filesystem::remove_all supprime simplement le lien symbolique, pas son contenu.
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 5.
Je confirme, c'est bien précisé dans la doc
et
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 21 janvier 2022 à 09:38.
Vous ne parlez pas de la même chose.
_seb_ et Blackknight parlent de la spec ("C++ dit de faire"), Gof parle de l'implémentation ("GCC/Clang fait").
Pour le sujet du journal, la spec Rust est pareille que C++ (= "supprime simplement le lien symbolique"), c'est l'implémentation qui merde en cas de race condition et ne fait alors pas dans ce cas ce qu'elle dit faire et fait habituellement.
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Bien vu ! Ceci dit, je m'étais plutôt focalisé sur
C'est beaucoup plus général.
Allez, je trolle :
Ça veut dire que GCC/CLang ne respecte pas la norme, on ne peut pas les appeler compilateur C++17 ?
Bon, pour Ada, c'est facile, la notion de lien symbolique n'est même pas précisée par la norme même si on peut l'associer aux special files qui sont normalement effaçables :)
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par Gof (site web personnel) . Évalué à 4.
En fait la spec dit que les race condition sont des "undefined behaviour". Donc ils respectent bien la spec, et ce qui est considéré comme une faille de sécurité en rust est juste un truc normal en C++
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
On n'est plus un UB près :D
[^] # Re: C'est la bibliothèque standard qu'il faut patcher
Posté par Gof (site web personnel) . Évalué à 8.
La documentation des anciennes versions de rust aussi
Mais bon, il y a une race condition qui existait dans l'implémentation, et qui existe aussi, dans la plupart des fonctions équivalentes dans diverses bibliothèques.
Par exemple dans libc++:
https://github.com/llvm-mirror/libcxx/blob/78d6a7767ed57b50122a161b91f59f19c9bd0d19/src/filesystem/operations.cpp#L1145
Si la directory
pdeviens un lien symbolique entre la ligne 1144 et 1145, il va suivre le lien symbolique.# Binaires statiques et conséquences
Posté par Christophe . Évalué à 10.
Bel exemple ici d'un inconvénient d'utiliser des binaires statiques (chose revenue à la mode avec Go et Rust): lorsqu'un bug est découvert dans une dépendance, il est très difficile de savoir ce qu'on doit mettre à jour.
Alors pour les paquets d'une distribution Linux j'imagine que tout sera recompilé avec la nouvelle version de la bibliothèque standard, mais pour le reste (petits utilitaires compilés localement, situation hypothétique d'un binaire commercial qui n'est plus maintenu, etc) c'est un peu le flou artistique…
Je trouve que c'est une saine piqûre de rappel de l'avantage d'avoir un livrable moins monolithique. En attendant, je crois qu'il ne me reste plus qu'à recompiler tous ces fameux petits utilitaires qui veulent remplacer les outils classiques (exa, fdupe, fd, ripgrep…)
[^] # Re: Binaires statiques et conséquences
Posté par YetiBarBar . Évalué à 4.
Sur ripgrep, exa, fd, … Pas certain de la nécessité de recompiler:
- ce ne sont pas des programmes privilégiés;
- j'ai du mal à voir où il pourrait faire un remove_dir_all
En revanche, je plussois sur l'inconvénient de la compilation statique… et même pire dans ce cas, le fichier 'Cargo.lock' ne référence pas, si ma mémoire est bonne la version de la librairie standard.
[^] # Re: Binaires statiques et conséquences
Posté par claudex . Évalué à 9.
Par contre, je le retrouve avec un strings sur le binare:
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Binaires statiques et conséquences
Posté par Christophe . Évalué à 5.
oui, c'est justement une partie du problème… Comment identifier les impacts ?
# Petite précision
Posté par syj . Évalué à 4.
il faut préciser que l'attaquant doit créer dans le répertoire un dossier anodin (non symbolique)
qu'il vient substituer par un lien symbolique au moment ou le programme privilégié s'exécute et va supprimer ce répertoire.
Dans le cas précis, la faille tient du fait que la fonction ne respecte pas son contrat fonctionnel qui est de ne pas suivre la suppression des liens symboliques.
Seulement , l'attaquant s'est que le check de statut symbolique se fait au début de la fonction et non au moment où la suppression est effective.
# Samba est écrit en rust ? ;)
Posté par so_phi . Évalué à 2.
Toutes les version de Samba antérieure à 4.13.16 sont vulnérables au risque de création en suivant un lien symbolique… (avec plein de conditions pour y parvenir.)
https://www.samba.org/samba/security/CVE-2021-43566.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.