• # C'est vieux, mais toujours d'actualité

    Posté par . Évalué à 3 (+1/-0).

    Merci pour le (vieux) lien. C'est toujours dur de convaincre les gens de ne pas recommander une telle méthode (coucou Rust).

    Ceci dit, est-ce que ce comportement n'a pas été modifié dans curl ? Ça ne changerait que moyennement le problème, mais bon.

    • [^] # Re: C'est vieux, mais toujours d'actualité

      Posté par (page perso) . Évalué à 5 (+3/-0).

      Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.

      • [^] # Re: C'est vieux, mais toujours d'actualité

        Posté par . Évalué à 2 (+0/-0).

        Je ne vois pas trop comment wget ou curl pourraient détecter cela.

        Une solution serait de détecter quand la sortie standard est redirigée, comme le font grep ou ls, et dans ce cas de ne rien faire.
        Ça casserait tous ces comportements sales, mais ça forcerait les usages légaux à évoluer aussi.

        • [^] # Re: C'est vieux, mais toujours d'actualité

          Posté par . Évalué à 2 (+1/-0). Dernière modification le 22/10/18 à 11:31.

          Ça casserait tous ces comportements sales, mais ça forcerait les usages légaux à évoluer aussi.

          Il y a plein de raisons légitimes à vouloir piper un document téléchargé… Ce n'est pas sans raison que c'est le comportement par défaut.

          Le seul cas qui pose problème c'est les utilisateurs qui exécutent ce genre de commande sans avoir forcement conscience des risques.

          Rappelons aussi que curl foo > bash est à quelques fichiers près sémantiquement équivalent à wget foo ; chmod +x foo; ./foo, voir même que git clone foo ; cd foo; ./foo.

          Il faut juste avoir conscience de ce que peut faire ce genre de commandes.

          • [^] # Re: C'est vieux, mais toujours d'actualité

            Posté par . Évalué à 2 (+0/-0).

            Yep, et tu noteras que je n'ai pas dis que c'était en soit une bonne idée de blinder le système contre ça.

            Mais, j'ai trouvé la question pertinente dans le sens technique. De la même façon que certains interpréteurs de commandes forcent validation d'une commande copiée/collée quoi.

            D'autant plus que, bah, j'ai été confronté à des gens qui font ce genre de trucs sans lire le script, pour installer npm par exemple, logiciel qui n'a aucun respect pour le système qui l'entoure.
            Au taf, à cause de ce genre de conseils pourris sur le net, j'ai perdu plusieurs jours à réinstaller des systèmes dans un état fonctionnel (parce que, non, en 1 an, je n'ai pas eu le temps de mettre en place une politique de restauration des machines… je ne suis pas payé en tant qu'admin, mais en tant que dev, à la base… je manque à la fois de compétences pour déployer les bons outils, et de temps pour essayer de le faire).

    • [^] # Re: C'est vieux, mais toujours d'actualité

      Posté par (page perso) . Évalué à -2 (+2/-6).

      C'est toujours dur de convaincre les gens de ne pas recommander une telle méthode (coucou Rust).

      Ben le problème initial qui nécessite cette bidouille est toujours la, les gens n'y peuvent pas grand chose si les distrib ne sont pas foutue de se mettre d'accord sur une format de package "sûr" commun et qui passe aussi bien que ça.
      Les fautifs sont-ils vraiment les utilisateurs de cette méthode? Plutôt de perdre ton temps à convaincre les de ne pas recommander une telle méthode, ce serait peut-être plu efficace d'essayer de convaincre les auteurs de la source du problème de régler le problème initial, tu ne penses pas?

      Ce n'est pas en soignant les blessures que tu empêcheras les suivants de se blesser, mais en stoppant la source des blessures.

      • [^] # Re: C'est vieux, mais toujours d'actualité

        Posté par (page perso) . Évalué à 6 (+5/-1).

        Le format des paquets n'a aucun lien avec le problème présenté ici.

        Le truc discuté ici consiste à copier/coller une ligne de shell afin de télécharger automatiquement tout le bouzin et d'exécuter des commandes.
        C'est l'équivalent d'un fichier zip qui contient un runme.sh. Le zip en question peut contenir autant de cochonneries que la méthode décriée.

        Si tu veux en faire un paquet à télécharger depuis un site web quelquonque, c'est le même résultat : il peut contenir n'importe quoi. Même s'il existait un format de paquet accepté par toutes les distributions.

        • [^] # Re: C'est vieux, mais toujours d'actualité

          Posté par . Évalué à 6 (+4/-0). Dernière modification le 24/10/18 à 13:57.

          En fait j'ai tendance à penser des fois que la méthode du curl pipé vers bash est moins dangereuses que certaines autres. Au moins tu peux lire le script et voir ce qu'il fait relativement facilement.

          Quand c'est un package il faut d'abord soit le mettre dans un bac à sable isolé, soit l'extraire quelque part pour l'étudier.

          Après le script spaghetti qui va aller chercher d'autres scripts ailleurs là ça devient ingérable (hello netdata.io) et t'as plus qu'à serrer les fesses et faire confiance à l'upstream, à ton dns, le proxy qui fait du mitm dans ta boite et que sais-je encore.

        • [^] # Re: C'est vieux, mais toujours d'actualité

          Posté par (page perso) . Évalué à 3 (+1/-0).

          Le format des paquets n'a aucun lien avec le problème présenté ici.

          Le rapport c’est que distribuer son logiciel proprement en créant un dépôt ad-hoc et des packages pour une distribution est déjà chiantissime alors le faire pour toutes les distributions est inimaginable hormis pour les plus gros projets.

          Le plus simple moyen de distribution est MacPorts mais la cible est spécifique au possible.

          Le vieux combo «configure && make all install» est largement délaissé — pour de bonnes raisons, l’investissement temps-bénéfice pour apprendre les Auto-Tools est assez décourageant, et même si on a tout bien fait, créer son package pour une distribution de premier plan comme Debian ou Ubuntu est absurdement difficile.

          • [^] # Re: C'est vieux, mais toujours d'actualité

            Posté par (page perso) . Évalué à 3 (+1/-0).

            On parle de truc qui ne sont pas dans les dépôts des distributions. En quoi avoir un format de paquet standardisé vas permettre d'être quasi-certain qu'un paquet récupéré sur un site quelconque ne contient pas de cochonneries ?
            Ou au moins être plus confiant qu'avec une ligne de commande venant du même site, administré par les mêmes personnes.

            • [^] # Re: C'est vieux, mais toujours d'actualité

              Posté par (page perso) . Évalué à 4 (+2/-0). Dernière modification le 30/10/18 à 14:45.

              Ou au moins être plus confiant qu'avec une ligne de commande venant du même site, administré par les mêmes personnes.

              Ce qui augmente la confiance c'est d'avoir un contenu cryptographiquement signé avec un checksum publié séparément.

              Rien n'interdit par exemple de faire un serveur qui publie un script différent en fonction des paramètres du client (IP, user agent, plage horaire) ce qui pourrait constituer un vecteur d'attaque.

              Avec un paquet hébergé ad-hoc c'est un peu mieux – faire confiance à une clef GPG est plus restrictif que de faire confiance à un serveur web – l'idéal serait d'avoir des sources différentes pour le checksum et pour le paquet.

  • # Résumé ?

    Posté par (page perso) . Évalué à 10 (+9/-0). Dernière modification le 19/10/18 à 15:08.

    • faut pas copier/coller de commande depuis un site web. Cf http://thejh.net/misc/website-terminal-copy-paste
    • faut pas prendre de l'info sensible d'un site web en http (pour éviter un MiTM qui modifierait le contenu)
    • ça ne suffit pas prendre de l'info d'un site web en https : en fait n'importe qui peut avoir un certificat valide, donc faut garantir que c'est le bon domaine…
    • même si on a le bon domaine, faudrait que ça soit vraiment lui qui réponde (DNSSEC? proxy?)
    • et quand on a tout ça, bon ben faut pas exécuter directement le contenu dans un shell sans réfléchir… (encore moins avec sudo…)
    • et ça serait mieux si le contenu était signé GPG, que la clé soit de confiance et qu'un café soit offert.

    (un exemple sur rvm.io: \curl -sSL https://get.rvm.io | bash -s stable )

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.