Durante la tarde de ayer saltaba la alerta a consecuencia del anuncio realizado por la empresa de seguridad Qualys sobre el descubrimiento de una grave vulnerabilidad en la librería glibc de Linux. Esta vulnerabilidad permitiría a un atacante tomar remotamente el control de un sistema sin conocer las credenciales de acceso.
Gracias a la colaboración realizada entre esta compañía y varias distribuciones de Linux se ha conseguido lanzar parches que solucionan esta grave vulnerabilidad al mismo tiempo que se informa de la misma, instando a todos los usuarios que utilicen una distribución afectada por la vulnerabilidad a actualizar lo antes posible. Gracias a los investigadores que han avisado de esta vulnerabilidad podemos ofrecer más información en este post a partir del original publicado en el blog de Qualys.
Pero empecemos por el principio.
¿Qué es glibc?
La librería GNU C o glibc es una implementación de la librería C estándar y una parte fundamental del sistema operativo Linux. Sin esta librería, un sistema Linux no puede funcionar.
¿Cómo funciona la vulnerabilidad?
Durante una auditoría del código, los investigadores de Qualys descubrieron un fallo de desbordamiento de buffer en la función __nss_hostname_digits_dots() de glibc. Este fallo puede ser aprovechado remotamente usando las funciones gethostbyname*().
Las aplicaciones tienen acceso al traductor de DNS principalmente mediante el conjunto de funciones gethostbyname*() y son estas funciones las que se encargan de traducir un nombre de dominio a una dirección IP.
¿Cuál es el riesgo?
Existe un riesgo de ejecución remota de código si un atacante consigue aprovechar esta vulnerabilidad, ya que obtendría el control completo del sistema vulnerable.
¿Que ataque se podría realizar?
Durante las pruebas realizadas por los investigadores de Qualys, estos consiguieron desarrollar una prueba de concepto en la que enviaban un email creado de forma específica y consiguieron obtener una shell remata en un sistema Linux, saltándose todas las protecciones existentes (como ASLR, PIE y NX) tanto en sistemas de 32 como de 64 bits.
¿Qué puede hacerse para minimizar los riesgos?
La mejor manera de minimizar el riesgo es aplicando el parche proporcionado por las distintas distribuciones de Linux. Los investigadores han trabajado codo con codo con los creadores de las diferentes distribuciones y el parche se encuentra disponible desde ayer, 27 de enero.
¿Por qué se llama GHOST?
Esta vulnerabilidad es conocida como GHOST porque puede ser activada por las funciones GetHOST.
¿Se trata de un fallo de diseño?
No, es un problema de implementación en las versiones del software afectadas.
¿Que distribuciones y versiones de Linux se ven afectadas?
La primera versión de la librería GNU C afectada por esta vulnerabilidad es la glibc-2.2, lanzada el 10 de noviembre de 2000. Se han identificado una serie de factores que mitigan el impacto de este fallo y, en particular, se ha descubierto que fue arreglado el 21 de mayo de 2013 (entre el lanzamiento de las versiones glibc-2.17 y glibc-2.18).
Sin embargo, no fue reconocido como un fallo de seguridad y, en consecuencia, la mayoría de las versiones estables y de soporte de larga duración de las distribuciones se encuentran expuestas. Esto incluye a Debian 7 (wheezy), Red Hat Enterprise Linux 6 y 7, CentOS 6 y 7 y Ubuntu 12.04, por ejemplo.
¿Se puede descargar el exploit?
De forma responsable, los investigadores de Qualys quieren dar el tiempo suficiente a todo el mundo para que parchee sus sistemas. De acuerdo con sus datos, una vez la vulnerabilidad haya llegado a la mitad de su ciclo de vida lanzarán el exploit de forma pública.
De esta forma se evita que se explote activamente en miles de sistemas vulnerables al tiempo que urge a actualizar a aquellos que utilicen una distribución que esté afectada por esta vulnerabilidad.
Guía de actualización para sistemas Debian
Tomada de kinomakino:
Esta es una pequeña guía para sistemas basados en Debian, apt-get friendly, para actualizar mi Kali linux a modo de ejemplo. Espero que les sirva de ayuda.
Lo primero que hacemos es salir del entorno gráfico, generalmente con Ctrl+Alt+F1.
Paramos nuestro servidor gráfico, en mi caso, GDM, genome desktop manager.
Comprobamos la versión de glibc6, con el comando dkpg -s glibc6. Vemos la salida, y comprobamos la versión.
En el fichero de fuentes, /etc/apt/sources.list, añadimos el repositorio de Debian para la versión SID. deb sid main. Hacemos un apt-get update para actualizar la lista de paquetes.
Ejecutamos la actualización del paquete en concreto, con apt-get install glibc6.
Una vez terminado, volvemos a comprobar la versión del paquete, esta vez 2.19-13 a priori, no vulnerable.
Para comprobar qué servicios están usando esta librería, podemos ejecutar este comando: lsof | grep libc | awk ‘{print $1}’ | sort | uniq. En teoría deberíamos reiniciar los servicios que se nos muestren, aunque sinceramente, creo que la mejor opción es reiniciar.
Podemos comprobar si estamos protegidos o no con esta sencilla prueba de concepto:
wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c
gcc gistfile1.c -o CVE-2015-0235
./CVE-2015-0235Podemos apreciar que ya no somos vulnerables.
Mientras que otros sistemas sin actualizar, por ejemplo Centos 6.5, nos aparece:
Conclusión
Estamos sin duda, junto con Shellshock, ante una de las vulnerabilidades en sistemas Linux más importantes de los últimos años. Sin duda el buen trabajo realizado por los investigadores que han descubierto esta vulnerabilidad evitará que muchos sistemas vean comprometida su seguridad.
Sin embargo, es muy probable que queden muchos sistemas sin actualizar, especialmente aquellos que gobiernan dispositivos englobados dentro del Internet de las cosas y eso es algo que debería preocuparnos a medio plazo.
