Sì , è un rischio potenziale, vedere CVE-2003-0063 o CVE-2008-2383 o CVE- 2010-2713, o CVE-2012-3515 o OSVDB 3881 o CVE-2003-0020 o qualcosa di simile quelli elencati qui... Altri ancora nei commenti qui sotto.

Aggiornare non è solo un potenziale rischio, è un rischio reale . rxvt-unicode (versioni 2.7—9.19, con patch 9.20) consente l'accesso in lettura / scrittura alle proprietà della finestra X, questo può abilitare l'esecuzione assistita dall'utente di comandi arbitrari, questo problema è stato assegnato CVE -2014-3121, maggiori dettagli qui https://bugzilla.redhat.com/show_bug.cgi?id=1093287.

Più di recente (ottobre 2019) iTerm2 versioni fino alla v3.3.5 hanno riscontrato la stessa classe di problemi: la visualizzazione di contenuti dannosi può abilitare il comando integrato tmux e di autorizzazione esecuzione, vedere CVE-2019-9535.

Anche questo argomento ha una buona copertura qui: https://unix.stackexchange.com/questions/73713/how- safe-is-it-to-cat-an-arbitrary-file e un'analisi approfondita del problema sottostante da Gilles qui: https://unix.stackexchange.com / questions / 15101 / come-evitare-sequenze-di-fuga-attacchi-nei-terminali.

Spiegazione

Ciò che stai osservando è un lato -effetto di come si comportano certe sequenze di escape: alcune di inseriscono i caratteri (di solito contenenti anche sequenze di escape) direttamente nel buffer di input del terminale . Tutto in nome della retrocompatibilità, ovviamente. Gli standard xterm escapes che sono descritti usando il termine "Report <something>" fanno questo. Questo comportamento consente ai programmi di interrogare / impostare le proprietà del terminale (o altre) " in banda" piuttosto che tramite ioctls o qualche altra API.

Come se ciò non bastasse, alcune di queste sequenze possono contenere una nuova riga , il che significa che qualunque cosa stia leggendo dal terminale (la tua shell) vedrà quello che sembra essere un comando utente completo .

Ecco un modo pulito per usarlo, con read di bash per stampare un escape (come prompt), quindi leggere immediatamente e dividere la risposta in variabili:

  IFS = ';' leggi -sdt -p $ '\ e [18t' csi8 righe colsecho righe = $ righe cols = $ cols  

Queste sequenze possono variare in base al terminale, ma per rxvt e derivato, l'escape della query grafica include una nuova riga (esempio utilizzando le stringhe bash e $ '' , vedere doc / rxvtRef. txt nel sorgente) `:

  $ echo $ '\ eGQ' $ 0bash: 0: comando non trovato  

Questo escape invia \ 033G0 \ n nel buffer di input del terminale (o digita 1 invece di 0 se disponi di un rxvt ).

Quindi, combina questo escape con altre sequenze che si comportano in modo simile:

  echo $ '\ x05' $ '\ e [>c' $ '\ e [6n '$' \ e [x '$' \ eGQ ' 

per me questo causa 11 tentativi di eseguire vari comandi: 1 , 2c82 , 20710 (la mia stringa di versione rxvt ), 0c5 , 3R (5 e 3 erano i coordinate del cursore), 112 e 0x0 .

Sfruttabile?

Con rxvt e gli emulatori di terminale più recenti dovresti essere "solo" in grado di creare un insieme limitato di sequenze per lo più numeriche. Nei vecchi emulatori di terminale era possibile (alcuni CVE elencati sopra) accedere agli appunti, all'icona della finestra e al testo della barra del titolo per costruire più stringhe dannose per l'invocazione (una piccola eccezione attuale è se si imposta la answerbackString X stringa della risorsa, ma non può essere impostata direttamente utilizzando questo metodo). Il difetto quindi è consentire l'accesso arbitrario in lettura e in scrittura a qualcosa che passa per lo stato o l'archiviazione all'interno di sequenze di escape che inseriscono i dati nel buffer di input.

