Perché "AcceptEnv *" è considerato insicuro?

In /etc/ssh/sshd_config, c'è un'opzione chiamata AcceptEnvche consente al client ssh di inviare variabili d'ambiente. Devo essere in grado di inviare un gran numero di variabili d'ambiente. Questi cambiamenti su ogni connessione dal client, quindi inserirli in uno script di accesso sul server sarebbe più difficile.

Ho letto che non "AcceptEnv *"è sicuro. Vorrei capire perché prima di provare a ottenere un elenco di tutte le variabili di ambiente che si tenta di impostare per inserirle.

Perché è considerato insicuro? Posso avere un esempio?

— TheDauthi
fonte

Risposte:

L'abilitazione dell'elaborazione dell'ambiente può consentire agli utenti di ignorare le restrizioni di accesso in alcune configurazioni utilizzando meccanismi come LD_PRELOAD.

Non tutte le versioni delle pagine man di sshd_config menzionano questo. Se le variabili di ambiente vengono modificate in anticipo e determinati processi privilegiati vengono eseguiti con nuove librerie specificate da questo, possono verificarsi problemi.

Dai un'occhiata a http://www.dankalia.com/tutor/01005/0100501004.htm e cerca "LD_PRELOAD Exploit". Siamo spiacenti, la pagina non ha collegamenti di ancoraggio.

Vedi anche questa domanda StackOverflow, " Qual è il trucco LD_PRELOAD? "

L'impostazione delle variabili di ambiente dopo la connessione va bene, ma quando tali variabili vengono interpretate dal demone ssh come impostato da AcceptEnv, potrebbero verificarsi errori.

— Jeff Ferland
fonte

In che modo è diverso da quando impostano manualmente le variabili dopo aver effettuato l'accesso?

— Joseph Garvin,

@JosephGarvin, alcuni sistemi hanno shell limitate o consentono solo un singolo comando specifico, in modo che "loro" non possano . La preoccupazione, quindi, è fornire un mezzo per aggirare tali misure di sicurezza.

— Charles Duffy,

Non accettare variabili di ambiente:

Guarda l'exploit Shellshock che è uscito di recente .. se accetti le variabili di ambiente, stai aprendo un exploit davvero brutto.

— John Hunt
fonte

Stai diffondendo la paura dell'IMO. Se sei così preoccupato, perché hanno accesso a SSH? E tra l'altro non puoi impedirgli di impostare le variabili di ambiente una volta che sono nella shell o addirittura funzioni. Tale exploit riguarda l'accesso alla shell non autorizzato attraverso elementi come nginx, non l'accesso alla shell autorizzato.

— Jordon Bedwell,

Ad ogni modo accetti almeno un env. variabile denominata TERM. Possono esserci esigenze valide per accettare altre variabili come STAMPANTE, EDITOR, PAGER, ...

— ibre5041

@JordonBedwell, non tutte le connessioni SSH sono autorizzate per l'accesso alla shell. Ho diversi sistemi in cui ci sono account per i quali l'unica autenticazione è con una chiave SSH che ha permesso di eseguire solo un singolo comando specifico (con l'identità del proprietario di quella chiave e altri dettagli, integrati).

— Charles Duffy,

... Detto questo, sono d'accordo sul fatto che a partire dal 2017 ShellShock è molto esagerato qui. Con le attuali implementazioni, la generazione di una funzione esportata richiede il controllo non solo del valore di una variabile di ambiente , ma anche del suo nome (e il processo di valutazione delle funzioni esportate durante l'avvio della shell non è più soggetto agli attacchi di iniezione).

— Charles Duffy,