Est `curl {quelque chose} | Sudo bash -` une méthode d'installation raisonnablement sûre?

Question

La façon la plus simple d'installer NodeJS sur Ubuntu ou Debian semble être Nodesource, dont instructions d'installation dites d'exécuter:

curl -sL https://deb.nodesource.com/setup_12.x | Sudo -E bash -

Cela se heurte à certaines règles de sécurité de base que j'ai apprises il y a longtemps, telles que "se méfier des téléchargements" et "faire attention à Sudo". Cependant, j'ai appris ces règles il y a longtemps, et de nos jours, il semble que tout le monde le fasse ... eh bien, au moins, il a 50 votes positifs sur askubuntu.com .

En lisant diverses opinions sur d'autres sites, je trouve que certaines personnes pensent également que curl-pipe-Sudo-bash n'est pas sûr:

• Phil. (Idontplaydarts.com, 2016-04-19) Détection de l'utilisation du côté serveur "curl | bash"
• Stemm, Mark. (Sysdig.com, 13/06/2016) Les amis ne laissent pas les amis Curl | Bash.
• Stackoverflow.com. (2015-04-01 et suivants) Pourquoi utiliser curl | Sudo sh n'est pas conseillé? ( également lié à askubunt )

alors que certaines personnes pensent que c'est aussi sûr que toute autre méthode d'installation pratique:

• McLellan, Bryan. (Github.com/btm, 2013-09-25) Pourquoi curl | Sudo bash est bon.
• YCombinator.com. (2016-10-22 et suivants) Mur de honte "Curl Bash piping".
• Varda, Kenton. (Sandstorm.io, 2015-09-24) curl | bash n'est-il pas sûr? .

Il y en a aussi qui explorent le problème sans donner un avis décisif:

• Granquist, Lamont. (Chef.io, 16/07/2015) 5 Façons de Résoudre le Problème de Bash Curl Pipe install.sh.

Puisqu'il n'y a pas de consensus clair de la part d'autres sites, je demande ici: le curl-pipe-Sudo-bash est-il une méthode d'installation raisonnablement sûre, ou comporte-t-il des risques inutiles qui peuvent être évités par une autre méthode?

Answer 1

C'est à peu près aussi sûr que n'importe quelle autre norme¹ méthode d'installation tant que vous:

• Utiliser HTTPS (et rejeter les erreurs de certificat)
• Faites confiance à votre magasin de certificats de confiance
• Faites confiance au serveur à partir duquel vous téléchargez

Vous pouvez et devez séparer les étapes - téléchargez le script², inspectez-le et voyez s'il fait quelque chose de louche avant d'exécuter le script que vous avez téléchargé ³. C'est une bonne idée. Cela ne fera rien de mal si vous le faites et vous pourriez prendre un compromis, que vous pouvez signaler à la source et à la communauté en général. Soyez prêt à creuser beaucoup de Bash, si mon expérience avec de telles choses est un indicateur. Vous pouvez également essayer de le `` développer '', de télécharger tous les scripts qu'il ferait séparément et de peaufiner le script pour les appeler, si vous êtes particulièrement préoccupé par les serveurs malveillants, mais à un moment donné, vous devez décider d'utiliser simplement un serveur différent si vous faites si peu confiance au premier.

Sachez que si le serveur (deb.nodesource.com) est compromis, vous n'avez pratiquement aucun recours. De nombreux gestionnaires de packages proposent de vérifier les signatures GPG sur les packages, et même si ne partie fondamentale de l'architecture de signature de clés est cassée , cela fonctionne toujours dans l'ensemble. Vous pouvez spécifier manuellement l'autorité de certification pour wget et curl , bien que cela prouve seulement que vous vous connectez vraiment à ce serveur, pas que le serveur diffuse du code sécurisé ou qu'il s'agit d'un code légitime des créateurs.⁴

