Incluso con el parche Shellshock, ¿no es Bash vulnerable a la redefinición de comandos?

12

A riesgo de agregar al montón de preguntas relacionadas con "Shellshock" ...

El parche Shellshock evita que se ejecute código arbitrario después de las definiciones de funciones en las variables de entorno. Por ejemplo, aquí está lo que hace una versión parcheada de Bash cuando uno intenta explotar el agujero:

$ env foo='() { :;}; echo derp' bash -c 'echo herp'
bash: foo: ignoring function definition attempt
bash: error importing function definition for 'foo'
herp

Esto todavía está permitido por diseño:

$ env foo='() { echo derp; }' bash -c foo
derp

Pero si la definición de la función a través del entorno es posible, cualquier persona con la capacidad de modificar el entorno puede reemplazar los comandos con código arbitrario (asumiendo que el script de destino no especifica los comandos por ruta absoluta):

$ env ls='() { echo derp; }' bash -c ls
derp

Mientras que el parche Shellshock previene cosas como el ataque del encabezado de Usuario-Agente HTTP, donde se puede usar cualquier variable de entorno cualquier para ejecutar código, no hace nada para evitar la redefinición de comandos existentes.

Un ataque similar ya es posible sin la herencia de funciones modificando PATH para que apunte a un directorio que contenga ejecutables arbitrarios con nombres malintencionados, pero ese escenario requiere acceso al sistema de archivos. Este no lo hace.

La pregunta, entonces: ¿la posibilidad de redefinir comandos a través del entorno cuenta como una vulnerabilidad? ¿Hay alguna situación común en la que pueda ser explotada para propósitos nefarios? (Por ejemplo, Git / Mercurial sobre SSH, gitolita ...)

    
pregunta Sam Harada 25.09.2014 - 21:51
fuente

1 respuesta

12

En teoría, sí. Pero entonces también tienes problemas con

  • LD_PRELOAD
  • LD_LIBARAY
  • BASH_ENV
  • etc.

El mayor problema con shellshock es que el nombre de la variable de entorno no importa, bash ejecutaría el código incluso si nunca llama por ejemplo. HTTP_COOKIES (¿quién haría eso por cierto?)

El atacante generalmente solo puede elegir una parte del nombre de la variable, y es poco probable (pero no imposible) que se llame una función / programa con ese nombre.

Por ejemplo, Si restringes tu git a través de SSH para que solo puedan invocar git , entonces el atacante debe definir una variable de entorno git , y esto no debería ser posible.

Actualizar : hay otra posible escalada de privilegios locales:

Puede ocultar comandos incluso si se llaman con la ruta completa

env /bin/date='() { echo fail; }' bash -c /bin/date

Lo que puede interferir con system (y otras) llamadas, y este es un problema para el ejecutable SUID que usa una de esas funciones como root.

    
respondido por el Johannes Kuhn 26.09.2014 - 00:26
fuente

Lea otras preguntas en las etiquetas