Come evitare gli attacchi della sequenza di escape nei terminali?

Leggendo i dettagli di CVE-2009-4487 (che riguarda il pericolo di sequenze di escape nei file di registro) sono un po 'sorpreso.

Per citare CVE-2009-4487 :

nginx 0.7.64 scrive i dati in un file di registro senza disinfettare i caratteri non stampabili, il che potrebbe consentire agli aggressori remoti di modificare il titolo di una finestra o eventualmente eseguire comandi arbitrari o sovrascrivere i file, tramite una richiesta HTTP contenente una sequenza di escape per un emulatore di terminale.

Chiaramente, non si tratta in realtà di una falla di sicurezza in nginx, ma negli emulatori di terminale.

Certo, forse l' catimmissione di un file di registro nel terminale avviene solo per caso, ma grepl'inging un file di registro è abbastanza comune. lessforse disinfetta le sequenze di escape, ma chissà quali comandi della shell non cambiano le sequenze di escape ...

Tendo ad essere d'accordo con la risposta della vernice :

La saggezza delle fughe terminali di risposta in generale è stata messa in discussione a intervalli regolari, ma nessuno dei principali programmi di emulazione terminale ha ritenuto opportuno scartare queste sequenze, probabilmente in un tentativo errato di compatibilità con la tecnologia degli anni '70 non più utilizzata. [..] Invece di incolpare tutti i programmi che scrivono file di log, sarebbe molto più produttivo, dal punto di vista della sicurezza, far sì che i programmi di emulazione terminale smettano di fare cose stupide e quindi risolvere questo e altri problemi di sicurezza una volta e per tutti.

Quindi le mie domande:

Come posso proteggere il mio xterm, in modo tale che non sia più possibile eseguire comandi o sovrascrivere i file tramite sequenze di escape?

Quali emulatori di terminale per X sono protetti da questo attacco?

I terminali VT100 (che tutti i moderni emulatori di terminali emulano in una certa misura) supportano una serie di comandi problematici, ma i moderni emulatori o distribuzioni disabilitano quelli più problematici e meno utili. Ecco un elenco non esaustivo di sequenze di escape potenzialmente rischiose (non incluse quelle che rendono il display illeggibile in qualche modo):

