Domanda:
Il "cat-ing" di un file può rappresentare un potenziale rischio per la sicurezza?
Ivan Kovacevic
2014-04-22 07:29:11 UTC
view on stackexchange narkive permalink

Uso spesso cat sulla console per visualizzare il contenuto dei file, e di tanto in tanto ho accidentalmente catato un file binario che fondamentalmente produce gibberish e beep di sistema. Tuttavia oggi ho riscontrato una situazione in cui l'output dell'utilità cat è stato reindirizzato all'input della console, quindi ho ottenuto cose come questa:

  -bash: 2c: command not found-bash: 1 : comando non trovato-bash: 1: comando non trovato-bash: 112: comando non trovato-bash: 112: comando non trovato-bash: 1: comando non trovato-bash: 0x1: comando non trovato-bash: 2c1: comando non trovato-bash: 2c: comando non trovato-bash: 1: comando non trovato-bash: 1: comando non trovato-bash: 112: comando non trovato-bash: 112: comando non trovato-bash: 1: comando non trovato -bash: 0x1: comando non trovato-bash: 2c1: comando non trovato-bash: 2c1: comando non trovato-bash: 2c1: comando non trovato-bash: 2c1: comando non trovato  

...
...

Questo mi ha fatto pensare che un file binario appositamente predisposto potrebbe creare un bel pasticcio nel sistema?! ... Ora mi rendo conto di usare cat in modo sconsiderato in questo modo non particolarmente intelligente, ma in realtà mi piacerebbe sapere cosa sta succedendo qui. Quali caratteri producono l'effetto di scaricare improvvisamente il contenuto sullo standard input ...

