Perché la capacità di definire funzioni in una variabile ambientale non costituisce di per sé un rischio per la sicurezza?

A quanto mi risulta, generalmente è considerato sicuro consentire a chiunque di fornire informazioni che verranno archiviate in una variabile ambientale. La vulnerabilità di shellshock è un problema qui perché significa che il codice alla fine della definizione di una funzione all'interno di una variabile ambientale verrà eseguito all'avvio di una nuova istanza di bash e ovviamente non vuoi che nessuno esegua il codice che preferisce sul tuo server . Le definizioni delle funzioni non sembrano tuttavia costituire un rischio per la sicurezza e sono consentite perché devono essere esplicitamente chiamate per l'esecuzione del loro codice.

La mia domanda è: perché non può un utente malintenzionato semplicemente definire una funzione, contenente il loro codice maligno come un comando comune come lse poi sperare che lo script (o tutto ciò che è in esecuzione) utilizzerà questo comando ad un certo punto?

Un esempio di ciò che ho in mente:

$ export ls='() { echo "doing bad things..."; }'
$ bash -c ls
doing bad things...

È un rischio per la sicurezza. Questo è generalmente il motivo per cui non è possibile farlo quando si passa a un altro contesto (controllo remoto di un sistema, cambio utenti, ecc.).

Se hai la possibilità di creare qualsiasi variabile d'ambiente che desideri, ci sono un numero qualsiasi di potenziali modi in cui puoi eseguire codice arbitrario.
Prendi $LD_PRELOADcome esempio. Se hai la possibilità di impostare quella variabile, puoi sostituire le funzioni di libreria e inserire il tuo codice. È possibile impostare la $DISPLAYvariabile e reindirizzare la visualizzazione X a cui si connette il programma in modo da ottenere il controllo dell'app.

Ecco perché cose come sudoeliminare l'ambiente di tutte le variabili. sudoconsente solo alcune variabili selezionate attraverso. E di quelle variabili, le disinfetta (passa attraverso la $TERMvariabile, ma non lo farà se contiene caratteri insoliti).

Direi che lo è, quando bash è il tuo / bin / sh. Non è una caratteristica della shell bourne, e scommetto che non è nemmeno una caratteristica della shell posix, in realtà potrebbero volerlo proibire espressamente.

Bash è davvero più una shell derivata di Korn, che una shell bourne, nonostante il suo nome, ed è l'unica shell simile a Korn che ha la caratteristica, e secondo me è la funzione di kitchensink che non ha virtù pratiche. Gli sviluppatori che evitano le funzionalità bash per gli standard, come la shell bourne, la shell posix o il sottoinsieme ksh88 che le shell moderne hanno in comune, o in altre parole, si sono impegnati con le buone pratiche e gli idiomi standard, sono scioccati quando il loro software è attivo Linux e Mac e ora potenzialmente vulnerabili, poiché gli autori dell'exploit sono liberi di usare i "bashismi", nonostante le loro intenzioni. Per quanto riguarda la compatibilità migliorata, quando viene invocata come / bin / sh, su altri derivati ​​della shell korn, è solo se / bin / sh è la shell di accesso o shell interattiva, quando bash si comporta più come una shell bourne, che una shell korn,

Cercherò di convincerti che è la funzione lavello della cucina, con 2 casi: sei uno sviluppatore incorporato, che crea dispositivi come router, env di archiviazione di rete 1 ° più grande, significa più memoria, quindi, più costi, quindi meno profitti, quindi, se questo fosse un motivo per considerare l'uso di questa funzionalità di bash, non dovresti invece usare FPATH e autoload, invece le funzionalità di ksh88? invece di passare l'intero byte di funzione per byte nell'ambiente? Potresti anche considerare l'analisi e la potatura dell'ambiente all'ingrosso, prima che arrivi a uno shellscript che potrebbe erroneamente analizzare una variabile, come semplicemente filtrare ^ $ (. *) $, E simili ...

Ciò sottolinea ciò che è unico al riguardo, non importa quale sia la variabile e lo script non deve fare riferimento o utilizzare la variabile, potrebbe comunque essere vulnerabile.

#!/bin/sh
exec /usr/local/myapp/support/someperlscript.pl

Per qualsiasi altra cosa sotto il sole, quanto sopra dovrebbe essere sicuro come lo script perl, non stai usando le variabili come potresti farne un'analisi errata? Passare a

#!/bin/bash -norc
exec /usr/local/myapp/support/someperlscript.pl

Non aiuta neanche, questo non aveva nulla a che fare con ENV o qualcosa del genere - tutti vengono bruciati perché bash deve essere unico. Il fatto che bash la versione 2 presenta il problema, mi dimostra che nessuno ha mai utilizza questa funzionalità per le loro applicazioni, perché altrimenti dovrebbe non avere agguato intorno a questo tempo. E quel che è peggio, in pratica non si può evitare questa funzione . Ecco un esempio con: con 'su -', che se chiedessi a qualcuno, la spiegazione sarebbe che scarta l'ambiente, controlla la pagina man e troverai solo il 99,9%. Ho provato nel modo giusto, poiché su questo sistema / bin / sh è la shell di login di root e / bin / sh è bash MA , in questo esempio provoper rafforzare il mio .bash_profile. Ho rinominato il mio esistente per root (che è abilitato), ma il mio pensiero era se su, quindi eventualmente sudo, comunque, sono cambiato in questo:

exec env -i TERM=vt102 LOGNAME=root USER=root HOME=/var/root /bin/ksh -i

Quindi, sto effettivamente lanciando l'ambiente completamente, e uso un ambiente minimo, e quindi eseguendo una shell che non dovrebbe avere il problema, al posto del processo corrente. Quindi al posto dell'esempio standard prova:

%dock='() { echo -e "\e[2t\c"; echo dockshock;} ; dock' su 

Questo dimostra come non abbia nulla a che fare con l'analisi di una particolare funzione e un exploit può fare riferimento e utilizzare la funzione. Puoi immaginare che la funzione abbia la logica per testare se root, ecc. In questo caso, è solo una forma modificata una funzione per iconizzare o ancorare una finestra terminale, usando una sequenza di escape, è piuttosto standard, quindi dopo aver fatto clic per deiconificare, ho vedi dockshock - ma, e allora? Ora prova questo:

%TERM='() { echo -e "\e[2t\c"; echo dockshock;} ; TERM' su - 

E indovina cosa? La finestra viene risucchiata nel dock. Ecco come appare dopo ...

%TERM='() { echo -e "\e[2t\c"; echo dockshock;} ; TERM' su -
Password:
dockshock
# env
_=/usr/bin/env
HOME=/var/root
LOGNAME=root
TERM=vt102
USER=root
# echo $0
/bin/ksh
#

Quindi, così tanto! Le funzioni esportate hanno effettivamente la priorità sugli script rc. Non puoi schivarlo.