• Il file di registro arbitrario comanda in rxvt ed Eterm riportati da HD Moore . Questi sono davvero importanti bug, fortunatamente risolti da tempo.
• Il comando di risposta, noto anche come Return Terminal Status, invocato da ENQ( Ctrl+E). Ciò inserisce il testo nel terminale come se fosse stato digitato dall'utente. Tuttavia, questo testo non è sotto il controllo dell'attaccante: è il nome del terminale, in genere qualcosa di simile a xtermo screen. Sul mio sistema (compressione Debian), xterm restituisce la stringa vuota di default (questa è controllata dalla answerbackStringrisorsa).
• I comandi Invia attributi dispositivo ESC [ ce amici. Il terminale risponde con ESC [ … c(dove …possono contenere solo cifre e segni di punteggiatura ASCII). Questo è un modo per interrogare alcune funzionalità del terminale, per lo più obsolete ma forse utilizzate da vecchie applicazioni. Ancora una volta, la risposta del terminale è indistinguibile dall'input dell'utente, ma non è sotto il controllo dell'attaccante. La sequenza di controllo potrebbe apparire come un tasto funzione, ma solo se l'utente ha una configurazione insolita (nessuna delle solite impostazioni che ho riscontrato ha una sequenza di escape del tasto funzione valida che è un prefisso della risposta del terminale).
• Le varie funzioni di controllo del dispositivo (DCS fuoriesce, a partire da ESC P).
  • Non so quale danno può essere fatto attraverso DECUDK(imposta chiavi definite dall'utente) su un tipico emulatore di terminale.
  • DECRQSS(Request Status String) è l'ennesimo comando a cui il terminale risponde con una sequenza di escape, questa volta a partire da \eP; questo può essere problematico poiché \ePè una chiave valida ( Alt+ Shift+ P).
  • Xterm ha altre due funzionalità sperimentali: ESC P + p …e ESC P + q …, per ottenere e impostare stringhe termcap. Dalla descrizione, questo potrebbe essere usato almeno per modificare l'effetto dei tasti funzione.
• Diversi comandi per il rapporto sullo stato: ESC [ … n(Rapporto sullo stato del dispositivo). Il terminale risponde con una sequenza di escape. La maggior parte di queste sequenze di escape non corrispondono alle sequenze di escape dei tasti funzione. Uno sembra problematico: il rapporto a ESC [ 6 nè della forma in cui sono e sono sequenze di cifre, e questo potrebbe apparire come con alcuni modificatori.ESC [ x ; y RxyF3
• Comandi di manipolazione delle finestre ESC [ … t.
  • Alcuni di questi consentono di ridimensionare, iconizzare, ecc. La finestra di xterm, che è dirompente.
  • Alcuni di questi fanno sì che il terminale risponda con una sequenza di escape. La maggior parte di queste sequenze di escape sembrano a basso rischio, tuttavia ci sono due comandi pericolosi: le risposte ESC [ 2 0 te ESC [ 2 1 tincludono rispettivamente l'etichetta e il titolo dell'icona della finestra del terminale e l'attaccante può sceglierli.
  • Almeno con Debian Squeeze, xterm ignora questi comandi di default; possono essere abilitati impostando la allowWindowOpsrisorsa o selettivamente tramite la disallowedWindowOpsrisorsa. Gnome-terminal in Ubuntu 10.04 implementa anche le risposte al titolo per impostazione predefinita. Non ho controllato altri terminali o versioni.
• Comandi per impostare il titolo del terminale o il nome dell'icona. Sotto xterm e la maggior parte degli altri terminali X, lo sono . Sotto Schermo, la sequenza di escape è . Trovo che la preoccupazione per questi comandi sia sopravvalutata. Mentre consentono una certa quantità di malizia, qualsiasi pagina web ha lo stesso problema. Agire su una finestra basata esclusivamente sul suo titolo e non sulla sua classe è come aprire un file il cui nome ti è stato dato da una parte non fidata, o non citare un'espansione variabile in uno script di shell, o dare una pacca sul naso a un cane rabbioso - non lamentarti se vieni morso.ESC ] digit ; title ESC \ESC k title ESC \

Trovo la risposta di Varnish disonesta. È come se stesse provando a spostare la colpa, o in modalità di sicurezza nazista (qualsiasi problema di sicurezza, genuino o no, giustifica il blackball di una caratteristica).

La saggezza delle fughe terminali di risposta in generale è stata messa in discussione a intervalli regolari, ma nessuno dei principali programmi di emulazione terminale ha ritenuto opportuno scartare queste sequenze, probabilmente in un tentativo errato di compatibilità con la tecnologia degli anni '70 non più utilizzata. (…)
Invece di incolpare tutti i programmi che scrivono file di log, sarebbe molto più produttivo, dal punto di vista della sicurezza, far sì che i programmi di emulazione terminale smettano di fare cose stupide, e quindi risolvere questo e altri problemi di sicurezza una volta e per tutti.

Molti dei feedback sono funzioni utili: un'applicazione ha bisogno di sapere cose come la posizione del cursore e la dimensione della finestra. Anche l'impostazione del titolo della finestra è molto utile. Sarebbe possibile fare affidamento interamente sulle ioctlchiamate per questi, tuttavia ciò avrebbe richiesto codice aggiuntivo e utilità per effettuare queste ioctlchiamate e tradurle in testo in stile unix passando i descrittori di file. La modifica di queste interfacce ora richiederebbe molto lavoro, con scarsi benefici.

I file di testo non devono contenere caratteri non stampabili come i caratteri di controllo. I file di registro sono generalmente considerati file di testo. I file di registro non devono contenere caratteri di controllo.

Se sei preoccupato che un file possa contenere sequenze di escape, aprilo in un editor o visualizzalo con lesssenza l' opzione -ro -Roppure visualizzalo cat -v.

Non è così semplice; molte persone hanno il codice per impostare il xtermtitolo come parte del prompt o ecc., e per ottime ragioni (come shutdownpuò dirti chiunque abbia la macchina sbagliata dalla finestra del terminale sbagliata!). Risolverlo correttamente implica quindi l'introduzione di contesti di sicurezza e quindi complicare seriamente l'interazione tra shell ed emulatori terminali e probabilmente anche dotfile delle persone. Oppure puoi andare con la soluzione a basso costo di sanificazione di tutto ciò che potrebbe essere visualizzato in un terminale; ciò si riduce in gran parte alla fuga di caratteri di controllo, che probabilmente dovrebbe essere fatto comunque solo per farli risaltare (poiché in un file di registro possono indicare qualcuno che sta cercando di iniettare shellcode).

(A parte questo, il codice di Punycode è un caso più grave dello stesso tipo di problema - ed è stato comunque reso uno standard ufficiale. A volte la sicurezza si riduce alla mitigazione di progetti insicuri che sono al di fuori del proprio controllo.)