Aparentemente hay una vulnerabilidad (CVE-2014-6271) en bash:ataque de inyección de código de variables de entorno especialmente diseñado para Bash
Estoy tratando de averiguar qué está pasando, pero no estoy completamente seguro de entenderlo. ¿Cómo puede el echo ejecutarse tal como está entre comillas simples?
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
EDITAR 1 :Un sistema parcheado se ve así:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
EDITAR 2 :Hay una vulnerabilidad/parche relacionado:CVE-2014-7169 que usa una prueba ligeramente diferente:
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
salida sin parche :
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test
salida parcheada parcialmente (versión anterior) :
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test
salida parcheada hasta e incluyendo CVE-2014-7169:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test
EDITAR 3 :la historia continúa con:
- CVE-2014-7186
- CVE-2014-7187
- CVE-2014-6277
Respuesta aceptada:
bash almacena las definiciones de funciones exportadas como variables de entorno. Las funciones exportadas se ven así:
$ foo() { bar; }
$ export -f foo
$ env | grep -A1 foo
foo=() { bar
}
Es decir, la variable de entorno foo tiene el contenido literal:
() { bar
}
Cuando se inicia una nueva instancia de bash, busca estas variables de entorno especialmente diseñadas y las interpreta como definiciones de funciones. Incluso puedes escribir uno tú mismo y ver que todavía funciona:
$ export foo='() { echo "Inside function"; }'
$ bash -c 'foo'
Inside function
Desafortunadamente, el análisis de definiciones de funciones a partir de cadenas (las variables de entorno) puede tener efectos más amplios de lo previsto. En versiones sin parches, también interpreta comandos arbitrarios que ocurren después de la finalización de la definición de la función. Esto se debe a restricciones insuficientes en la determinación de cadenas similares a funciones aceptables en el entorno. Por ejemplo:
$ export foo='() { echo "Inside function" ; }; echo "Executed echo"'
$ bash -c 'foo'
Executed echo
Inside function
Tenga en cuenta que el eco fuera de la definición de la función se ha ejecutado inesperadamente durante el inicio de bash. La definición de la función es solo un paso para que la evaluación y el exploit sucedan, la definición de la función en sí misma y la variable de entorno utilizada son arbitrarios. El shell mira las variables de entorno, ve foo , que parece que cumple con las restricciones que conoce sobre cómo se ve una definición de función, y evalúa la línea, sin querer, también ejecuta el eco (que podría ser cualquier comando, malicioso o no).
Esto se considera inseguro porque normalmente no se permite ni se espera que las variables, por sí mismas, provoquen directamente la invocación del código arbitrario contenido en ellas. Quizás su programa establece variables de entorno a partir de la entrada de un usuario que no es de confianza. Sería muy inesperado que esas variables de entorno pudieran manipularse de tal manera que el usuario pudiera ejecutar comandos arbitrarios sin su intención explícita de hacerlo usando esa variable de entorno por tal razón declarada en el código.
Aquí hay un ejemplo de un ataque viable. Ejecuta un servidor web que ejecuta un shell vulnerable, en algún lugar, como parte de su vida útil. Este servidor web pasa las variables de entorno a un script bash, por ejemplo, si está utilizando CGI, la información sobre la solicitud HTTP a menudo se incluye como variables de entorno del servidor web. Por ejemplo, HTTP_USER_AGENT podría establecerse en el contenido de su agente de usuario. Esto significa que si falsifica su agente de usuario para que sea algo así como '() {:; }; echo foo’, cuando se ejecuta ese script de shell, echo foo será ejecutado. De nuevo, echo foo podría ser cualquier cosa, maliciosa o no.