In questo articolo, dice che questo script C-shell:
#!/bin/csh -b
set user = $1
passwd $user
Con queste autorizzazioni:
-rwsr-x--- 1 root helpdesk
È vulnerabile perché si possono manipolare variabili env, come:
env TERM=''cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh'' change-pass
Ma davvero non vedo che cosa debba vedere il TERM ENV var con tutto questo. Avete qualche spiegazione?
Si tratta di un difetto di progettazione in csh , che consente di valutare l'escape del backtick nei contenuti della variabile di ambiente.
Nel complesso, l'ipotesi è in generale che il controllo dell'ambiente di una shell non dovrebbe portare all'esecuzione di codice arbitrario.
L'interruzione di questa ipotesi crea dozzine di vettori di attacco per l'esecuzione di codice in modalità remota, da script CGI a risposte DHCP dannose all'inoltro di posta.
Quando questo comportamento è stato accidentalmente innescabile per bash , l'abbiamo chiamato Shellshock e ne abbiamo fatto un gran chiasso.
@ b0fh ha già spiegato l'uso dell'ambiente in csh . Ma l'articolo dovrebbe essere obsoleto nel 21 ° secolo. I programmi uid sono conosciuti come possibili vettori di attacco e gli amministratori paranoici ricevono posta ogni volta che viene installato un nuovo programma root setuid - admins dovrebbe essere sempre paranoico ...
Ma AFAIK, le versioni recenti degli Unix non consentono gli script setuid, perché erano troppo pericolosi. Ciò significa che qualsiasi sistema operativo decente dovrebbe ignorare s su un file che non è in formato eseguibile ma utilizzare solo l'hash bang ( #! ) nella sua prima riga.
Quando viene avviata una nuova shell, vengono valutate le variabili di ambiente. In questo caso, i backtick portano a quei comandi che vengono eseguiti e l'output viene utilizzato come valore di TERM.
(Questo particolare problema potrebbe essere risolto o potrebbe non essere. In generale, è molto difficile scrivere script di shell che siano sicuri contro input intelligenti e si protegga correttamente quando si esegue setuid.)
Ogni programma con uno dei bit set-user / group-upon-execution 1 rappresenta un potenziale rischio per la sicurezza. Nell'esempio fornito in questa domanda 2 , le autorizzazioni dello script passaggio-permesso consentono l'esecuzione dello script e del programma passwd con i privilegi di root usando lo spazio dei nomi dell'ambiente copiato da altri utenti.
Il programma passwd è in esecuzione in modalità terminale, al contrario della modalità di input standard, e non vuole che il terminale faccia eco ai caratteri della password sul display. Chiama ttyname per ottenere il nome del terminale dalla variabile di ambiente TERM per disattivare l'eco e altrimenti indirizzare i / o.
Sostituendo una serie di comandi della shell citata per il valore di TERM, è possibile creare una shell senza restrizioni per gli utenti non root. Il singolo apice nel comando env assicura che la valutazione sia posticipata, almeno in alcune implementazioni di shell 3 , fino a quando la chiamata getenv non viene effettuata per TERM tramite ttyname.
L'ignaro membro dell'helpdesk del gruppo potrebbe aprire una porta sul retro dell'attaccante, semplicemente reimpostando la password di un cliente utilizzando il passaggio di sicurezza.
[1] Il comando ls -l lo mostra come una "s" nei codici di autorizzazione. È il '4' nei codici di comando chmod dell'esempio. Le versioni utente e di gruppo di questi bit sono SUID e SGID abbreviati.
[2] Questo stesso exploit è segnalato per essere efficace con la variabile di ambiente MAIL_CONFIG e l'eseguibile che lo acquisisce dall'ambiente, sudo, nello stesso modo. (Credito a @ adam-shostack per questo esempio alternativo.)
[3] Potrebbero esserci implementazioni che posticipano la valutazione TERM fino a quando non viene eseguita la copia dell'ambiente per il processo figlio, lo script passaggio-passaggio. È più probabile che POSIX o qualche altro standard regoli quando si verifica la valutazione e che rimanda sempre fino a quando non viene richiesto il valore.
Leggi altre domande sui tag permissions