Journal Une CVE dans le compilateur rust

Posté par  . Licence CC By‑SA.
Étiquettes :
26
20
jan.
2022

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  (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  (site web personnel) . Évalué à 4.

      Euh… sinon, pourquoi pas de backport ?

      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.

      Et on sait dire quels programmes doivent être recompilés ?

      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  (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  (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  (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  . É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  (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  (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  . É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  (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  . É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  (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  . É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  (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  . É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  . Évalué à 1. 

        Et on sait dire quels programmes doivent être recompilés ?

        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)

        S'il faut avoir le code pour compiler, maintenant, où va t-on…

        • [^] # Re: pardon, j'ai ri

          Posté par  (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  . É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  . É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

  • # Cherie, ca va troller

    Posté par  . Évalué à 10.

    With enough eyes, all bugs are somebody else's problem, c'est bien ca la citation?

    We also want to thank Florian Weimer for reviewing the UNIX-like fix and for reporting the same issue back in 2018, even though the Security Response WG didn't realize the severity of the issue at the time.

    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  (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  . É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  . É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  (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  (site web personnel) . Évalué à 4.

      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.

      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  . É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  . Évalué à 6.

        En quoi est-ce grave pour un programme non privilégié ?

        Ç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 -r se mette à suivre les liens symboliques ;).

    • [^] # Re: La description n'est pas claire je trouve.

      Posté par  (site web personnel) . Évalué à 0.

      Le fait que ça puisse être réalisé par un programme privilégié est la cerise sur le gâteau

      Quel intérêt à un attaquant de provoquer la race condition sans la cerise sur le gâteau?

      mais déjà en soi c'est assez grave.

      Est-ce que le cas arrive sans faire exprès?

      • [^] # Re: La description n'est pas claire je trouve.

        Posté par  . Évalué à 8.

        Quel intérêt à un attaquant de provoquer la race condition sans la cerise sur le gâteau?

        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  (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.

          1. Est-ce que le répertoire $X est un lien symbolique.
          2. Sinon, alors ouvre le répertoire $X et supprime le contenu.

          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  . Évalué à 4. Dernière modification le 21 janvier 2022 à 11:27.

      La gestion des permissions, quand à elle, reste correcte d'un point de vue système

      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  . É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  . Évalué à 5.

          On parle bien de supprimer des fichier auquel l'utilisateur qui les supprime a bien les droits de suppression.

          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  . É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  . Évalué à 7.

              L'appel système de suppression est fait en mode privilégié ?

              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 /tmp je 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  . É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  . É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 :

              /var/spool/pad/alice
/var/spool/pad/bob
/var/spool/pad/charlie

              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/alice et trouve un dossier caca et un fichier pipi (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 caca et 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 caca et 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  . É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  . É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  . Évalué à 3.

              du point de vue du système, il a bien les droits de le faire

              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  . Évalué à 4.

            le code Rust vérifie que c'est bien le cas et accepte d'agir en mon nom (je le mandate)

            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  . Évalué à 3.

              Mais ta description du problème prête à malentendu.

              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.

              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.

              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  . Évalué à 3.

              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.

              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  . É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  . É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  . Évalué à 5. Dernière modification le 23 janvier 2022 à 11:11.

                  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.

                  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  (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  . Évalué à 10.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Binaires statiques et conséquences

    Posté par  . É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  . É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  . Évalué à 9.

        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.

        Par contre, je le retrouve avec un strings sur le binare:

        $ strings binary |grep 'rustc version'
clang LLVM (rustc version 1.57.0 (f1edd0429 2021-11-29))

        « 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  . Évalué à 5.

        j'ai du mal à voir où il pourrait faire un remove_dir_all

        oui, c'est justement une partie du problème… Comment identifier les impacts ?

  • # Petite précision

    Posté par  . É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  . É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.