Shellshock più esclusione di whitelist per ambiente su su / su - grosso problema?

Question

Shellshock più esclusione di whitelist per ambiente su su / su - grosso problema?

#1 da (3 voti)
#2 da (0 voti)

1

La domanda è: quanto è grande questo problema? Sembra abbastanza grande per me.

Con il bug shellshock è possibile aggirare la whitelist delle variabili di ambiente innocue note in sudo, così come altre rotte per l'esecuzione del codice come utenti con privilegi elevati. Per esempio le variabili MAIL e DISPLAY sono per default propagate da sudo in molte configurazioni (l'ultima volta che ho controllato - non penso che l'ultima Debian faccia).

In presenza di Shellshock, se un utente senza privilegi, un utente parzialmente privilegiato o un malware con esecuzione di codice non privilegiata può fornire qualsiasi variabile di ambiente propagata qualunque a una shell in esecuzione come root, può eseguire codice arbitrario come root.

L'utente con diritti di sudo limitati è dannoso
L'utente imposta la variabile d'ambiente come MAIL nel codice exploit shell
Qualsiasi chiamata a popen , system o bash da qualsiasi sudo 'd comando da un utente di questo tipo ora provocherà l'esecuzione arbitraria di codice come root.
il risultato è che qualsiasi diritto sudo diventa accesso di root al sistema - non importa quanto sia limitato il suo accesso

o

L'utente ottiene l'accesso al terminale utente non presidiato con alcuni diritti sudo, o
Il malware acquisisce l'esecuzione del codice come utente non privilegiato con alcuni diritti sudo
Malware / User imposta variabili d'ambiente propagate come MAIL al codice exploit shell
Qualsiasi chiamata a popen , system o bash da qualsiasi sudo 'd comando da un utente di questo tipo ora provocherà l'esecuzione di codice come root.
Non richiede la conoscenza della password - la password può essere inserita successivamente dall'utente dopo l'accesso è cessato.

bash sudo shellshock whitelist

posta Ben 30.09.2014 - 16:20

fonte

2 risposte

Leggi altre domande sui tag bash sudo shellshock whitelist

Protezione di OAuth / OpenID Connetti l'identità in un cookie per un facile accesso Quanto tempo può essere una passphrase pkcs # 8?

score 3 · Answer 1

Sudo blocca le variabili di ambiente che potrebbero essere definizioni di funzioni bash ( 2004-11-11 env.c: strip ha esportato le funzioni bash da l'ambiente ), anche se il nome della variabile è nella whitelist. Ecco perché sudo non è incluso nella lista dei comuni vettori di attacco per Shellshock.

Uno script di bash invocato da su a un account limitato può essere un vettore di attacco. Ma ci sono altri problemi con uno script di shell invocato tramite su . su non elimina le variabili di ambiente come IFS o PATH (bash non importa IFS dall'ambiente, ma alcune altre shell lo fanno) - o BASH_ENV , che è il nome di un file dove bash legge i comandi all'avvio. Uno script di shell invocato tramite su su un account limitato avrebbe bisogno di un wrapper intermedio. Questo wrapper dovrebbe fare attenzione a quali variabili e valori lascia passare.

score 0 · Answer 2

@Gilles ha ragione. Penso che i risultati di questo test potrebbero essere interessanti:

Ho fatto un test con uno script molto scadente:

$ cat ./sudoset.bash 
#!/bin/bash-shellshock
set

Per confermare, senza sudo:

$ export MAIL="() { :;} ; echo busted"; ./sudoset.bash | head -3
  busted
  busted
  BASH=/bin/bash-shellshock

(non sono sicuro del motivo per cui "busted" appare due volte)

Con sudo:

$ export MAIL="() { :;} ; echo busted"; sudo ./sudoset.bash | head -3
BASH=/bin/bash-shellshock
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()

Ma la variabile MAIL è nella whitelist mentre descrivi:

$ export MAIL="simpletest"; sudo ./sudoset.bash | grep MAIL
MAIL=simpletest

Non appena contiene una definizione di funzione, sudo sembra spogliarlo:

$ export MAIL="() { :;} ; echo busted"; sudo ./sudoset.bash | grep MAIL
MAIL=/var/mail/root