"Shell shock" - sfruttabile quando 'system ()' syscall o 'exec (bash)', giusto?

Question

"Shell shock" - sfruttabile quando 'system ()' syscall o 'exec (bash)', giusto?

#1 da (5 voti)
#2 da (1 voti)

0

La mia comprensione è corretta sul fatto che per sfruttare tramite "Shell Shock", il binario che influenziamo ha bisogno di eseguire bash (e abbiamo bisogno di avere influenza sulla linea di comando)?

Pertanto, ho ragione, che se binario non esegue direttamente bash, e non usa la chiamata di sistema system() (che usa la shell per la valutazione del comando), ma, invece, chiama i programmi helper tramite chiamate di sistema da exec() family (o carichi tramite caricamento dinamico come ld ecc.), dato che il binario dato è "shell shock" sicuro? (Ovviamente si applica in modo transitorio, se possiamo influenzare il modo in cui le app helper chiamano le loro app helper)

E se il sistema espone solo tali binari agli input provenienti dal mondo esterno, quel dato sistema è "shell shock" sicuro? (Pertanto, il controllo della mancanza di chiamate system() e delle chiamate exec() di bash è un buon criterio di valutazione dell'audit?)

linux unix audit shellshock

posta Grzegorz Wierzowiecki 27.09.2014 - 00:09

fonte

2 risposte

1

Per aggiungere a ciò che ha detto Mark, vale anche la pena notare che execlp , execvp e execvpe invocano /bin/sh , in quanto è così che eseguono le ricerche di percorso. Quindi, anche senza gli effetti generazionali di cui parla Marco, solo l'uso della famiglia di funzioni exec * non garantisce che bash non venga invocato. La correzione corretta è assicurarsi di aver installato una versione patch di bash che non sia suscettibile allo shock di shell. (Sì, questo non offre alcuna protezione contro vulnerabilità future.)

risposta data 27.09.2014 - 12:17

fonte

Leggi altre domande sui tag linux unix audit shellshock

La maggior parte degli attacchi MiTM viene eseguita per impersonare siti Web o semplicemente decrittografare il traffico? Il prisma può conoscere anche dati al di fuori dei data center statunitensi?

score 5 · Accepted Answer

Sbagliato su entrambi i fronti.

Per sfruttare la vulnerabilità "shellshock", un utente malintenzionato deve controllare almeno una variabile di ambiente (facilmente eseguibile tramite CGI, SSH o DHCP) e bash deve essere invocato a un certo punto con la modifica ambiente: direttamente come risultato di un exec() , indirettamente attraverso system() o equivalente, in modo molto indiretto tramite exec() di un'app helper che a sua volta chiama system() e così via.

bash non ha bisogno di essere invocato per nome, neanche. Su molti sistemi, /bin/sh è un collegamento simbolico o hard a /bin/bash , quindi l'esecuzione di qualsiasi script che inizia con #!/bin/sh comporterà l'esecuzione di bash .