Sin
lugar a dudas, una de las
vulnerabilidades del año, con el permiso de lo que quede por llegar, va a
ser esta que vamos a comentar. Su matrícula es CVE-2014-6271,
un número que va a rebotar en la cabeza de los administradores durante
bastantes meses.
Resulta que bash, el intérprete
de comandos más extendido en el mundo UNIX y derivados, tiene una curiosa y oscura funcionalidad que
puede ser abusada hasta el punto de retorcerla y usarla para ejecutar código
arbitrario en sistemas remotos.
Cuando lees una noticia así en
una lista de seguridad te viene a la cabeza la imagen de Gandalf el Gris,
detrás de ti, dándote golpecitos en la cabeza con su bastón mientras te grita
"Parchea!!! Insensatooooooo".
No es para menos…
Veamos primero la funcionalidad,
presente desde hace años en la misma página de
manual de bash:
"Functions
may be exported so that subshells automatically have them defined with the -f
option to the export builtin. A function definition may be deleted using the -f
option to the unset builtin"
Esto es un mecanismo similar a
cuando exportamos variables definidas en un entorno hacia otro proceso.
Vamos a probar la funcionalidad
de manera básica:
Primero creamos una función en el
intérprete
$function test { echo “hola”;}
Ahora le decimos a bash que la
exporte:
$ export –f test
Creamos un nuevo interprete…
$ bash
…y llamamos a la función que
acabamos de exportar:
$ test
hola
¿Dónde está el problema?
En el mecanismo que hace de
exportación de esa función, la forma en la que lo hace y como interpreta el
código que se inyecta en el entorno donde es exportada.
Para conseguir esa exportación de
funciones bash recurre a un pequeño "truco".
No exporta la función en sí, sino en una variable de entorno donde se
interpreta su valor como el cuerpo de una función. Vamos a verlo modificando el
ejemplo anterior, en vez de una función vamos a crear una variable de entorno:
$ test=’() {echo “hola”;}’
Exportamos, no una función sino
una variable que es lo que haría el intérprete:
$ export test
Ahora creamos un intérprete y
volvemos a invocar nuestra función 'test':
$ bash
$ test
hola
Curioso, ¿verdad?.
Bueno, pues cuando el entorno
recibe esta variable y el interprete detecta la siguiente cadena ‘() {‘ entiende
que está ante una función y comienza a interpretar su código. El problema y
aquí entramos en la zona peligrosa, es que no para de interpretar cuando
termina el cuerpo de la función y continua ejecutando el código que viene
detrás del cuerpo.
Por ejemplo, si el intérprete
tiene la siguiente variable-función exportada con código más allá de la
definición de la función:
’(){ echo “hola”; }; /bin/ls’
Terminará ejecutando el ‘/bin/ls’
cuando se esté interpretando esa cadena. No hará falta invocar la función,
justo cuando el interprete procese las cadenas detrás del cuerpo de la función
ejecutará el comando. Idealmente, debería de terminar justo cuando encuentre el
'};'
correspondiente pero inexplicablemente no lo hace y peor aun ejecuta
directamente ese código anexado al cuerpo de la función.
¿Por qué es peligroso?
Son muchísimos los vectores. Las
variables de entorno y los intérpretes de comandos son exportados y creados en infinidad
de situaciones. El peligro real, es cuando un proceso remoto acepta cadenas de
entrada y hace uso de ellas a través de variables de entorno. Ahí es donde se
puede inyectar una variable que contenga la cadena ‘(){‘ seguida de código
arbitrario, comandos que terminarán siendo ejecutados por el proceso.
El ejemplo, ya canónico y que
posiblemente veamos estampado en alguna camiseta, es la mínima expresión de
definición de una función en bash ”() { :;};”
Es fácil interpretarlo, el bloque
de la función definida contiene el carácter ‘:’ que en bash no hace nada,
simplemente devolver cero. Su correspondiente en C sería un “return 0;”. A esa
cadena por supuesto se le puede adosar cualquier comando, desde un ‘echo "yo estuve aquí" hasta un devastador
"rm –Rf"
o un "curl****/mi_shell.php"
para depositarla en "/var/www/".
En la lista oss-security,
donde se dio a
conocer públicamente el problema, exponen un escenario que caracteriza el
empleo de este ataque. Supongamos un script CGI que procesa las cabeceras HTTP
mapeando su clave, valor a variables de entorno. No cuesta imaginar que sucede
a partir de aquí. En el momento que se reciba una petición HTTP con una
cabecera "
cocinada" sería
posible que dicho sistema termine ejecutando los comandos que se inyecten desde
el exterior.
¿Quién la ha descubierto?
Su nombre es Stephane Chazelas.
Francés apasionado del mundo UNIX, Chazelas no es un nombre muy conocido, hasta
ahora, en la comunidad de seguridad. No se saben los detalles de cómo llegó
hasta la vulnerabilidad, pero es bastante posible que gracias a sus profundos
conocimientos de cómo funcionan las entrañas del sistema le proporcionará la
óptica necesaria para ver aquello que otros no vieron.
Chazelas apostó por informar
sobre su hallazgo a las vías adecuadas para que el problema fuese corregido
antes de ser anunciado, aunque casi al
final se filtró por algún medio y se precipitó la publicación de detalles y
parches.
Una reflexión
Si hacemos un repaso de las
últimas vulnerabilidades podríamos ver desde cierta perspectiva que un buen
grupo de ellas ya no se asientan sobre desbordamientos de memoria u otras,
llamémoslas vulnerabilidades clásicas. Este tipo de errores tira más al fondo,
a la lógica del diseño, un territorio donde los fuzzers comienzan a dejar de
ser eficaces (no dejarán de serlo completamente) y se confía más en una
comprensión del problema que solo te puede proporcionar la experiencia y la
capacidad de conectar los vértices que componen la figura final.
Este tipo de errores siempre han
existido y el otro tipo, los provocados por funcionalidades achacables a
ciertos lenguajes (sí, C y C++, vosotros dos) no van a dejar de dar quebraderos
de cabeza. Pero los problemas que derivan de un diseño inadecuado… ¿Qué IDS
está preparado para ello? Quizás pueda parar una cadena pasada por Shikata Ga
Nai ochocientas veces pero ¿Cómo paras una cabecera HTTP que contiene una
definición de una función que va a ser exportada y de paso ejecutado el código
que viene detrás? ¿Y la funcionalidad heartbeat de OpenSSL? No hay un detector
de diseños defectuosos, no lo habrá nunca. Jamás.
Más información
remote code execution through bash
Bash specially-crafted environment variables
code injection attack
David García
Twitter: @dgn1729
