Journal [bookmark] terminaux et protection contre la copie

Posté par  . Licence CC By‑SA.
Étiquettes :
14
17
avr.
2018

Salut.

Ça ne doit pas être récent, mais tout de même, je me suis dis que d'autres que moi ici pourraient ne pas être au courant.
Je suis tombé sur un lien qui démontre comment insérer à l'insu de l'utilisateur lors d'un copier/coller (à noter: il faut que le retour chariot soit copié également, sinon le code n'est évidemment pas exécuté).

Pour le coup, on parle de commandes shell, d'une dangerosité évidente (il suffirait qu'un sudo ait été exécuté récemment pour que sur une ubuntu l'attaque passe en uid0 quand même), mais on peut imaginer utiliser ce genre d'astuces également dans des outils graphiques, puisque le réel problème viens du fait que la sélection visuelle diffère de ce qui est réellement copié dans le presse-papier.

Il semble que certains terminaux offrent une certaine mitigation en insérant des caractères d'échappement, mais il montre aussi comment le contourner: en insérant le caractère qui va bien en début de commande (ce que l'on peut remarquer quand on effectue un triple clic pour sélectionner la ligne entière, d'ailleurs, mais je ne doute pas que ça puisse se contourner)…

Du coup, j'ai découvert l'existence d'une option pour urxvt (à vue de nez, c'est un plugin-perl, il faut donc probablement compiler avec le support perl et le plugin installé), mais ça implique que l'utilisateur ait volontairement modifié sa configuration par défaut (URxvt.perl-ext-common: confirm-paste dans le ~/.Xdefaults) sur une Debian (ce qui me fait penser: quid de Tails ou de Kali, puisqu'elles sont censées être tournées vers un truc plus sécurisé, d'un côté ou de l'autre?).
Alors certes l'option est intrusive, et le vrai patch ne devrais pas être à ce niveau là (mais au niveau des navigateurs internet, qui une fois de plus ont des comportements trompeurs pour l'utilisateur final), mais je pense que ce genre de trucs devrait être activé par défaut. Surtout que bon, c'est pas tous les jours que l'on copie-colle des commandes pompées sur le net, si?

  • # oubli très important

    Posté par  . Évalué à 3.

    Je suis tombé sur cette information en lisant ceci: https://lwn.net/Articles/749992/

  • # Déjà discuté ici

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

    Et oui, 5 ans auparavant cela a déjà fait l'objet de débats ici même : https://linuxfr.org/users/dgellow/journaux/bookmark-don-t-copy-paste-me

    Et ce n'est pas aussi simple que tu ne le penses.

  • # Pourquoi se donner tant de mal ?

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

    Pourquoi se donner tant de mal à vouloir cacher des commandes derrière un copier-coller innocent alors qu’il est apparemment parfaitement acceptable de demander aux utilisateurs de faire ceci :

    Please do not use your distribution provided calibre package. […] To install or upgrade, simply copy paste the following command into a terminal and press Enter:

    sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()"

    • [^] # Re: Pourquoi se donner tant de mal ?

      Posté par  . Évalué à 3.

      Si tu es prêt à installer calibre, c’est que tu as un minimum confiance dans les devs de calibre pour pas mettre de la merde dans leur code. Confiance qu’il est tout à fait raisonnable d’étendre à linux-installer.py écrit par les même personnes.

      • [^] # Re: Pourquoi se donner tant de mal ?

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

        Que je leur fasse un minimum confiance pour ne pas intentionnellement cacher de code malicieux dans le script d’installation, sans doute (sinon ils pourraient tout aussi bien cacher le code malicieux dans le programme lui-même, indépendamment de la manière dont il est installé — sauf que le programme est typiquement exécuté avec les droits d’un utilisateur normal, alors que le script d’installation, tel qu’il est lancé dans la commande proposée au copier-coller, est exécuté avec les droits du super-utilisateur).

        En revanche, que je leur fasse confiance pour écrire un script d’installation sans bug, qui fonctionnera exactement comme prévu… Non, juste non. Je ne fais confiance à aucun développeur pour écrire du code sans bug. Et un bug dans un script d’installation qui par nature touche aux fichiers du système, non merci, très peu pour moi.

        • [^] # Re: Pourquoi se donner tant de mal ?

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

          Du coup tu fais comment pour installer un logiciel sur ta machine ?

          • [^] # Re: Pourquoi se donner tant de mal ?

            Posté par  (Mastodon) . Évalué à 10.

            Il est en train de te dire qu'il fait confiance en un mainteneur de paquet mais pas le développeur pour pas avoir un système tout deg à la fin. Ce qui a tout de même du sens quand tu vois le nombre de dev qui font encore des chmod 777 à tire larigot.

            Les curl trucmuche | sudo bash c'est mignon mais :

            1. en général l'install est vaguement bien gérée, par contre pour désinstaller bonjour les trucs qui traînent dans tous les coins et le script que tu dois lire à l'envers pour savoir nettoyer tout ça
            2. tu sais plus quelle version t'utilise et vue qu'il n'y a pas de moyen standard (parfois c'est --version, d'autre -V, d'autres applis faut aller dans le "about --> version, une autre ce sera ailleurs) c'est encore plus compliqué si on se rajoute des difficultés.
            3. un package c'est signé, pas un script qui traine dans un coin et c'est parfois créé directement depuis le gestionnaire de version avec vue sur l'historique des commits, ce qui ramène au point #4 :
            4. tu fais pas forcément confiance au dev sur le fait qu'il ne se soit pas fait pwner son site. C'est bien beau d'avoir toujours la dernière release à la seconde qui est sortie mais primo c'est des fois pas plus mal qu'il y'ait un lag entre la release upstream et celle en distro pour se rendre compte de ce genre de joyeusetés.

            Alors certe ça fait un intermédiaire de plus, et il y'a eu des gros epic fail de la part de certains mainteneurs (hum openssl debian, beurk linux mint) mais en principe un mainteneur est en général moins à l'ouest qu'un dev sur ce genre de questions (pas les mêmes métiers, toussa…).

            Après je dis pas que je n'utilises jamais de scripts d'installation, mais en général soit je les lances dans une sandbox avant, soit je prends le temps de les analyser pour voir de quoi il en retourne et si c'est pas trop spaghettis.

            Après il y'a aussi des trucs encore plus goret à coup de lancer des containers docker avec l'option --privileged et pleins de mounts locaux.

            • [^] # Re: Pourquoi se donner tant de mal ?

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

              Je suis de moins en moins d'accord avec cette vision des choses. Les mainteneurs connaissent la distrib et leur contrainte bien mieux qu'un dev, c'est évident. Les mainteneurs peuvent être plus à jour sur les problèmes de sécurité (sauf pour openssl…).

              Mais typiquement, j'ai un frein psychologique à mettre à jour ma distrib : je n'ai pas envie de perdre des jours à rependre un éventuel "epic fail" de mise à jour. Résultat, je me trouve avec un firefox obsolète, alors que son système d'upgrade est sécurisé. En tout cas, bien plus que de garder une vieille version, même en LTS.

              Peut-être que les mainteneurs devraient faire des packageurs automatiques, utiliser des conteneurs Dockers (sans doute la meilleur idée pour les applications serveurs ayant 12000 dépendances).

              Urpmi et autre yum ont montré la voix à suivre, mais Androïd et iOS ont montré une autre voie un peu plus souple (un "store" et une base qui se met à jour d'une autre façon).

              "La première sécurité est la liberté"

  • # Et la version clickable

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

    En trafiquant les fichiers .desktop pour faire passer une application pour ce qu'elle n'est pas.

    • [^] # Re: Et la version clickable

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

      Une autre preuve de concept de ma pomme: https://github.com/illwieckz/chaton-mignon ;-)

      Je m’en souviens qu’on en avait déjà parlé dans les commentaires d’un journal mais je ne retrouve pas…
      Il semble que désormais GNOME attend plus que le simple bit “exécutable” (mais je ne sais pas quoi) pour afficher correctement et lancer un fichier .desktop.

      ce commentaire est sous licence cc by 4 et précédentes

  • # Comportement d'Urxvt

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

    Justement, j'ai constaté depuis grosso modo un an un nouveau comportement d'Urxvt lorsque j'y colle du texte. Au lieu d'exécuter chaque ligne terminée par un retour à la ligne, il insère une commande multiligne, non encore exécutée, que je peux éditer puis valider en entier. C'est un peu comme si j'avais tout tapé à la main en mettant des \ avant chaque retour à la ligne.

    Je ne sais même pas comment il fait pour envoyer à mon shell des retours à la ligne non exécutants, mais ça a bien l'air d'une protection contre le copier-coller malicieux.

  • # Fish: le shell peut vous sauver

    Posté par  . Évalué à 4.

    Et bien fish est là pour vous. Quand je colle du texte, les retours chariot ne sont pas interprétés comme un envoi de commande : le texte va à la ligne. Et seulement quand je tape sur la touche Entrée, ça exécute.

    J'aime beaucoup.

    • [^] # Re: Fish: le shell peut vous sauver

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

      Bon, eh bien c'est exactement le comportement que je décris dans mon commentaire précédent, ce qui me laisse supposer qu'il vient de mon shell, Zsh, et non de mon terminal Urxvt.

      Reste la question : comment le shell peut-il savoir qu'il s'agit d'un collage de texte et non d'une saisie manuelle ?

      • [^] # Re: Fish: le shell peut vous sauver

        Posté par  (site web personnel, Mastodon) . Évalué à 5.

        Reste la question : comment le shell peut-il savoir qu'il s'agit d'un collage de texte et non d'une saisie manuelle ?

        Les 2 manières de détecter un copier/coller que je connais c'est soit détecter une grande quantité de caractères d'un coup (on n'écrit pas 100 caractères d'un coup à la main), soit via des échappements avec le bracketed paste mode.

        • [^] # Re: Fish: le shell peut vous sauver

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          et je viens de tester sur Konsole/Zsh, ça fait bien le comportement que vous décrivez (ça colle mais n'exécute pas, il faut valider avec [entrée]).

        • [^] # Re: Fish: le shell peut vous sauver

          Posté par  . Évalué à 2.

          Une solution plus fiable serait de définir un évènement que l'UI passe au shell pour indiquer que c'est un copié-collé.

          À ce moment, autant faire en sorte que ce soit standard pour tout le système, car probablement utile dans d'autres cas. Donc API supplémentaire pour que le programme destinataire indique qu'il sait/veut gérer.

      • [^] # Re: Fish: le shell peut vous sauver

        Posté par  . Évalué à 2. Dernière modification le 17 avril 2018 à 14:43.

        Les frappes claviers génèrent des évènements qui sont bien différents d'une opération de collage. Je n'ai jamais eu à gérer ce cas là cependant. J'ai cherché (un peu) dans le code de fish, mais sans succès…

        EDIT: En fait, effectivement, c'est probablement ce qu'a expliqué Goffi qui marche. Je ne sais pas si c'est possible de distinguer les deux sinon.

Suivre le flux des commentaires

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