#Shellshock: Grave vulnerabilidad en bash (CVE-2014-6271) permite la ejecución remota de comandos

Todos sabéis que bash lleva desde los 80 "casado" con Unix/Linux/MacOS y todavía se utiliza ampliamente para muchas cosas, entre ellas proveer un shell a un usuario remoto (telnet o ssh por ejemplo), como parser para scripts CGI (Apache, etc.) e incluso para facilitar soporte a la ejecución de comandos como se hace con Git...

Ahora Stephane Chazelas ha descubierto una vulnerabilidad bastante seria que puede ser explotada remotamente. Se le ha asignado el CVE-2014-6271 y en resumen se basa en la posibilidad de crear variables de entorno con código que puede ser ejecutado después de una función y antes de llamar al shell de bash. 

Al igual que los lenguajes de programación "reales" Bash tiene funciones, aunque de una aplicación un tanto limitada, y también es posible poner estas funciones de bash en las variables de entorno. El fallo está cuando se añade código adicional al final de estas definiciones de funciones (dentro de la variable environment) porque bash sigue ejecutando o parseando estos comandos. Algo así como:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
 vulnerable
 this is a test


El resultado afecta a numerosos contextos:

- ForceCommand se utiliza en sshd para limitar las capacidades de ejecución de comandos a los usuarios remotos. Algunas implementaciones de Git y Subversion utilizan estos shells restringidos aunque a OpenSSH no le afecta ya que los usuarios ya tienen acceso a la consola.

- El servidor Apache usando mod_cgi o mod_cgid se ve afectado si los scripts CGI están escritos en bash, o propagan subshells. Dependiendo del comando un shell puede llamar a otros subshells si implicitamente utiliza system/popen en C, os.system/os.popen en Python, system/exec en PHP (cuando se ejecuta en modo CGI) y open/system en Perl.

- Los scripts PHP ejecutados con mod_php no se ven afectados aunque se creen subshells.

- Los clientes DHCP invocan scripts de shell para configurar el sistema, con valores tomados de un servidor potencialmente malicioso. Esto permitiría ejecutar arbitrariamente comandos, normalmente como root, en el equipo cliente DHCP.

- Varios demonios y programas con privilegios SUID pueden ejecutar scripts de shell con los valores de variables de entorno establecidas/ modificados por el usuario, lo que permitiría ejecutar comandos arbitrarios.

- Cualquier otra aplicación que hookea un shell o ejecuta un script de shell con bash como intérprete. Los scripts de shell que no exportan variables no son vulnerables a este problema, incluso si ellos procesan contenido no confiable y la almacenan en variables (dejados) de shell y subshells abiertos.


Ya se han publicado parches que corrigen este fallo, con los que se asegura de que no se permite código después del final de una función bash. Así que si ejecutamos el ejemplo anterior con la versión parcheada de bash, obtendremos la siguiente salida:

 $ 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


Fuentes:
- Bash specially-crafted environment variables code injection attack
- Remote exploit vulnerability in bash CVE-2014-6271
- CVE-2014-6271: remote code execution through bash

Comentarios

  1. Para escalar privilegios en MacOS

    LANG='() { :;}; id -p > /tmp/getroot' open /Applications/Darwine/WineHelper.app/Contents/MacOS/WineHelper

    Para solventar la papeleta :

    port selfupdate
    port install bash

    Luego cuando hagas

    env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

    bash: aviso: x: ignoring function definition attempt
    bash: error al importar la definición de la función para `x'
    this is a test

    Solved! :)

    Salu2

    ResponderEliminar
  2. Falta luego hacer un cat /tmp/getroot, después de definir LANG, que me lo había dejado ;)

    ResponderEliminar
  3. y si realizas los updates y upgrades y sigue reconociendo el sistema como vulnerable?

    ResponderEliminar
  4. Jilmar pues o tienes paciencia o cambias a Windows.

    ResponderEliminar

Publicar un comentario