Alerta! Grave vulnerabilidad en bash

LinuxVersionsSe acaba de publicar una vulnerabilidad crítica en Bash, el interprete de comandos de Linux y muchos otros sistemas Unix (incluido OSX), que también parece afectar a otros interpretes como zsh, tcsh, csh y ksh. Se ha identificado con el registro: CVE-2014-6271 y seguro que dará mucho que hablar los próximos días.

Mediante esta vulnerabilidad es posible ejecutar comandos debido al incorrecto procesado de las variables de entorno, en determinadas circunstancias, esto puede ser explotable remotamente.

El problema reside en que bash permite la declaración de funciones (como cualquier otro lenguaje interpretado) y no son validadas correctamente cuando son almacenadas en una variable. Con ejemplos seguro que se ve mejor.

Una función se declara de la siguiente forma:

$ cat test.sh
#!/bin/bash
function hola() {
    echo "Hola mundo"
}
hola

$ bash test.sh
Hola mundo

Pero por desgracia bash procesa todo el contenido de la variable y continua ejecutando incluso cuando termina la función:

$ VAR="() { echo 'Hola mundo'; }; echo 'Adios mundo'" bash -c "echo Prueba"
Adios mundo
Prueba

En la prueba anterior, se esperaba que únicamente se mostrase «Prueba», pero acaba procesando el echo de «Adios mundo».

Esto tiene implicaciones en servicios remotos, en especial en páginas web con CGIs que leerán las variables enviadas por el cliente como cabeceras (y que pueden contener comandos) y ejecutarán su contenido cuando se invoque bash. Explotar CGIs escritos en bash será trivial y aunque parezca mentira, existen miles:

Otras implicaciones conocidas hasta ahora, pero que seguro que aumentan estos días, son:

  • Uso en ForceCommand de SSH para limitar capacidades de ejecución de comandos
  • Otros CGI (como php, perl, etc) que lancen subshells con llamadas del tipo system()
  • Clientes DHCP que lancen shells.
  • Herramientas y aplicaciones con SUID que invoquen bash para alguna acción.
  • Sistemas móviles que utilicen bash, como Android
  • Otros sistemas con Linux, como routers (que generalmente lanzan pings, traceroutes, etc), modems, televisores, etc..

La alegría de la huerta. Nos esperan días con muchas noticias sobre nuevos impactos, Eso seguro.

Para solucionar el problema tan solo hay que esperar a que saquen el parche (y funcione), cosa que ya ha ocurrido en las distribuciones más populares, pero que tardará tiempo en sistemas embebidos o poco mantenidos.

Algunos como GNU Bash, Redhat/Fedora, CentOS, Debian, Ubuntu y Novel/SuSE ya han publicado las actualizaciones.

Ejemplo de un código vulnerable y su explotación sacado de un comentario de reddit:

[root@host cgi-bin]# rm -fr /tmp/aa
[root@host cgi-bin]# cat /var/www/cgi-bin/hi
#!/bin/bash
echo "Content-type: text/html"
echo ""
echo "hai"
[root@host cgi-bin]# curl -k -H 'User-Agent: () { :;}; echo aa>/tmp/aa'  https://localhost/cgi-bin/hi
hai
[root@host cgi-bin]#  tail -n1 /var/log/httpd/ssl_access_log
::1 - - [24/Sep/2014:18:22:05 +0200] "GET /cgi-bin/hi HTTP/1.1" 200 4 "-" "() { :;}; echo aa>/tmp/aa"
[root@host cgi-bin]#  ls -l /tmp/aa
-rw-r--r--. 1 apache apache 3 24 sept. 18:22 /tmp/aa
[root@host cgi-bin]# sestatus
SELinux status:                 enabled
[root@host cgi-bin]# yum update

PRUEBA DE CONCEPTO

En la siguiente imagen se puede apreciar el ataque funcionando en un sitio de prueba:

  1. Inicialmente se ejecuta normalmente el SH en un navegador y se aprecia el resultado.
  2. A través de línea de comando se ejecuta una petición al script SH y se modifica el User-Agent
  3. Aquí se envía la cadena de comandos bash a ejecutar en en el servidor -en este caso la creación de un archivo de prueba-
  4. Se verifica que el SH se ejecuta y el archivo se crea en /tmp/test/
  5. Se observa el ataque en el Log de Apache.

Referencias:

Fuente: Security by Default

Visitas: 5