Envoltorios de script Set-uid, 'system (3)' shellshock y función de Bash importados del entorno

Question

Envoltorios de script Set-uid, 'system (3)' shellshock y función de Bash importados del entorno

#1 de Tom Leek (5 votos)
#2 de Joshua (0 votos)

3

Dado , es un requisito frecuente permitir a los usuarios sin privilegios acceso restringido a funciones privilegiadas: los administradores de sistemas de trabajo a veces proporcionan esto en forma de shellscripts, que luego se invocan a través de un envoltorio setuid , como entonces:

int main()
{
   setuid( 0 );
   system( "/path/to/script.sh" );

   return 0;
}

(La evidencia de esta afirmación se puede encontrar buscando setuid el script no funciona en su motor de búsqueda favorito o en desbordamiento de pila . No, no deberían estar haciendo esto, pero lo hacen. Cuando los consejos de seguridad son demasiado difíciles o demasiado oscuros para que los administradores de sistemas los sigan, se necesita otra solución.)

Tenga en cuenta que esto puede no ser simplemente ignorancia. ¿Quién esperaría que un script que contenga solo esto sea peligroso?

#!/bin/bash
kill -HUP $(< /var/run/demonname.pid)

Obviamente, la intención es pedirle a demonname que vuelva a leer su archivo de configuración. No llama más que bash incorporados (por lo que no debería usar la ruta), y no consulta el entorno una vez. En mi opinión, incluso un administrador de sistemas experimentado podría ser perdonado por pensar que un suidwrapper estaba bien en este caso .

Como se descubrió anteriormente, Shellshock, e (incluso sin él) la función de Importación desde entorno (FIE) de bash, plantea vulnerabilidades de escalamiento de privilegios.

Suponiendo que:

tales cosas existen en su instalación, y usted no sabe que lo hacen, y
puede asumir de manera confiable que se crearán nuevos ...

Sería aconsejable:

volcar bash y usar algo para siempre amén?
parche para golpear a la FIE por completo (la opción de "bomba nuclear desde la órbita") ?
parchear bash para incluir en la lista blanca las rutas completas de los scripts que pueden utilizar esta función?
parche system y popen para borrar el entorno de forma predeterminada si se ejecuta como root? (La gente no debería estar usando estas funciones).
¿Enviar al administrador cada vez que alguien llama a system como root? ¿O comienza un shellscript como root?
o qué?

En otras palabras, ¿se utiliza FIE en la producción para algo más que para explotar sistemas? Si es así, ¿podemos incluir esos usos en la lista blanca y prohibirlos en cualquier otro lugar? Si no, no podemos simplemente eliminar la función ?

bash shellshock privilege-escalation

pregunta Ben 03.10.2014 - 15:01

fuente

2 respuestas

0

Mi envoltorio se ve así:

int main()
{
   setuid( 0 );
   execve("/path/to/script.sh", "/path/to/script.sh", NULL );

   return 0;
}

No puedo desechar que incluso si / bin / sh es bash.

respondido por el Joshua 03.10.2014 - 19:36

fuente

Lea otras preguntas en las etiquetas bash shellshock privilege-escalation

ASLR no parece aleatorizar la sección de texto Conjunto de datos de malware de Android

score 5 · Accepted Answer

Tales envoltorios de setuid son peligrosos independientemente de si el intérprete de script es un bash fijo, un bash sin fijar, o algún otro shell. La razón es que muchas variables de entorno afectan a los intérpretes de scripts. Los infractores a menudo citados son PATH y IFS. Esta es la razón por la que sudo restablece todo el entorno a valores sanos (ya que los autores de shell son invariablemente creativos, no puede lograr seguridad con solo una lista negra en unas pocas variables de entorno "peligrosas conocidas"; tiene que matar a todo el lote).

Para abusar de una metáfora usada en exceso, la FIE es solo la punta del iceberg, no el bloque de hielo que rompe el casco del barco. Las variables de entorno son el problema, ya que son un canal encubierto e indirecto que se propaga a través de las llamadas y puede afectar la funcionalidad de muchas maneras (por ejemplo, podría cambiar el comportamiento de las rutinas de asignación de memoria activando el "modo de depuración" a través del entorno). Para los binarios de setuid, el kernel borra el peor de los casos (LDPRELOAD) pero, en realidad, todas las variables de entorno deberían borrarse, con la posible excepción de las variables LC_ * (para establecer el comportamiento dependiente de la ubicación, e incluso eso es altamente discutible) .

Por supuesto, parchear el kernel para limpiar el entorno cada vez que se invoca un binario setuid está destinado a romper cosas ... Incluso OpenBSD, a pesar de su postura de "toda su seguridad nos pertenece", ha evitado implementar realmente tal cambio drástico. En su lugar, confían en la documentación :

¡No confíes en tu entorno! Esto involucra cosas simples como su ruta de acceso (nunca use el sistema con un nombre no calificado, evite execvp), sino también elementos más sutiles como su localidad, zona horaria, termcap, etc. Esté atento a la transitividad: aunque esté tomando todas las precauciones, los programas a los que llama directamente no necesariamente. Nunca use el sistema en programas privilegiados, cree su línea de comando, un entorno controlado y llame a execve directamente. La página del manual de perlsec es un buen tutorial sobre tales problemas.