Si vous vous inquiétez de l'exécution de code arbitraire, APT définitivement le permet, et je suis assez confiant que les deux Homebrew et Yum faire aussi. Donc, comparativement, ce n'est pas dangereux. Cette méthode permet une plus grande visibilité; vous savez précisément ce qui se passe: Un fichier est en cours de téléchargement, puis interprété par Bash comme un script. Cotes sont bonnes, vous avez déjà suffisamment de connaissances pour commencer à étudier le script. Au pire, le Bash peut appeler un autre langage que vous ne connaissez pas, ou télécharger et exécuter un exécutable compilé, mais même ces actions peuvent être remarquées au préalable et, si vous êtes si enclin, enquêté.

En passant, étant donné que la plupart du temps vous devez installer des choses avec Sudo, je ne vois pas son utilisation ici comme une préoccupation particulière. C'est légèrement déconcertant, oui, mais pas plus que Sudo apt install ....

---

^{1: Il existe des gestionnaires de paquets beaucoup plus sûrs , bien sûr - je ne parle que des gestionnaires standard comme APT et yum.}

^{2: ... tout en étant prudent avec vos copies/pâtes, naturellement. Si vous ne savez pas pourquoi vous devez faire attention à vos copies/pâtes, considérez ce code HTML: Use this command: <code>echo 'Hello<span style="font-size: 0">, Evil</span>!'</code>. Pour être sûr, essayez de coller dans un éditeur de texte (GUI) et assurez-vous d'avoir copié ce que vous pensez avoir fait. Si vous ne l'avez pas fait, arrêtez immédiatement de faire confiance à ce serveur .}