rxvt richiede modifiche in fase di compilazione per l'attivazione, ma urxvt ha utilmente un'opzione della riga di comando -insecure che abilita alcune delle funzionalità più interessanti:

  $ echo $ '\ e] 2 ;; uptime; \ x07' $ '\ e [21 ;; t' $ '\ eGQ' bash: l: comando non trovato17: 59: 41 fino a 1448 giorni, 4:13, 16 utenti, caricamento medio: 0,49, 0,52, 0,48 bash: 0: comando non trovato  

Le tre sequenze sono:

1. \ e] 2; ... \ x07 imposta il titolo della finestra;
2. \ e [21 ;; t titolo della finestra della query, posto nel buffer di input;
3. \ eGQ capacità di query grafica, che aggiunge \ n al buffer di input.

Di nuovo, a seconda terminale, altre funzionalità come la dimensione del carattere, i colori, la dimensione del terminale, il set di caratteri, i buffer dello schermo alternativi e altro possono essere accessibili anche se sfugge. La modifica involontaria di questi è almeno un inconveniente, se non un vero e proprio problema di sicurezza. Le attuali versioni di xterm limitano le funzionalità potenzialmente problematiche tramite le risorse "Consenti *".

CVE-2014-3121

Prima della v9.20, urxvt non proteggeva anche l'accesso in lettura e scrittura alle proprietà X ( utilizzato principalmente dai gestori di finestre). Scrittura l'accesso in lettura (o più precisamente, l'accesso a sequenze che echeggiano stringhe potenzialmente arbitrarie) ora richiede l'opzione -insecure .

  $ echo $ '\ e] 3; xyzzy = uptime; date +% s; \ x07' $ xprop -id $ WINDOWID xyzzyxyzzy (UTF8_STRING) = 0x75, 0x70, 0x74, 0x69, 0x6d, 0x65, 0x3b, 0x64, 0x61, 0x74, \ 0x65, 0x20, 0x2b, 0x25, 0x73, 0x3b  

Questo può essere usato banalmente per inserire stringhe arbitrarie nel buffer di input del terminale. Quando viene invocata la sequenza di escape per interrogare una proprietà (insieme all'utile \ eGQ che aggiunge una nuova riga):

  $ echo $ '\ e] 3;? Xyzzy \ x07 '$' \ eGQ '$ 3; uptime; data +% s; 0 bash: 3: comando non trovato 17:23:56 su 1474 giorni, 6:47, 14 utenti, caricamento medio: 1,02, 1,20, 1,17 1400603036 bash: 0: comando non trovato  

Comandi multipli, preservando spazi bianchi e metacaratteri della shell. Questo può essere sfruttato in una varietà di modi, iniziando con il cat-ing di un binario non attendibile, ovviamente, ulteriormente idee in HD Short paper di Moore (2003).

Followup

Per la sequenza di escape chiedi su: 1; 112; 112; 1; 0x1; 2 Questo è: Richiedi parametri del terminale (DECREQTPARM) e Invia attributi del dispositivo :

  $ echo $ '\ e [ x '$' \ e [0c '; 1; 1; 112; 112; 1; 0x1; 2c  

Il secondo ( \ e [0c ) è uguale a ^ E (utilizzando rxvt ). Ci sono anche alcune sequenze di fuga. la sequenza completa scritta per ciascuno è, rispettivamente:

  \ e [1; 1; 1; 112; 112; 1; 0x \ e [? 1; 2c  

Sì.

Nuovo add 2020-01-25:

Da tempo sono passato da LATIN-1 codifica in UTF-8 come codifica predefinita nella maggior parte dei miei sistemi, ho trovato alcune caratteristiche interessanti intorno a questo ( ora ci sono due lunghezze per una stringa) ...

Per esempio, dato che mi piace giocare con bash , ho chiesto perché la localizzazione bash non funziona con le stringhe multilinea. Questa funzionalità di bash rappresenta un bug, in cui la soluzione consiste nell'usare eval . Se questo non è un difetto di sicurezza , potrebbe diventarlo o produrne uno ...

In ogni evoluzione di quasi tutto (linguaggi, librerie, strumenti, protocolli, applicazioni, hardware, installatori , console, ecc ...) includono nuove funzionalità, con potenziali nuovi bug ...

Fortunatamente, sono pochi perché vengono rapidamente corretti (quasi un giorno da rivelare), ma lo sono!

Quindi decisamente sì, stai attento!

Uso corretto del comando cat .

Come tu sembra che stia utilizzando un moderno emulatore di terminale , alcune sequenze di escape potrebbero essere utilizzate per modificare il buffer della tastiera .

Potrebbero essere stati inseriti dei comandi shell appropriati.

Potresti usare l'argomento -e di cat per operazione sicura, vedere man cat .

  -e equivalente a -vE -E, --show-end mostra $ alla fine di ogni riga -v , --show-nonprinting usa ^ e M- notation, eccetto LFD e TAB  

block quote>

Quindi

  cat -e suspectfile.rawcat -e suspectfile.raw | less  

o sotto bash:

  less < < (cat -e suspectfile.raw)  

o anche

  quale meno cat / usr / bin / less / bin / catrawless () {/ usr / bin / less < < (/ bin / cat -e "$ @ ");}  

Addendum

In effetti, era possibile , in passato ... Poiché questo è diventato un problema, questo tipo di funzionalità è stato rapidamente rimosso , ma ...

Quando leggi comando non trovato , questo implica che qualcosa è stato effettivamente iniettato.

La iniezione principale la caratteristica che non è stata rimossa è la sequenza identifica te stesso , utilizzata in molti incapsulamenti di VT-100.

Questa sequenza è Escape Z che inietterà la stringa 1; 2c nel buffer della tastiera, che significa VT-100 (nella convenzione AVO).

Parlando di cat , potresti provare:

  cat <<< $ '\ 033Z'  

e avanti riga richiesta, vedrai 1; 2c (o forse con altri numeri, a seconda del terminale utilizzato) come se li avessi premuti.

.. . e

  cat -e <<< $ '\ 033Z' ^ [Z $  

Dove -e = > -vE , -v trasforma \033 in ^ [ e -E mettono un segno $ alla fine della riga (e nulla verrà inserito nella riga successiva, buffer della tastiera non è interessato).

Potresti trovare molte cose divertenti nella Guida per l'utente di VT100 (come: cat <<< $ '\ 033 # 8 ';)

(Erano terminale moderno ! In qualche passato ...)

Provando a usare bash

C'è un piccolo comando bash per svuotare il buffer della tastiera e ottenere il suo contenuto:

  cat <<< $ '\ 033Z'; buf = ''; while read -t .1 -n 1 chr; do buf + = "$ chr"; done; printf "\ n> |% q | < \ n "$ buf ^ [[? 1; 2c> | $ '\ E [? 1; 2c' | <  

E una piccola funzione per testare qualsiasi catena:

  trySeq () {printf -v out "$ 1" echo -n "$ out" buf = "" durante la lettura -t.1 -n1 char do buf + = "$ char" fatto
["$ buf"] && printf "\ r |% q | -> |% q | < \ e [K \ n" "$ out" "$ buf"}  

Quindi Potrei provare:

  for seq in $ '\ e [' {c, {1..26} {n, t, x}}; do trySeq "$ seq"; done | $ '\ E [c' | -> | $ '\ E [? 65; 1; 9c' | < | $ '\ E [1x' | -> | $ '\ E [3; 1; 1; 120; 120; 1; 0x '| < | $' \ E [5n '| -> | $' \ E [0n '| < ...  

(forse con qualche effetto sul tuo console)

Esempio per divertimento

Immagina, alcuni potrebbero inserire qualcosa del genere nel tuo ambiente:

  $ source < (printf '% dc ( ) {printf "Sei stato colpito \\ 041 \\ n";}; \ n '{0..100})  

Da lì, se tu

  $ cat <<< $ '\ e [c' $ 65; 1; 9c_  

Il cursore rimarrà alla fine della riga del prompt dei comandi. Da lì, se premi meccanicamente Invio invece di Ctrl c , leggerai qualcosa del tipo:

  $ 65; 1; 9cbash: 65: comando non trovatobash: 1: comando non trovato Sei stato colpito! $ _  

E ora?

Da lì, sfortunatamente, non esiste uno standard.

Ogni terminale virtuale potrebbe supportare lo standard ANSI completo e / o DEC completo ...

Ma poiché ci sono alcuni problemi di sicurezza, molti non lo fanno ...

Potresti osservare un comportamento usando un terminale che non osserveresti usando un altro ...

xterm, linux console, gnome-terminal, konsole, fbterm, Terminal (Mac OS) ... l ' elenco di emulatori di terminale non è così breve!

E ognuno di essi ha i propri bug e limitazioni rispetto agli standard DEC e ANSI.

In accordo, potresti trovare qualche console virtuale che potrebbe essere più in primo piano di altre e dove l'iniezione da tastiera potrebbe violare la tua sicurezza.

È una dei motivi perché preferisco usare sempre lo stesso (vecchio) xterm piuttosto che altri strumenti più presenti.

I terminali di vetro "reali" avevano una sequenza di escape per stampare lo schermo su una stampante. Lo hanno fatto eseguendo un comando e reindirizzando il contenuto della schermata corrente allo stdin del comando print.

Il comando potrebbe essere configurato da un'altra sequenza di escape.

Il modo classico di sfruttare questo era per creare file con nomi che incorporassero la sequenza di escape per impostare il comando della stampante e cambiarlo in uno script di tua scelta e quindi avere un secondo file con la sequenza di escape di stampa al suo interno.

Quando qualcuno allora eseguito ls in quella directory, avrebbero finito per eseguire il codice. Il che era carino se fosse l'utente root !

In teoria i moderni emulatori di terminale non dovrebbero più fare quel genere di cose.

Terminal.app sembra essere basato sul NextStep nsterm, quindi potrebbe contenere tutti i tipi di stranezze.

Forse provare a restringere i byte esatti che producono i messaggi comando non trovato ?

Sembra che ci siano sequenze di escape per alzare e abbassare il terminale:

http://the.taoofmac.com/space/apps/Terminal

qualche altra informazione qui:

http://invisible-island.net/ncurses/terminfo.src.html#toc-_Apple__Terminal_app

Se vuoi inviare il contenuto allo stdin di un programma,

  programma -para meter < /path/file.ext  

In genere non c'è vulnerabilità, ma ovviamente se la usi in modo sbagliato, potresti crearne una.

La stampa del contenuto di un file binario produce segnali acustici perché il carattere 7 è il vecchio comando del terminale per far suonare la macchina, e alcuni programmi del terminale continuano ad accettare quel comando. Ma in base alla progettazione, non c'è niente che possa ferirti. Nel peggiore dei casi, apri semplicemente una nuova finestra di terminale per annullare qualsiasi pasticcio che potrebbe essere stato creato.

Ora, se in qualche modo hai reindirizzato il contenuto di un file a una shell dei comandi, questa è un'altra questione. Puoi farlo trasferendo l'output di qualcosa a / bin / bash (tipicamente disapprovato dal punto di vista della sicurezza) o potresti averlo copiato e incollato inavvertitamente nel tuo terminale. Anche tipicamente sconsiderato.

Ma finché non gestisci la cosa, stai bene.

Quello che stai vedendo sono sequenze di controllo xterm.

Le sequenze di controllo vengono attivate quando vengono visualizzate in output nel terminale; ad esempio, quando cat un file con byte che sono ASCII non stampabili.

Nel tuo esempio, la sequenza di controllo è ESC Z (byte 1B 5A ) che restituisce l'ID del terminale - come comando nel terminale.

Puoi provarlo tu stesso:

  echo -e '\ x1BZ'  

(In alternativa puoi scrivere ESC come \ e o Z come \x5A).

Ce ne sono anche altri divertenti:

  echo -e ' \ eF '# sposta il prompt in fondo al terminale.echo -e' \ ec '# Reimposta il terminale  

Aggiungerò queste informazioni qui senza la reale intenzione di rispondere alla mia domanda. I caratteri che possono essere iniettati sulla riga di comando durante la stampa di altri caratteri, meglio conosciuti come sequenze di escape, sono definiti davvero buoni su questo sito ( Grazie F. Hauri , per averlo menzionato):
http://vt100.net/docs/vt100-ug/chapter3.html

Nel capitolo: Reports”

Rapporto sulla posizione del cursore

Richiamato da ESC [ 6 n
La risposta è ESC [Pl; Pc R
Pl = numero di riga; Pc = numero colonna

Rapporto sullo stato

Richiamato da ESC [5 n
La risposta è ESC [0 n (terminale ok)
ESC [3 n (terminale non ok)

Cosa sei

Invocato da ESC [c o ESC [0 c
La risposta è ESC [? 1; Ps c

Ps è il parametro "opzione presente" con il seguente significato:

Significato Ps
0 Base VT100, nessuna opzione
1 Opzioni del processore (STP)
2 Opzione video avanzata (AVO)
3 AVO e STP
4 Opzione processore grafico (GPO)
5 GPO e STP
6 GPO e AVO
7 GPO, STP e AVO

Richiamato in alternativa da ESC Z (non consigliato). La risposta è la stessa.

ESC è 27 decimale ASCII o 33 ottale o 1B esadecimale.

Quindi per ottenere ad esempio la posizione corrente del cursore stampata out, o meglio detto iniettato nella tua riga di comando esistente, dovresti chiamare:

  echo -e '\ 033 [6n'  

e l'output sarebbe essere qualcosa del genere:

  7; 1R  

Puoi spostare la posizione del cursore con la seguente sequenza di escape

  echo -e '\ 033 [10; 20H'  

10 - riga 10
20 - colonna 20

Tuttavia non sposta la posizione della colonna (lo fa spostarsi tra le righe) perché il terminale probabilmente lo reimposta all'inizio della riga. Ad ogni modo, se interroghi la posizione del cursore subito dopo, "incollerà" sulla console la posizione della colonna impostata:

  echo -e '\ 033 [10; 20H \ 033 [6n'  

output:

  0; 20R  

È così che puoi ottenere diversi output iniettati ('incollati') sulla console, è lontano da qualsiasi vero exploit poiché questo darà solo diverse combinazioni di numeri che possono essere emesse, ma poi di nuovo forse combinate con qualcos'altro. Chissà.

Nel mio caso in cui ho cat-cato l'immagine del firmware ne ho ottenute molte: 1; 2c Ora so che è il "Cosa sei" rapporto, di quello che è il mio terminale, dove 2 significa: Opzione video avanzata (AVO).

Tutto sommato è decisamente meglio evitare di catturare senza pensare qualsiasi file ...
Come già suggerito ( anche da F. Hauri ), utilizza almeno cat -e

Ci sono ovvi rischi nel convogliare un file casuale a un interprete di qualsiasi tipo, ma unix non è impostato per proteggere gli utenti dalla loro stessa stupidità. Il semplice utilizzo di cat filename potrebbe rovinare la visualizzazione, ma non dovrebbe danneggiare nulla.

Se utilizzi cat per visualizzare i file e identificarne il tipo Suggerirei di conoscere file (ti dice qual è il file) e less che ti avviserà se stai guardando dati binari e non scaricherà un Archivio di installazione da 100 MB sulla tua console. zless aprirà in modo trasparente i file gzip.