El blog de seguridad online de Google da a conocer un problema de seguridad en la biblioteca de C de GNU. El resolver DNS del lado cliente es vulnerable a un desbordamiento de buffer de pila cuando se utiliza la función getaddrinfo(). Los programas que utilicen esta función pueden ser explotados con nombres de dominio o servidores DNS controlados por un atacante, o a través de un ataque man-in-the-middle.





Una vulnerabilidad fue encontrada en GNU glibc y clasificada como crítica. La función send_dg/send_vc del archivo resolv/res_send.c es afectada por esta vulnerabilidad. Mediante la manipulación del parámetro MAX_PACKET de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. Esto tiene repercusión sobre la confidencialidad, integridad y disponibilidad.

La vulnerabilidad fue publicada el 2016-02-16 por Robert Holiday de Ciena con identificación Bug 18665 con un advisory (Mailing List) (confirmado). El advisory puede ser descargado de sourceware.org. La publicación se realizó con la cooperación del fabricante. La vulnerabilidad es identificada como CVE-2015-7547. La vulnerabilidad es relativamente popular y aunque es muy compleja. El ataque se puede efectuar a través de la red. La explotación no necesita ninguna autentificación específica. Los detalles técnicos asi como un exploit público son conocidos.

Un exploit fue publicado después de inmediatamenteFue declarado como proof-of-concept. Por lo menos durante 2847 días, esta vulnerabilidad fue clasificada como exploit día cero.

Aplicando el parche 8479f23a es posible eliminar el problema. Poniendo el filtro UDP DNS Packet Length > 512 Bytes / TCP Reply Length > 1024 Bytes en el firewall, es posible mitigar el efecto del problema. El mejor modo sugerido para mitigar el problema es aplicar el parche al componente. Una solución posible ha sido publicada inmediatamente después de la publicación de la vulnerabilidad. La vulnerabilidad se tratará con las siguientes líneas de código:

if (status  NSS_STATUS_SUCCESS
   && (status2  NSS_STATUS_TRYAGAIN
      && *errnop == ERANGE && *h_errnop != NO_RECOVERY))
   status = NSS_STATUS_TRYAGAIN;

La grave vulnerabilidad en la libreria glibc utilizada en sistemas GNU/Linux permite la ejecución de código malicioso. Para ponernos en situación, se sospecha que la vulnerabilidad se extiende a un gran número de aplicaciones, incluyendo prácticamente a todas las distribuciones GNU/Linux; lenguajes de programación como Python, PHP, y Rubi on Rails; y muchas otras que utilizan código GNU/Linux para buscar una dirección IP. La mayoría del software utilizado en Bitcoins está afectado también.

El blog de seguridad online de Google da a conocer un problema de seguridad en la biblioteca GNU C; una solución, soluciones, y una prueba de concepto-explotan están incluidos. "El sistema de resolución de cliente glibc DNS es vulnerable a un desbordamiento de búfer basado en pila cuando se utiliza la función de biblioteca getaddrinfo (). Software que usa esta función puede ser explotado con los nombres de dominio controlado por el atacante, servidores DNS controlado por el atacante, o por medio de un hombre -in-the-middle ".

Recientemente, un ingeniero de Google se dio cuenta de que su cliente SSH segfaulted cada vez que trataban de conectarse a un host específico. Que el ingeniero presentó un boleto para investigar el comportamiento y después de una intensa investigación descubrió que el problema residía en glibc y no en SSH como esperábamos.

Gracias a la observación aguda de este ingeniero, hemos sido capaces de determinar que la cuestión podría permitir la ejecución remota de código. inmediatamente comenzamos un análisis a fondo de la cuestión para determinar si podría ser explotada, y las posibles correcciones. Vimos esto como un reto, y después de algunas sesiones de hacking intensos, hemos sido capaces de crear explotar un trabajo completo!




En el curso de nuestra investigación, y para nuestra sorpresa, hemos aprendido que los mantenedores de glibc previamente habían sido alertados de la cuestión a través de su gestor de fallos en julio de 2015. (bug). No podríamos decir inmediatamente si la corrección de errores estaba en marcha, así que trabajamos duro para asegurarse de que entiende el problema y luego se acercó a los mantenedores de glibc. Para nuestro deleite, Florian Weimer y Carlos O'Donell de Red Hat también habían estado estudiando el impacto del error, aunque sea de forma totalmente independiente! Debido a la naturaleza sensible del tema, la investigación, la creación de parches y pruebas de regresión realizado principalmente por Florian y Carlos había continuado "off-bug".

Esta fue una coincidencia asombrosa, y gracias a su arduo trabajo y la cooperación, hemos sido capaces de traducir el conocimiento de ambos equipos en una prueba de parche y la regresión completa para proteger a los usuarios de glibc.

El parche está disponible aquí.

• https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html

Resumen Edición:

Nuestras investigaciones iniciales mostraron que la cuestión afecta todas las versiones de glibc desde la 2.9. Definitivamente, usted debe actualizar si se encuentra en una versión anterior sin embargo. Si se detecta la vulnerabilidad, los propietarios de máquinas podrían tomar medidas para mitigar el riesgo de un ataque.

El sistema de resolución de cliente DNS glibc es vulnerable a un desbordamiento de búfer basado en pila cuando se utiliza la función de biblioteca getaddrinfo (). Software utilizando esta función puede ser explotado con los nombres de dominio controlado por el atacante, servidores DNS controlado por el atacante, o por medio de un ataque man-in-the-middle.