^{3: Vous pouvez réellement détecter si le script est juste en cours de téléchargement ou en cours de téléchargement et exécuté, car interpréter un script avec Bash prend un temps différent que de l'enregistrer dans un fichier, et le système de tuyaux de Linux peut "sauvegarder", ce qui peut rendre ces différences de synchronisation visibles pour le serveur. Si vous avez exécuté exactement curl | Sudo bash commande qu'ils ont donnée, votre examen est (du moins s'il s'agit d'un serveur malveillant ...) vide de sens.}

^{4: Là encore, il semble que NodeSource crée une sorte de programme d'installation personnalisé, qui ne serait pas signé par l'équipe Node de toute façon , alors ... je ne suis pas convaincu que ce soit moins sûr dans ce cas particulier.}

Answer 2

Il y a trois principales fonctionnalités de sécurité que vous voudriez examiner lorsque vous comparez curl ... | bash installation sur un système de packaging de distribution Unix comme apt ou yum.

La première consiste à vous assurer que vous demandez le ou les fichiers corrects. Apt le fait en conservant son propre mappage des noms de packages vers des URL plus complexes; le gestionnaire de paquets OCaml est juste opam offrant une vérification assez facile. En revanche, si j'utilise la méthode d'installation de curl/Shell d'opam, je dois vérifier l'URL https://raw.githubusercontent.com/ocaml/opam/master/Shell/install.sh, en utilisant mes connaissances personnelles qui raw.githubusercontent.com est un site bien géré (détenu et géré par GitHub) qui a peu de chances de voir son certificat compromis, qu'il est en effet le bon site pour télécharger du contenu brut à partir de projets GitHub, le compte GitHub ocaml est en effet le fournisseur dont je souhaite installer le logiciel et opam/master/Shell/install.sh est le bon chemin vers le logiciel que je veux. Ce n'est pas très difficile, mais vous pouvez voir les opportunités d'erreur humaine ici (par rapport à la vérification de apt-get install opam) et comment les agrandir avec des sites et des URL encore moins clairs. Dans ce cas particulier également, un compromis indépendant de l'un des deux fournisseurs ci-dessus (GitHub et le projet OCaml) pourrait compromettre le téléchargement sans que l'autre ne puisse faire grand-chose.

La deuxième fonction de sécurité confirme que le fichier que vous avez obtenu est bien le bon pour le nom ci-dessus. La méthode curl/Shell repose uniquement sur la sécurité fournie par HTTPS, qui pourrait être compromise du côté serveur (peu probable tant que l'opérateur du serveur prend grand soin) et du côté client (beaucoup plus fréquent que vous ne le pensez dans ce âge de interception TLS ). En revanche, apt télécharge généralement via HTTP (rendant ainsi l'ensemble de l'ICP TLS non pertinent) et vérifie l'intégrité des téléchargements via une signature PGP, ce qui est considérablement plus facile à sécuriser (car les clés secrètes n'ont pas besoin d'être en ligne, etc.) .

La troisième consiste à s'assurer que, lorsque vous disposez des fichiers corrects du fournisseur, le fournisseur lui-même ne distribue pas de fichiers malveillants. Cela dépend de la fiabilité des processus de conditionnement et de révision du fournisseur. En particulier, j'aurais tendance à faire confiance aux équipes officielles Debian ou Ubuntu qui signent les packages de versions pour avoir produit un produit mieux vérifié, à la fois parce que c'est le travail principal de ces équipes et parce qu'elles font une couche d'examen supplémentaire en plus de ce que le fournisseur en amont a fait.

Il existe également une fonctionnalité supplémentaire, parfois utile, fournie par les systèmes de conditionnement, telle qu'apt, qui peut ou non être fournie par les systèmes utilisant la procédure d'installation curl/Shell: l'audit des fichiers installés. Parce qu'apt, yum, etc. ont des hachages pour la plupart des fichiers fournis par un package, il est possible de vérifier une installation de package existante (en utilisant des programmes tels que debsums ou rpm -v) pour voir si l'un de ces fichiers installés a été modifié.

La méthode d'installation curl/Shell peut offrir quelques avantages potentiels par rapport à l'utilisation d'un système d'emballage tel que apt ou yum:

1. Vous obtenez généralement une version beaucoup plus récente du logiciel et, surtout s'il s'agit d'un système d'emballage lui-même (comme pip ou Haskell Stack), il peut effectuer des vérifications régulières (lorsqu'il est utilisé) pour voir s'il est à jour et offre un système de mise à jour.

2. Certains systèmes vous permettent d'effectuer une installation non root (c'est-à-dire dans votre répertoire personnel, qui vous appartient) du logiciel. Par exemple, alors que le binaire opam installé par le précédent install.sh est placé dans /usr/local/bin/ par défaut (nécessitant un accès Sudo sur de nombreux systèmes), il n'y a aucune raison pour que vous ne puissiez pas le mettre dans ~/.local/bin/ ou similaire, n'accordant ainsi aucun accès root au script d'installation ou au logiciel suivant. Cela a l'avantage de garantir que la compromission racine est évitée, bien que cela permette aux versions ultérieures du logiciel de compromettre la version installée du logiciel que vous utilisez.

Answer 3

Soumettre une réponse à ma propre question. Je ne sais pas si c'est la meilleure réponse, mais j'espère que d'autres réponses répondront à ces points.

curl {something} | Sudo bash - sur Linux est aussi sûr que de télécharger quelque chose sur Windows et de cliquer avec le bouton droit de la souris en tant qu'administrateur. On peut affirmer que cela est "raisonnablement sûr", mais comme l'a récemment xkcd suggère, personne ne sait vraiment à quel point la sécurité informatique est mauvaise de nos jours. Dans tous les cas, cette méthode n'est PAS aussi sûre que les autres méthodes d'installation.

Toutes les méthodes plus sûres incluent une étape pour vérifier l'intégrité du téléchargement avant d'installer quoi que ce soit, et il n'y a aucune bonne raison de sauter cette étape. Les installateurs comme apt ont une certaine forme de cette étape intégrée. Le but est de s'assurer que ce que vous avez téléchargé correspond à ce que l'éditeur a prévu. Cela ne garantit pas que le logiciel est exempt de ses propres vulnérabilités, mais il devrait au moins protéger contre les attaques simples qui remplacent le téléchargement par des logiciels malveillants. L'essentiel est simplement de vérifier les sommes de contrôle MD5 et SHA256 publiées par l'éditeur du logiciel. D'autres améliorations sont possibles:

• Il est préférable d'obtenir ces sommes de contrôle via un chemin réseau différent, par exemple en appelant un ami dans un autre pays, ce qui protégerait contre les attaques MITM.
• Il est préférable d'obtenir les sommes de contrôle au moins un jour plus tôt/plus tard, ce qui protégerait au cas où le site Web de l'éditeur serait brièvement repris mais la prise de contrôle était arrêtée dans la journée.
• Il est préférable de vérifier les sommes de contrôle elles-mêmes à l'aide de GPG, ce qui protégerait au cas où le site Web de l'éditeur serait compromis mais que leur clé privée GPG ne l'était pas.

Commentaire d'un côté: Certains sites disent que vous devez télécharger le script sh puis l'inspecter avant de l'exécuter. Malheureusement, cela donne un faux sentiment de sécurité à moins que vous ne vérifiiez le script avec un niveau de précision pratiquement impossible. Le script Shell est probablement de quelques centaines de lignes, et de très petites modifications (comme une modification obscurcie d'un caractère en URL) peuvent convertir un script Shell en programme d'installation de logiciels malveillants.

Answer 4

"Raisonnablement sûr" dépend de vos poteaux de but, mais curl | bash est loin derrière l'état de l'art.

Jetons un coup d'œil au type de vérification que l'on peut souhaiter:

• Veiller à ce qu'une personne malveillante chez votre FAI ne puisse pas faire un homme du milieu pour vous alimenter en code arbitraire.
• S'assurer que vous obtenez les mêmes fichiers binaires que l'auteur a publiés
• Assurez-vous que vous obtenez les mêmes fichiers binaires que ceux qui téléchargent le même nom de fichier ont également obtenu.
• S'assurer que les fichiers binaires que vous téléchargez reflètent un ensemble spécifique et vérifiable de sources et d'étapes de génération, et peuvent être reproduits à partir de ceux-ci.
• Séparer l'installation du logiciel de l'exécution du logiciel - si vous installez un logiciel pour être géré par un utilisateur non privilégié et disposant de faibles privilèges, aucun compte disposant de privilèges élevés ne doit être mis en danger dans le processus.

Avec curl | Sudo bash, vous obtenez seulement le premier si cela; avec rpm ou dpkg vous en obtenez; avec nix, vous pouvez tous les obtenir.

• En utilisant curl pour télécharger via https, vous avez une certaine sécurité contre un attaquant man-in-the-middle, dans la mesure où cet attaquant ne peut pas forger un certificat et une clé valides pour le site distant . (Vous n'avez pas la sécurité contre un attaquant qui a fait irruption dans le serveur distant ou contre celui qui a accès à l'autorité de certification locale que votre entreprise a mise dans toutes les autorités de certification. stocker les listes sur le matériel appartenant à l'entreprise afin qu'elles puissent MITM les connexions SSL sortantes à des fins de "sécurité" intentionnelles!).

  C'est le seul modèle de menace curl | Sudo bash réussit parfois à vous protéger.

• S'assurer que vous obtenez les mêmes fichiers binaires que l'auteur a publiés peut être fait avec une signature numérique de cet auteur (les distributions Linux distribuent généralement un trousseau de clés OpenPGP appartenant à des personnes autorisées à publier des packages dans cette distribution, ou ont une clé qu'ils utilisent pour packages qu'ils ont eux-mêmes construits et utilisent des mesures de contrôle d'accès pour restreindre les auteurs qui peuvent intégrer des packages dans leurs systèmes de génération).

  Déployé correctement, rpm ou dpkg vous offre cette sécurité; curl | bash non.

• S'assurer que demandant le même nom renvoie toujours les mêmes fichiers binaires est plus délicat, si une clé d'auteur autorisée aurait pu être capturée. Cela peut être accompli, cependant, si le contenu que vous téléchargez est adressé par hachage ; pour publier un contenu différent sous le même nom, un attaquant devrait soit découpler les entrées du hachage du contenu du fichier (détecté trivialement si c'est le hachage du binaire qui est publié).

  Le passage à une publication de build adressée par hachage a deux approches possibles:

  • Si le hachage provient des sorties de la génération, l'approche la plus simple d'un attaquant consiste à trouver le mécanisme par lequel l'utilisateur final a recherché ce hachage et à le remplacer par une valeur malveillante - de sorte que le point d'attaque se déplace, mais le la vulnérabilité elle-même ne le fait pas.

  • Si le hachage concerne les entrées de la génération, vérifier que la sortie de la génération correspond réellement à ces entrées nécessite plus de travail (à savoir, relancer la génération!) À vérifier, mais cette vérification devient beaucoup plus difficile à éviter.

  Cette dernière approche est la meilleure, même si elle coûte cher à vérifier et met du travail supplémentaire sur les gens qui font le packaging de logiciels (pour traiter tous les endroits où l'auteur d'un programme est plié dans des horodatages ou d'autres éléments non reproductibles pour construire le processus lui-même).

  Le traitement des auteurs malveillants ne fait pas partie du modèle de sécurité que rpm ou dpkg essaie de résoudre, et bien sûr, curl | bash n'y fait rien non plus.

• Séparer l'installation du runtime consiste à concevoir le format de sérialisation à l'avance sans fonctionnalités dangereuses - ne prenant pas en charge les bits setuid ou setgid, ne prenant pas en charge les scripts d'exécution sans bac à sable au moment de l'installation avec du code arbitraire, etc. . curl | Sudo bash ne vous donne aucune protection ici, mais rpm et dpkg ne le font pas non plus. nix, en revanche, permet à tout utilisateur non privilégié d'installer un logiciel dans le magasin - mais le format de sérialisation NAR qu'il utilise ne représentera pas les bits setuid ou setgid, ce contenu dans le magasin n'est référencé par aucun compte d'utilisateur qui ne le fait pas ne le demandez pas explicitement ou un logiciel qui en dépend, et les cas où le logiciel a besoin de setuid privilèges pour être installés nécessitent une action administrative explicite hors bande avant que ces bits ne soient réellement définis.

  Seules les méthodes d'installation de logiciels bizarres, de niche et spécialisés comme nix permettent de faire les choses correctement.

Answer 5

Une option serait d'essayer de faire une analyse comportementale de ce que sont les résultats, en exécutant la commande curl séparément pour récupérer une copie de ce que le script est.

Ensuite, exécutez-le dans un linux vm et regardez quelles connexions se produisent, etc., vous pouvez même exécuter la surveillance de l'intégrité des fichiers sur le système et voir ce qui est modifié lors de son exécution.

En fin de compte, le contexte est important que ce comportement puisse conduire à des compromis, mais n'est pas particulièrement pire que la plupart des autres méthodes par lesquelles les gens obtiennent des logiciels. Même avec l'analyse comportementale que j'ai mentionnée ci-dessus, vous êtes limité par les sources secondaires à partir desquelles le script peut récupérer, qui peuvent également être dynamiques - mais il en va de même pour les dépendances des vrais logiciels, donc à un certain niveau, vous devez vous fier à la source pour ne pas lier quelque chose de mauvais.

Answer 6

Non, ce n'est pas aussi sûr. Votre téléchargement peut échouer au milieu.

Si votre téléchargement échoue au milieu, vous aurez exécuté un script partiel, qui peut potentiellement échouer à effectuer certaines opérations qu'il était censé effectuer (nettoyage, configuration, etc.).

Ce n'est pas probable si le script est petit ou que votre connexion est rapide, mais c'est possible, surtout sur une connexion lente.

Ceci est un exemple de la différence entre la sécurité et la sûreté. :)