Nota: ero nel terminale Mac OS X mentre facevo questo, in realtà ho chiamato diff -a per confrontare due immagini rom del firmware e stampare le differenze (pensavo ci sarebbero stati solo pochi byte di differenze ma c'erano quasi 8 MB di differenze stampate sullo schermo) In seguito ho provato, apposta, a catare uno dei file e ho ottenuto lo stesso effetto che ho incollato qui.

- UPDATE - - UPDATE - - UPDATE -

L'ho postato qui ieri a tarda notte e questa mattina ho provato a replicare il comportamento e non ci riesco. Sfortunatamente non posso essere sicuro se alcuni caratteri di escape abbiano causato l'esecuzione automatica del gibberish dal binario sulla console o se alla fine del gatto mi sono rimasti un po 'di caratteri (come se li avessi incollati) sul riga di comando e probabilmente ho premuto invio accidentalmente per ottenere una riga chiara ...

Quando provo a cat il file in questione ora ottengo questo quando termina (scorri a destra per vedere):

  D? k (Fli9p? s? HT? 78 =! g ?? Ès3? &é ?? = ?? 7 ?? K? ̓Kü<ö ???? z (; ????? ?? j ?? > ?? ö? Ivans-MacBook-Pro: FI9826W-2.11.1.5-20140121 NA ivankovacevic $ 1; 2c1; 2c1; 2; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c; 1; 1; 112; 112; 1; 0x1; 2c1; 2c; 1; 1; 112; 112; 1; 0x1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1;  

Il mio prompt effettivo è:

  Ivans-MacBook-Pro: FI9826W-2.11.1.5-20140121 NA ivankovacevic $  

Dove:

  FI9826W-2.11.1.5-20140121 N A  

è l'attuale directory di lavoro. Come vedete era camuffata nel linguaggio binario senza senso e potrei aver premuto invio di riflesso o qualcosa del genere. Questo di per sé è un po 'sbagliato per il gatto perché ovviamente il mio suggerimento avrebbe potuto essere "mimetizzato" ancora meglio. Ma è meno grave di quanto pensassi inizialmente. Anche se non sono ancora sicuro al 100% che non sia stato eseguito automaticamente la scorsa notte quando ho provato, perché c'era anche un'altra cosa strana che è accaduta la scorsa notte, prima di questa. Ho chiamato cat su un altro file molto simile che ha causato la chiusura dell'app Terminal con:

  Tipo di eccezione: EXC_BAD_ACCESS (SIGSEGV) Codici di eccezione: KERN_INVALID_ADDRESS su 0x00007fcb9a3ffffa  

Ora sto pensando che forse una combinazione di questi due eventi ha causato l'esecuzione automatica di parole incomprensibili sulla console. Ma non posso replicare di nuovo quel comportamento.

I file in questione sono firmware per una telecamera IP Foscam, ecco i link:

Sito internazionale: http://foscam.com/Private/ProductFiles/FI9826W-2.11.1.5 -20140120.zip
E poi il file all'interno: FI9826W_app_ver1.11.0.40_OneToAll.bin”

chiamando cat su quello farà chiudere Terminal.

Sito USA: http://foscam.us/downloads/FI9826W-2.11.1.5-20140121%20NA.zip
e quindi il file: FI9826W_app_ver1. 11.0.40_OneToAll_A.bin

cat-ing quello causerà quella pasta di 1; 2c1; 2c1; 2; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c1; 2c. ... caratteri sulla riga di comando

Ah, quei ricordi confortanti di un tempo in cui le bombe ANSI erano in giro e ampiamente conosciute ...
Sette risposte:
#1
+60
mr.spuratic
2014-04-23 02:38:43 UTC
view on stackexchange narkive permalink

, è 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  
Buoni collegamenti! Ecco alcuni specifici di Apple http://www.cvedetails.com/cve/CVE-2005-1341/ o http://www.cvedetails.com/cve/CVE-2009-1717/ e probabilmente ce ne sono altri .. .
Fantastico aggiornamento! Hai detto "L'attuale versione di un popolare emulatore di terminale ha questo problema", puoi condividere con noi quale emulatore di terminale è? E chi ha scoperto la vulnerabilità? Tu? Amico di un amico?
Ho trovato il problema oggi (durante la ricerca di stringhe di formato interessanti), nessun nome o dettaglio fino a quando non viene coordinato con gli autori.
Lo rispetto totalmente! Spero comunque che aggiorni le informazioni quando gli autori avranno fornito la correzione. E btw. il tuo ultimo aggiornamento alla fine, che spiega i caratteri che ho ricevuto, è superbo. Grazie! La tua risposta è la mia preferita per ora ...
Andrà bene. La mia risposta speculativa (nessuna macchina OS X a portata di mano) sul segfault è stata trattenuta per lo stesso motivo.
Dannazione, muoio dalla curiosità ora per entrambe le cose. Farebbe un http://i.imgur.com/eNoBclw.jpg? :)
Sono in contatto con gli autori, aggiornerò presto la risposta con i dettagli promessi.
#2
+47
F. Hauri
2014-04-22 10:40:37 UTC
view on stackexchange narkive permalink

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 , 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 :

  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

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.

Oh? Ti interessa condividere i dettagli? Nella misura in cui è vero, questa è una vulnerabilità di sicurezza critica nell'emulatore di terminale.
Questo è il motivo per cui alcune delle sequenze di escape ANSI sono generalmente disabilitate nei terminali / emulatori moderni.
gatto -e, buon consiglio! Sono ancora interessato se potresti forse espandere la tua risposta con un esempio di quelle sequenze di escape per modificare il buffer della tastiera che potrebbe spiegare questo.
Quando digito `man cat` tutto quello che vedo è che` -e` è "equivalente a -vE", ma nessuna informazione è data su -vE ...
La convenzione è che i flag di un singolo carattere possono essere raggruppati insieme, quindi `-vE` è uguale a` -v -E`. cioè, la pagina man ti dice di guardare la documentazione per i flag `-v` e` -E` che significano "mostra caratteri non stampabili usando" ^ "e" M-"notation" e "Mostra le terminazioni di riga come rispettivamente un "$" carattere ".
@F. Hauri: Grazie per l'addendum. Tuttavia, come ho già accennato nel commento alla risposta di dr jimbob, nella sequenza ESC-Z del terminale di Mac OS X non viene emesso altro che una nuova riga. CSI-ESC-Z ottiene quel "1; 2c". CSI è Control Sequence Introducer: ASCII ottale 33 (ESC) + parentesi quadra sinistra. Quindi la sequenza di escape completa che funziona per me è: echo $ '\ 033 [\ 033Z'. L'ho scoperto semplicemente guardando il file del firmware, non l'ho trovato documentato da nessuna parte ...
@IvanKovacevic - `echo -e '\ x1BZ'` funziona in Mac OS X 10.9 (così come linux), Terminal 2.4, con le mie impostazioni di terminale predefinite (dichiarate come xterm-256color, non consentire l'applicazione VT100).
@dr jimbob: Hai ragione! Ma sta succedendo qualcosa di strano su Mac (OS X 10.9.2, xterm-256color) ed è per questo che l'ho visto come se non funzionasse. Quando digito echo -e '\ x1BZ' per la prima volta ... funziona. Se poi premo il tasto su per ottenere l'ultimo comando utilizzato e lo emetto di nuovo, non funziona più (viene stampata solo una nuova riga). Quindi solo dopo un po 'di tempo, dopo aver digitato molti altri comandi regolari, riprende a funzionare! Davvero strano ... l'ho provato anche adesso su Linux, e funziona sempre!
Per riferimento, PuTTY per impostazione predefinita risponderà a un Control-E con la stringa "PuTTY" (ma puoi fargli dire qualcos'altro se vuoi). Il che non è davvero un problema di sicurezza a meno che qualcuno non ascolti la tua connessione o inserisca roba ... nel qual caso, se è la tua macchina, hai già problemi molto più grandi di qualcuno che sa che usi PuTTY.
Grazie F. Hauri per la tua risposta! Ci hai messo un grande impegno! Ma alla fine ho dovuto scegliere e mr.spuratic ha anche fornito una risposta eccellente. Tutto sommato, credo che sarai felice di tutti i voti positivi premiati!
Hmmm sono d'accordo, la risposta di @mr.spuratic è ricca. Ma porto strumenti utilizzabili per rendere i test più facili, (spero che tu l'abbia provato) ... Comunque ho ottenuto la mia prima medaglia d'oro \ @SO con questa risposta! Quindi va bene! ;-). (P.S: In caso di problemi con la funzione, forse giocare con il parametro timeout (`-t .01`) potrebbe aiutare)
wow, un distintivo d'oro! L'ho appena notato. Congratulazioni! :) Te lo meriti. Come ho già detto, ho visto lo sforzo (in più iterazioni) che hai messo in questa risposta. Il tuo codice di test è davvero intelligente! Ho avuto difficoltà a decidere le risposte e volevo premiare sia la tua che quella di mr.spuratic. Visto che hai già ottenuto così tanti voti positivi (il mio compreso ovviamente). Premiare la risposta di mr.spuratic con la taglia e la bandiera accettata sembrava la cosa migliore per ristabilire l'equilibrio nell'Universo! ;-)
C'è un modo per disabilitare tale comportamento in modo che non cambi accidentalmente il mio guscio durante il bestiame?
Non proprio, ma potresti usare molte implementazioni di terminali differenti. XTerm può essere commutato tra le modalità * vt100 * e * tektronix *, che hanno sequenze di controllo di manipolazione delle finestre completamente diverse.
Ironia della sorte, xterm è probabilmente il meno sicuro di quelli tradizionali, e ha _molto_ più "funzionalità" della maggior parte (funzionalità legacy di cui non avrete mai bisogno ma che sono ancora presenti, come il supporto per certi hardware della vecchia scuola).Per non parlare del fatto che molti emulatori di terminale (come rxvt e urxvt) sono solo fork di xterm.
#3
+7
JasperWallace
2014-04-22 13:30:57 UTC
view on stackexchange narkive permalink

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  
`" contenuto dello schermo corrente al suo stdin "` - il contenuto dello schermo non è stdin.
@Ruslan: Indica lo stdin del comando a cui vengono reindirizzati i contenuti dello schermo.
Quindi dovrebbe essere "suo" non "è"
@JasperWallace: Informazioni interessanti! Esempi: Per ridurre a icona Terminal.app: echo -e '\ x1B [2t' Per ridurre al minimo-massimizzare l'eco -e '\ x1B [2t \ x1B [5t' :)
#4
+6
tylerl
2014-04-22 08:38:13 UTC
view on stackexchange narkive permalink

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.

In questo caso ho appena digitato: cat . Quindi non ho incollato qualche comando fasullo nella console, ma ho controllato il mio aggiornamento alla domanda che ho appena scritto.
#5
+4
dr jimbob
2014-04-23 02:40:12 UTC
view on stackexchange narkive permalink

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  
In realtà echo -e '\ x1BZ' nel mio caso stampa solo una riga vuota. Tuttavia echo -e '\ x1B [\ x1BZ' stampa quel "1; 2c" sulla riga di comando che stavo ottenendo ripetutamente dopo aver inserito il file binario del firmware. Questa è e [che è conosciuta come sequenza di escape, seguita da Z. Tuttavia non ho idea di cosa significhi 1; 2c. Quello è l'ID del terminale ?!
@IvanKovacevic Sì, vedere il mio * addendum *. (La mia prima risposta è stata troppo rapida. Scusa;)
@dr jimbob: Non avevo ragione, echo -e '\ x1BZ' funziona, ma ha qualche strano comportamento su Mac OS X. Se lo emetto per la prima volta ed elimino i caratteri emessi, premi Invio per ottenere un nuovo prompt chiaro (Perché l'eco che lascia un po 'di incomprensioni anche davanti alla riga del prompt, o sul retro, dipende da come la si guarda). Quindi se provo a richiamare l'ultimo comando con il tasto su, e lo richiamo di nuovo, non funziona più ... Viene stampata solo una nuova riga. Questo è il motivo per cui inizialmente pensavo che non funzionasse, perché l'ho già chiamato ... Su Linux funziona indipendentemente ogni volta.
Ed anche echo -e '\ x1B [\ x1BZ' funziona ogni volta. Suppongo che la sequenza CSI lo resetti.
`alias clear =" echo -e '\ ec' "" Infine, un * clear * in cygwin <3
#6
+4
Ivan Kovacevic
2014-04-23 09:20:20 UTC
view on stackexchange narkive permalink

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

#7
-1
paul
2014-04-23 15:42:41 UTC
view on stackexchange narkive permalink

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.

Inviare un file casuale a un interprete (cioè bash) è, ovviamente, estremamente pericoloso. Ma non è quello che stiamo discutendo qui. Mostrare solo contenuti, con cat, che come la storia ha dimostrato PUO 'produrre danni. Controlla la risposta di mr.spuratic.
Per aggiungere alla risposta di paul, è stato detto molte volte, ma le vecchie abitudini sono dure a morire: non usare cat per questo, usa meno o un editor di testo.


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