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 freem . Évalué à 3.
Je suis tombé sur cette information en lisant ceci: https://lwn.net/Articles/749992/
# Déjà discuté ici
Posté par Renault (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 gouttegd . É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 :
[^] # Re: Pourquoi se donner tant de mal ?
Posté par Moonz . É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 gouttegd . É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 Matthieu Moy (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 Psychofox (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 :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 Nicolas Boulay (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é"
[^] # Re: Pourquoi se donner tant de mal ?
Posté par Psychofox (Mastodon) . Évalué à 1.
T'utilises quelle distro pour pas avoir de firefox à jour ? J'ai la 59.0.2 là sur ma distro.
# Et la version clickable
Posté par chimrod (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 Thomas Debesse (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 🚲 Tanguy Ortolo (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.
[^] # Re: Comportement d'Urxvt
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
J'ai remarqué la même chose, mais chez moi au moins c'est un comportement de zsh et pas du terminal (ça marche dans plusieurs terminaux avec zsh, mais pas avec bash).
[^] # Re: Comportement d'Urxvt
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Oui, pareil en fait, je m'avais trompé. :-)
# Fish: le shell peut vous sauver
Posté par Glandos . É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 🚲 Tanguy Ortolo (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 Goffi (site web personnel, Mastodon) . Évalué à 5.
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 Goffi (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 Kerro . É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 Glandos . É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.