Le blog de Genma
Vous êtes ici : Accueil » Informatique & Internet » GNU/Linux, Logiciels Libres » curl script |sh

curl script |sh

D 21 mars 2017     H 09:00     A Genma     C 7 messages   Logo Tipee

TAGS : GNU/Linux Planet Libre

En lisant un article sur le fait qu’il est désormais possible de faire l’installation de Docker sur Raspberry pi je vois que l’installation passer par la commande

curl -sSL get.docker.com | sh

Tout d’abord que fait cette commande ?

La commande curl va lancer le programme Curl qui va se connecter au site get.docker.com, récupérer un script d’installation et le passer (le symbole |) en argument au shell (la commande sh). On est face à une commande shell assez classique (enchainement de deux programmes).

En quoi est-ce une mauvaise pratique ?

La commande s’exécute avec les droits de l’utilisateur courant. Par droits, il y a la possibilité de modifier ou supprimer tout un ensemble de fichiers par exemple. On n’a aucun moment le contenu du script qui est récupéré sur le site Internet de Docker et qui est lancé. Si ce script contient une commande du type

rm -rf *

parmi tous les lignes du script, cette commande sera executée et va supprimer de façon recursive les fichiers. Il faudrait donc pouvoir avoir le contenu du script pour pouvoir le vérifier...

Déléguer et avoir confiance

Par solution de facilité, on exécute une commande simple pour installer un programme. Mais on n’a aucune garantie sur son contenu. Certes c’est le cas pour beaucoup de choses, on délègue la confiance sur les développeurs de sa distribution Linux favorite (Debian, Ubuntu...), sur les auteurs de logiciels libres ou ceux qui y contribuent et qui vont relire et corriger le code source (d’où la nécessité d’un code ouvert et libre)... On accorde sa confiance tous les jours et plusieurs fois par jour.

Mais ce n’est pas une raison pour faire trop confiance (et pour ne pas apprendre, ne pas chercher à comprendre quelques bases.

Une analogie ?

Si vous lisez sur un forum que le fait de supprimer les freins de votre voiture lui permettra de consommer moins d’essence, car il y aura moins de frottement et donc moins de ralentissement, vous le faîtes ? Non. Et ce, même si l’explication scientifique associée vous semble tout à fait plausible, vous mettrez en doute cette affirmation et la démonstration associée. Pourquoi ? Parce que vous avez un minimum de connaissances, vous cherchez à comprendre et à apprendre (en passant le permis). Et si vous avez un doute, vous demandez au spécialiste qu’est le garagiste. Si vous faites la modification vous même, vous le faîtes en connaissance de cause (en tout cas je l’espère).

En informatique, c’est pareil. Toute demande de mot de passe pour faire une tâche d’administration implique devrait impliquer qu’on est compris et que l’on sait ce que l’on fait. Ou bien que l’on ait demandé à quelqu’un qui s’y connait et en qui on est confiance (on en revient à la confiance), le garagiste de l’informatique. Voici un exemple de la nécessité de comprendre mais surtout d’apprendre un minimum l’informatique (et plus particulièrement l’hygiène numérique). On ne doit pas devenir un garagiste (pour reprendre l’analogie avec la voiture) sauf si c’est quelque chose dont on a envie, la nécessité ou le temps mais comprendre qu’il y a des choses à apprendre, des bases, que rien n’est magique, c’est essentiel de mon point de vue.

7 Messages

  • Hello,
    très bien vu de rappeler les fondamentaux.
    Juste quelques remarques de coquilles ou mauvaises formulations (pas pour faire le grammar nazi, mais dans l’esprit d’apporter une relecture constructive)
    > je vois que l’installation passer par la commande
    > Par "droits", il y a on entend la possibilité de modifier
    > On n’a à aucun moment le contenu du script (ou mieux : on ne voit à aucun...)
    > va supprimer de façon récursive
    > ne pas chercher à comprendre quelques bases).
    > une tâche d’administration implique devrait impliquer qu’on est ait compris et que l’on

    hth


  • C’est à la fois tellement simple et efficace... que dangereux, oui.
    Personnellement je jette toujours un œil au script, quand il est bien je le garde au chaud dans un dossier plein de scripts sympa, ça me fait gagner du temps quand j’ai quelque chose à faire :)

    petit bonus : http://www.tecmint.com/10-most-dangerous-commands-you-should-never-execute-on-linux/


  • Tu oublies aussi qu’on n’est pas à l’abri d’avoir un réseau internet teinté.

    Or, si le contenu est intercepté par un FAI (ou autre) qui injecte un « script src="" » des familles, on va droit vers des effets de bords très indésirables.

    Une archive .zip, .deb ou .apt ne peut être utilisée/dépackée si elle est endommagée, donc si la transmission est foireuse. C’est une sacrée sécurité de plus. De plus, un paquetage système est bien plus facile à retirer.


  • Composer, le gestionnaire de dépendance de PHP, faisait comme ça avant mais maintenant il passe par une procédure à peine plus longue qui vérifie l’intégrité du fichier par une clef de hachage via PHP (parce que si vous téléchargez Composer, c’est que vous avez PHP) :
    https://getcomposer.org/download/

    Je trouve ça pragmatique et intelligent :)


  • Il me semble intéressant de rajouter que faire juste "curl script" pour s’assurer du contenu avant de faire "curl script | sh" n’est pas suffisant pour assurer la sécurité car il est possible de déterminer côté serveur si c’est la première ou la seconde commande qui est lancée (histoire de timing, les détails sont là : https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/). Un serveur web malicieux pourrait donc montrer un script innocent lorsque l’on fait "curl script" mais servir un script dangereux lors du "curl script | sh".


  • Très content de lire ça sur ton blog !
    J’ai horreur de cette pratique, le curl bidule | sh c’est le mal !!


  • C’est comme quand on va chez le médecin, et qu’on vous donne une ordonnance illisible pour 2mg de schmilblick, et que comme ça vous semble assez évident que c’est plutôt 300 mg de tartanpion qu’il faudrait vous décidez d’aller voir un autre médecin.