Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

Falla de seguridad crítica: desbordamiento de buffer basado en la pila glibc en getaddrinfo() (CVE-2015-7547)

El paquete glibc contiene bibliotecas estándar, que son utilizadas por parte de múltiples programas en el sistema. Con el fin de ahorrar espacio de disco y memoria, así como facilitar las actualizaciones, se mantiene en un lugar el código del sistema común y se comparte entre programas. Este paquete contiene la biblioteca C estándar frente a la cual se enlazan todos los programas GNU/Linux. La biblioteca libresolv empaquetada junto con glibc proporciona funcionalidades que proporcionan traducción entre los nombres del host y las direcciones de IP. nss_dns es el componente glibc que proporciona el módulo de servicio NSS (del inglés Name Service Switch), utilizado por libresolv para realizar búsquedas DNS.

Información de fondo

Se encontró un desbordamiento del búfer basado en pila de libresolv en el código que realiza peticiones DNS A/AAAA dobles. Un atacante remoto podría crear respuestas DNS especialmente diseñadas que pueden hacer que libresolv se cuelgue o que potencialmente ejecute códigos con los permisos del usuario en la biblioteca. El desbordamiento del búfer ocurre en la función send_dg (para solicitudes UDP) y send_vc (para peticiones TCP) en libresolv. El problema sólo se expone cuando se llama a libresolv desde el módulo de servicio NSS nss_dns. Esta falla ha sido asignada a CVE-2015-7547.

Las aplicaciones que llaman a getaddrinfo con la familia de direcciones AF_UNSPEC son afectadas, a excepción de Red Hat Enterprise Linux 6.4, en donde las aplicaciones también se afectan si usan la familia de direcciones AF_INET6. Las aplicaciones que solo usan las funciones antiguas gethostbyname o las funciones libresolv tal como res_search (y no getaddrinfo) no son afectadas.

Este problema no afectó la versión de glibc empaquetada con Red Hat Enterprise Linux 5 o versiones anteriores. Este problema afectaba las versiones de glibc empaquetadas con Red Hat Enterprise Linux 6 y 7.

Impacto

Red Hat Product Security ha categorizado este problema como de impacto Critical.

Mitigación

En una configuración libresolv predeterminada, el vector basado en UDP es mitigado usando un resolver de DNS confiable que cumpla con los requerimientos del protocolo, en una red también confiable. Un resolver que cumpla con los requisitos no producirá la clase de respuestas de gran tamaño que son necesarias para explotar esta vulnerabilidad ya que, por defecto, el resolver de glibc no habilita EDNS0 y no solicita grandes respuestas.

El vector basado en TCP se puede mitigar por medio de un resolver recursivo confiable, en una red confiable que limita el tamaño de las respuestas DNS individuales a 1023 bytes o menores. Sin embargo, dicha funcionalidad no es común en implementaciones del resolver de DNS ya que daña al protocolo DNS (la opción de configuración del tamaño del búfer ofrecida por la mayoría de los resolvers solo aplica a UDP y no a TCP). El rechazar respuestas AAAA, sin limitar el tamaño de las respuestas A, no mitiga la vulnerabilidad.

Deshabilitar el soporte IPv6 en los sistemas afectados no mitiga la vulnerabilidad, ya que las búsquedas duales A/AAAA se realizan incluso cuando el sistema no tiene soporte IPv6.

Productos afectados y solución

Todas las versiones del paquete glibc incluidas con Red Hat Enterprise Linux 6 y 7 están afectadas por esta falla. Vea la tabla a continuación con los enlaces a las recomendaciones de seguridad respectivas que solucionan este problema:

Resolución

Producto Recomedación
Red Hat Enterprise Linux 6 RHSA-2016:0175
Red Hat Enterprise Linux 7 RHSA-2016:0176
Red Hat Enterprise Linux 6.2 Advanced Update Support RHSA-2016:0225
Red Hat Enterprise Linux 6.4 Advanced Update Support RHSA-2016:0225
Red Hat Enterprise Linux 6.5 Advanced Update Support RHSA-2016:0225
Red Hat Enterprise Linux 6.6 Extended Update Support RHSA-2016:0225
Red Hat Enterprise Linux 7.1 Extended Update Support RHSA-2016:0225


Después de que se aplica la actualización necesita reiniciar el sistema o reiniciar todos los servicios afectados:

Debido a que esta vulnerabilidad afecta a una gran cantidad de aplicaciones en el sistema, la manera recomendada y más segura para garantizar de que todas las aplicaciones utilicen los paquetes glibc actualizados es reiniciar el sistema.

En caso de que no se posible reiniciar todo el sistema, luego de aplicar la actualización, ejecute el siguiente comando para listar todos los procesos en ejecución (no restringido a servicios) aún utilizando la versión antigua [en memoria] de glibc en su sistema.

lsof +c0 -d DEL | awk 'NR==1 || /libc-/ {print $2,$1,$4,$NF}' | column -t

En la lista resultante identifique los servicios que se presentan al público y reinícielos. Si bien este proceso puede funcionar como una solución temporal, no es soportado por Red Hat y en caso de que surja un problema se le solicitará que reinicie el sistema antes de poder comenzar con la resolución del problema.

Preguntas Frecuentes

1. ¿SELinux bloquea este fallo de seguridad?
Una política SELinux apropiada puede contener algo del daño que un atacante pueda realizar y restringir su acceso al sistema, pero DNS es utilizado por muchas aplicaciones y componentes del sistema, por lo tanto, las políticas SELinux ofrecen solo una contención limitada para este problema.

2. Un resolver de DNS confiable ¿brinda protección frente a este problema?
Un resolver confiable en una configuración predeterminada que cumple con los requerimientos del protocolo no puede mitigar este problema ya que las vulnerabilidades potenciales pueden involucrar respuestas DNS bien formadas sintácticamente.

3. ¿Los binarios enlazados estáticamente son afectados por este fallo?
Red Hat no soporta el enlace estático de glibc. Sin embargo, si los clientes han construido aplicaciones enlazadas estáticamente usando el paquete glibc-static estas aplicaciones continuarán usando las copias del sistema de nss_dns y libresolv y si se instalan los paquetes glibc actualizados esta vulnerabilidad será abordada.

Reconocimientos

La vulnerabilidad fue descubierta por el Google Security Team y Red Hat.