Un error de condición de carrera ha sido arreglado en el núcleo principal de Linux, pero algunas distribuciones Red Hat, Canonical y Debian aún no tienen parche.
Un error de escalamiento de privilegios local ha sido arreglado en el núcleo de Linux, pero varias distribuciones aún faltan por publicar sus actualizaciones.
Administradores deben mitigar por sí mismos la vulnerabilidad en servidores Linux y estaciones de trabajo, así como revisar los planes de actualización de las distribuciones.
“El error de condición de carrera en el driver n_hdlc (drivers/tty/n_hdlc.c) en el núcleo de Linux hasta la versión 4.10.1 (CVE-2017-2636) puede causar un error de doble liberación en la función n_hdlc_release() al acceder a la lista n_hdlc.tbuf”, dijo Alexander Popov, un investigador de Positive Technologies en Rusia, quienes encontraron y reportaron la falla. Un usuario local sin privilegios que puede manejar la disciplina de línea HDLC en el dispositivo tty puede explotar esta falla y obtener privilegios incrementados sobre el sistema afectado o causar una condición para una denegación de servicio.
La vulnerabilidad, que obtuvo una puntuación base de 7.8 bajo el criterio de Common Vulnerability Scoring System (CVSS) 3.0, no necesita ser activada por ninguna interacción del usuario, además la complejidad del ataque es considerada baja. Explotar esta falla no requiere hardware o periféricos especializados para realizar el ataque en el sistema objetivo. Para CVSS, la vulnerabilidad es considerada de alta severidad por el impacto que puede causar.
El parche a esta vulnerabilidad fue enviado al núcleo principal de Linux el 28 de febrero, y la nueva versión del núcleo fue publicada el 7 de marzo. Algunas de las versiones anteriores del núcleo hasta la versión 4.10.1 son consideradas vulnerables.
La vulnerabilidad puede afectar servidores Linux y estaciones de trabajo, además de máquinas virtuales, pero casi no a contenedores. “Debido a las configuraciones de ioctl en Docker, esto no debería ser ejecutable desde un contenedor,” afirmó Patrick Carey de la compañía de seguridad de código abierto Black Duck Software. “Obviamente si tú tienes acceso al servidor donde se aloja el contenedor, los resultados pueden ser impredecibles.”
Esperando los parches
Red Hat ha calificado el problema como uno de severidad importante y ha prometido que arreglará el error en actualizaciones futuras. El problema afecta al núcleo de baja latencia incluido con Red Hat Enterprise MRG2, el núcleo-rt incluido con Red Hat Enterprise Linux 7 y los paquetes en Red Hat Enterprise Linux 5/6/7. No afecta a los núcleos que vienen incluidos en Red Hat Enterprise Linux 5.
Canonical ha calificado el problema como de alta severidad, ya que todas las versiones de Ubuntu están afectadas. La compañía ha publicado las correcciones del núcleo principal de Linux para Ubuntu Linux 12.04 LTS (Precise Pangolin), 14.04 LTS (Trust Tahr), Ubuntu 16.04 LTS (Xenial Xerus), and Ubuntu 16.10 (Yakket Yak). Las actualizaciones para Ubuntu Core 15.04 y Ubuntu Linux 17.04 (Zesty Zapus) todavía siguen pendientes. Canonical ha actualizado algunos paquetes de núcleos como linux-ti-omap4 (para 12.04 LTS) y Linux-gke (16.04 LTS), pero no planea actualizar otros como linux-maguro (para 14.04 LTS). Los arreglos todavía necesitan ser incorporados para algunos paquetes como Linux-lts-vivid para la versión 14.04 LTS y Linux-rapi2 para 17.04. Los administradores deberán consultar la lista completa de Canonical para determinar el estado de su kernel y distribución.
Varios paquetes de Linux Debian 6.0 para sparc, s/390, powerpc, mips, ia-64, ua-32, arm, amd64, el núcleo de Debian Wheezy 3.2.78-1, jessie 3.16.39-1 y stretch 4.9.13-1 son vulnerables. La versión más reciente de Debian jessie, 3.16.39-1+deb8u2 y wheezy,3.2.86-1 ya tienen el módulo de sus núcleos arreglados.
¿Qué hacer mientras tanto?
Mientras el núcleo actualizado está disponible, los administradores de Linux pueden mitigar la vulnerabilidad previniendo manualmente que el núcleo sea cargado. El módulo n_hdlc usualmente es cargado automáticamente cuando una aplicación intenta usar la disciplina de línea HDLC desde un espacio de usuario, pero puede ser bloqueada usando las reglas modprob. Al ejecutar # echo “install n_hdlc /bin/true” >> /etc/modprobe.d/disable-n_hdlc.conf como usuario root puede prevenir la carga accidental o intencional del módulo. El sistema necesitará ser reiniciado si los módulos n_hdlc ya han sido cargados.
“Red Hat Product security cree que este método es uno robusto para prevenir la carga accidental del módulo, aún para usuarios con privilegios”, escribió Red Hat en su recomendatorio sobre el problema.
Cualquier distribución Linux que tenga la línea CONFIG_N_HDLC=m en la configuración de su núcleo probablemente está afectado ya que usa el driver vulnerable.
Popov descubrió el error mientras investigaba un crash sospechoso del núcleo que ocurrió al usar una herramienta de fuzzing no supervisada para llamadas de sistemas Linux, syzkaller. La vulnerabilidad tiene que ver con el hecho de que n.hdlc usa listas simples ligadas, hechas por el mismo programa, que usa como buffers de datos y un apuntador n_hdlc.tbuf para reenviar buffers después de que ocurra un error. Si los buffers de datos no pueden ser enviados por alguna razón, entonces la dirección es guardada en n_hdlc.tbuf. El buffer es la primera cosa enviada la siguiente vez que hdlc_send_frames() es llamada. La función flux_tx_queue() y hdlc_send_frames() pueden agregar al buffer en la la lista tx_free_buf_list dos veces, causando que se intente liberar dos veces.
El error parece tener casi 8 años de antigüedad, ya que fue creado en el 2009 cuando se agregó código para limpiar el buffer del módulo n_hdlc. Fue arreglado usando una lista ligada estándar del núcleo protegida y quitando el apuntador, dijo Popov. En caso de un error de transmisión, el buffer de datos se coloca después de la cabeza de la lista tx_bf_list.
La vulnerabilidad existe en un componente de código abierto bastante usado (en este caso, el núcleo de Linux) en varias versiones importantes y distribuciones, pero “la única manera que la mayoría de los usuarios de Linux se enteren es si revisan activamente el NVD [National Vulnerability Database] o el noticiero de seguridad de su provedor de Linux”, dijo Carey. Es altamente probable que miles de sistemas vayan a permanecer sin parcharse y vulnerables, especialmente cuando se ejecuta Linux en un hardware no estandarizado como las Raspberry Pi.
Fuente:https://www.seguridad.unam.mx/
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
