¿Por qué "AcceptEnv *" se considera inseguro?

En /etc/ssh/sshd_config, hay una opción llamada AcceptEnvque permite que el cliente ssh envíe variables de entorno. Necesito poder enviar una gran cantidad de variables de entorno. Estos cambian en cada conexión desde el cliente, por lo que sería más difícil ponerlos en un script de inicio de sesión en el servidor.

He leído que "AcceptEnv *"es inseguro. Me gustaría entender por qué antes de intentar obtener una lista de todas las variables de entorno que se intentan configurar para ponerlas allí.

¿Por qué se considera inseguro? ¿Puedo obtener un ejemplo?

— TheDauthi
fuente

Respuestas:

Habilitar el procesamiento del entorno puede permitir a los usuarios eludir las restricciones de acceso en algunas configuraciones utilizando mecanismos como LD_PRELOAD.

No todas las versiones de las páginas man para sshd_config mencionan esto. Si las variables de entorno se cambian de antemano y se ejecutan ciertos procesos privilegiados con nuevas bibliotecas especificadas por esto, pueden surgir problemas.

Eche un vistazo a http://www.dankalia.com/tutor/01005/0100501004.htm y busque "LD_PRELOAD Exploit". Lo sentimos, la página no tiene enlaces de anclaje.

Consulte también esta pregunta de StackOverflow, " ¿Cuál es el truco LD_PRELOAD? "

Establecer las variables de entorno después de la conexión está bien, pero cuando el demonio ssh interpreta esas variables según lo establecido por AcceptEnv, pueden ocurrir cosas malas.

— Jeff Ferland
fuente

¿En qué se diferencia cuando establecen las variables manualmente después de iniciar sesión?

— Joseph Garvin

@JosephGarvin, algunos sistemas tienen shells restringidos o solo permiten un comando específico, de modo que "ellos" no pueden . La preocupación, entonces, es proporcionar un medio por el cual tales medidas de seguridad puedan ser eludidas.

— Charles Duffy

No acepte variables de entorno:

Vea el exploit Shellshock que salió recientemente ... si acepta variables de entorno, entonces está abriendo un exploit realmente desagradable.

— John Hunt
fuente

Estás difundiendo el miedo de la OMI. Si está preocupado, ¿por qué tienen acceso SSH? Y, por cierto, no puede evitar que establezcan variables de entorno una vez que están en el shell o incluso en las funciones. Ese exploit se trata de acceso a shell no autorizado a través de cosas como nginx, acceso a shell no autorizado.

— Jordon Bedwell

De todos modos, acepta al menos una env. variable denominada TERM. Puede haber necesidades válidas para aceptar otras variables como IMPRESORA, EDITOR, PAGER, ...

— ibre5041

@JordonBedwell, no todas las conexiones SSH están autorizadas para acceso de shell. Tengo varios sistemas en los que hay cuentas para las cuales la única autenticación es con una clave SSH que permite ejecutar solo un comando específico (con la identidad del propietario de esa clave y otros detalles).

— Charles Duffy

... Dicho esto, estoy de acuerdo en que a partir de 2017, ShellShock es muy exagerado aquí. Con las implementaciones actuales, generar una función exportada requiere control no solo sobre el valor de una variable de entorno , sino también su nombre (y el proceso de evaluación de las funciones exportadas durante el inicio del shell ya no es propenso a ataques de inyección).

— Charles Duffy