Google ha encontrado algunos factores atenuantes que pueden ayudar a prevenir la explotación si no es capaz de parchear inmediatamente a su instancia de glibc. La vulnerabilidad se basa en un gran tamaño (2048+ bytes) UDP o TCP respuesta, que es seguido por otra respuesta que se sobreponen a la pila. Nuestra mitigación sugerida es la de limitar la respuesta (es decir, a través de DNSMasq o programas similares) Tamaños aceptados por la resolución de DNS a nivel local, así como para garantizar que las consultas DNS sólo se envían a los servidores DNS que limitan el tamaño de la respuesta de las respuestas UDP con el bit de truncamiento conjunto.

Información técnica:

glibc se reserva 2048 bytes en la pila a través de alloca () para la respuesta de DNS en _nss_dns_gethostbyname4_r () para la celebración de las respuestas a una consulta DNS.



Más tarde, en send_dg () y send_vc (), si la respuesta es mayor que 2048 bytes, un nuevo búfer se asigna desde el montón y toda la información (tampón puntero, nuevo tamaño de memoria intermedia y el tamaño de respuesta) se actualiza.
 
Bajo ciertas condiciones, un desajuste entre el búfer de pila y la nueva asignación del heap. El efecto final es que el búfer de pila se utiliza para almacenar la respuesta DNS, a pesar de que la respuesta es mayor que el búfer de pila y se asignó un búfer de pila. Este comportamiento conduce al desbordamiento de pila.

Los vectores para desencadenar este desbordamiento de memoria son muy comunes y pueden incluir ssh, sudo, y el rizo. Estamos seguros de que los vectores de explotación son diversa y extendida; no hemos tratado de enumerar estos vectores más.

Explotación:

la ejecución de código remoto es posible, pero no es sencillo. Se requiere pasar por la reducción de seguridad presentes en el sistema, tales como ASLR. No vamos a lanzar nuestro código de explotación, sino una prueba no como arma de concepto ha sido puesto a disposición simultáneamente con esta entrada del blog. Con esta prueba de concepto, se puede comprobar si se ven afectados por este problema, y verificar factores atenuantes que tal vez deseen adoptar.

• https://github.com/fjserna/CVE-2015-7547

Como se puede ver en la sesión de depuración de abajo somos capaces de controlar de manera fiable EIP / PIR.

(gdb) x/i $rip
=> 0x7fe156f0ccce <_nss_dns_gethostbyname4_r>: req
(gdb) x/a $rsp
0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042

Cuando el código se bloquea inesperadamente, puede ser un signo de algo mucho más importante de lo que parece; ignorar los accidentes en su propio riesgo!

Mitigaciones - Contramedidas - Soluciones - Parches manuales

Para los sistemas que no podemos parchear inmediatamente, una manera de prevenir la explotación es configurar los resolvers para evitar que envíen respuestas mayores de 2048 bytes.

Por ejemplo: - en BIND - añade la siguiente línea en la sección de options de named.conf:

max-udp-size 2048;

- en Unbound - añade la siguiente línea en la sección de server de unbound.conf:

max-udp-size: 2048

Tampoco es mala idea activar ASLR:

sysctl -w kernel.randomize_va_space=2

• 0 - nada de aleatorización, todo es estático
• 1 - aleatorización conservadora, es decir, sólo librerías compartidas, stack, mmap(), VDSO y heap.
• 2 - aleatorización completa incluida la memoria administrada mediante brk() 

Mitigating factors for UDP include:
- A firewall that drops UDP DNS packets > 512 bytes.
- A local resolver (that drops non-compliant responses).
- Avoid dual A and AAAA queries (avoids buffer management error) e.g.
Do not use AF_UNSPEC.
- No use of `options edns0` in /etc/resolv.conf since EDNS0 allows
responses larger than 512 bytes and can lead to valid DNS responses
that overflow.
- No use of `RES_USE_EDNS0` or `RES_USE_DNSSEC` since they can both
lead to valid large EDNS0-based DNS responses that can overflow.
Mitigating factors for TCP include:
- Limit all replies to 1024 bytes.

Mitigations that don't work:
- Setting `options single-request` does not change buffer management
and does not prevent the exploit.
- Setting `options single-request-reopen` does not change buffer
management and does not prevent the exploit.
- Disabling IPv6 does not disable AAAA queries. The use of AF_UNSPEC
unconditionally enables the dual query.
- The use of `sysctl -w net.ipv6.conf.all.disable_ipv6=1` will not
protect your system from the exploit.
- Blocking IPv6 at a local or intermediate resolver does not work to
prevent the exploit. The exploit payload can be delivered in A or
AAAA results, it is the parallel query that triggers the buffer
management flaw.

Las principales distribuciones Linux ya ofrecen actualizaciones:

• Debian: http://www.debian.org/security/2016/dsa-3481
• Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=574880
• Ubuntu: http://www.ubuntu.com/usn/usn-2900-1/
• Red Hat: https://rhn.redhat.com/errata/RHSA-2016-0225.html y https://rhn.redhat.com/errata/RHSA-2016-0176.html

Fuentes:
https://www.meneame.net/m/tecnolog%C3%ADa/linux-vulnerabilidad-ejecucion-remota-codigo-glibc
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
https://googleonlinesecurity.blogspot.com.es/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
http://www.scip.ch/es/?vuldb.80983
http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/