En este artículo, dice que este script de shell C:
#!/bin/csh -b
set user = $1
passwd $user
Con estos permisos:
-rwsr-x--- 1 root helpdesk
Es vulnerable porque se pueden manipular variables env, como:
env TERM=''cp /bin/sh /tmp/sh;chown root /tmp/sh;chmod 4755/tmp/sh'' change-pass
Pero realmente no veo lo que tiene que ver el TÍTULO env var con todo esto. ¿Tienes alguna explicación?
Este es un defecto de diseño en csh , que permite la evaluación del escape de backtick en el contenido de la variable de entorno.
En general, se suele suponer que el control del entorno de un shell no debe llevar a la ejecución de código arbitrario.
Romper este supuesto crea docenas de vectores de ataque para la ejecución remota de código, desde scripts CGI hasta respuestas DHCP maliciosas y reenvío de correo.
Cuando este comportamiento fue accidentalmente activable para bash , lo llamamos Shellshock e hicimos un gran revuelo al respecto.
@ b0fh ya ha explicado el uso del entorno en csh . Pero el artículo debería quedar obsoleto en el siglo XXI. Se sabe que los programas Set uid son posibles vectores de ataque, y los administradores paranoicos reciben un correo cada vez que se instala un nuevo programa raíz Setuid: los administradores deberían siempre ser paranoicos ...
Pero, AFAIK, las versiones recientes de Unixes no permiten los scripts de setuid, porque solía ser demasiado peligroso. Eso significa que cualquier sistema operativo decente debe ignorar el s en un archivo que no está en formato ejecutable, pero solo debe usar el hash bang ( #! ) en su primera línea.
Cuando se inicia un nuevo shell, se evalúan las variables de entorno. En este caso, las comillas inversas conducen a que se ejecuten esos comandos, y la salida se use como el valor de TERM.
(Este problema en particular puede solucionarse o no. Generalmente, es muy difícil escribir scripts de shell que sean seguros contra entradas inteligentes y que se protejan a sí mismos cuando se ejecute setuid.)
Cada programa con uno de los conjuntos de bits de usuario / grupo sobre la ejecución 1 es un riesgo potencial para la seguridad. En el ejemplo dado en esta pregunta 2 , los permisos de script change-pass permiten la ejecución del script y el programa passwd con privilegios de raíz utilizando el espacio de nombres de entorno copiado de otros usuarios.
La contraseña del programa se está ejecutando en modo terminal, a diferencia del modo de entrada estándar, y no quiere que el terminal muestre caracteres de contraseña en la pantalla. Llama a ttyname para obtener el nombre del terminal de la variable de entorno TERM para apagar el eco y, de lo contrario, dirigir la entrada / salida.
Al sustituir un conjunto de comandos de shell entre comillas por el valor de TERM, es posible crear un shell sin restricciones para usuarios que no sean root. La comilla simple en el comando env garantiza que la evaluación se posponga, al menos en algunas implementaciones de shell 3 , hasta que se realice la llamada a getenv para TERM mediante ttyname.
El miembro desprevenido del servicio de asistencia técnica del grupo podría abrir una puerta trasera al atacante, simplemente restableciendo la contraseña de un cliente mediante el cambio de paso.
[1] El comando ls -l muestra esto como una 's' en los códigos de permiso. Es el '4' en los códigos de comando chmod del ejemplo. Las versiones de usuario y grupo de estos bits se abrevian SUID y SGID.
[2] Se informa que este mismo exploit es efectivo con la variable de entorno MAIL_CONFIG y el ejecutable que lo adquiere del entorno, sudo, de la misma manera. (Crédito a @ adam-shostack por este ejemplo alternativo).
[3] Puede haber implementaciones que pospongan la evaluación de TERM hasta que se realice la copia del entorno para el proceso hijo, el script de cambio de paso. Es más probable que POSIX o algún otro estándar gobierne cuando se realiza la evaluación y que siempre difiera hasta que se solicite el valor.
Lea otras preguntas en las etiquetas permissions