Shellshock produce un vettore di escalation di privilegi locali completo?

Sì!

I binari con un setuid bit e chiamando (direttamente o indirettamente) bash a execve , popen o system sono strumenti che possono essere utilizzati per attivare il bug di Shell Shock.

Se questi comandi non si occupano di cancellare *env prima di eseguire bash (o uno script di shell) allora questi binari possono essere usati per eseguire qualsiasi comando (ad esempio bash ) con il privilegio di% % co_de.

root e popen non consentono al programmatore di pulire system .

Ecco una prima bozza di controllo semplice per stima questo rischio:

find /  -perm +4000 \
    -exec /bin/zsh -c "ls -dluT {} ; nm -a {} | egrep '(popen|system|execve)' && strings {} | egrep '/bin/(sh|bash)'" \; 2>/dev/null

Questo non è un proof di rischio, poiché *env potrebbe essere stato pulito prima del fork della shell. L'unico modo per essere sicuri è leggere il codice sorgente.

Ed ecco il risultato su una versione attuale di un Unix molto usato:

-rwsr-xr-x  1 root  wheel  910848 Sep 29 16:31:18 2014 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
             U _popen
/bin/bash

(Qui l'ultima volta utilizzata non è una prova di un attacco ma della mia precedente "bozza di controllo".)

Quando bash è invocato nel contesto setuid (o setgid), cioè quando l'uid effettivo è diverso dall'uid reale, allora bash rilascia i privilegi (imposta l'uid effettivo sul vero uid).

L'eccezione è quando usi -p o -o privileged (la variabile SHELLOPTS viene ignorata, quindi privileged anche lì) o quando viene invocata come sh .

In questo caso però, le funzioni non vengono importate dall'ambiente (né cose come BASH_ENV , BASH_OPTS , SHELLOPTS per gli stessi ovvi motivi).

Se lo fossero, non avresti bisogno della vulnerabilità shellshock per sfruttarla. La semplice esportazione di una funzione echo (o qualsiasi cosa chiamata dallo script inclusi percorsi come /bin/mount ) farebbe.

Alcuni comandi setuid possono scegliere di impostare il ruid sull'euid. Se lo fanno, non sanificano l'ambiente e chiamano bash (o qualsiasi altra shell), quindi la vulnerabilità del game over, shellshock o meno.

Il linker dinamico di libc si occupa di rimuovere alcune variabili che influiscono sulla libc o sul linker (LD_PRELOAD, LOCPATH, LD_LIBRARY_PATH ...), ma è compito dell'applicazione setuid cancellare il resto se invocano altri comandi come una shell ( o python, o qualsiasi altro comando il cui comportamento può essere controllato con variabili di ambiente), il tipico approccio sano è quello di cancellare tutto tranne una lista bianca sanificata.

Un tipico esempio di tale applicazione è sudo .

Per impostazione predefinita (con l'opzione env_reset su), sudo cancella l'ambiente, ne imposta alcuni (come PATH , HOME , SUDO_USER ...) e inserisce alcuni whitelist dopo aver controllato il loro contenuto come TERM o DISPLAY . Parte di questo controllo si occupa in particolare delle variabili il cui contenuto inizia con () .

Se env_reset è disattivato (disabilitato dall'utente / amministratore), sudo ancora oscura alcune variabili che influenzano varie shell o altri strumenti comuni (come PS4 , BASH_ENV ...) e quelli il cui contenuto inizia con () .

Quindi shellshock non può essere sfruttato facendo:

DISPLAY='() {(:);}; ouch;}' sudo trusted-bash-script

Ora, è possibile che ci siano comandi setuid che impostano ruid e non controllano le variabili che iniziano con () e invocano bash (possibilmente indirettamente), ma di nuovo non c'è bisogno del bug shellshock da sfruttare quelli.

Una possibile eccezione è la suexec di apache. Per quanto ne so, suexec sanifica l'ambiente ma solo il bianco: elenca alcune variabili in base al loro nome e non al loro contenuto. Senza CVE-2014-6271, questo non sarebbe un problema dato che nomi di variabili come QUERYSTRING , HTTP_USER_AGENT non corrispondono al nome di un comando, quindi non è stato ritenuto necessario bloccare le variabili il cui contenuto inizia con "() {" , ma in pratica significa che è esposto a CVE-2014-6271.