Un fallo TCP del kernel de Linux con una puntuación CVSS de 9,8 afecta a Ubuntu, Red Hat y otras distribuciones

Anthropic afirmó el 27 de octubre que su modelo de inteligencia artificial escribió un exploit que aprovecha el fallo para permitir que un atacante remoto sin credenciales ejecute comandos como root en servidores Linux que tengan un servicio de escucha de TCP multipath (MPTCP).

A fecha de 29 de octubre, Ubuntu y RHEL todavía no han publicado una versión corregida del kernel. Red Hat, Amazon, Oracle y SUSE asignan a la vulnerabilidad puntuaciones de entre 5,9 y 8,1, inferiores al 9,8 del equipo del kernel.

El fallo consiste en una condición de carrera en el código que configura nuevas conexiones TCP sobre IPv4. Puede provocar que el kernel lea memoria que ya ha liberado, un tipo de error conocido como use-after-free.

La corrección del kernel reconoce al investigador de Anthropic Xinyang Ge por haber comunicado el error. Ni el registro CVE ni la corrección mencionan TCP multipath (MPTCP). La relación entre esta función y el fallo procede de la publicación de Anthropic.

MPTCP permite que una única conexión utilice varias rutas de red al mismo tiempo. En Linux, una aplicación debe solicitar MPTCP cuando abre un socket.

La publicación de Anthropic afirma que el fallo «se corrigió en el repositorio principal y se adaptó a todas las ramas estables del kernel que siguen mantenidas». Para los usuarios de las distribuciones, la corrección solo llega cuando el proveedor publica un paquete del kernel que la incorpora. Debian, Oracle Linux, SUSE y Amazon Linux ya han distribuido paquetes corregidos, al menos para algunas versiones de sus kernels, pero Ubuntu y RHEL todavía no.

Qué distribuciones tienen una corrección

Ubuntu también considera vulnerables sus kernels para la nube, FIPS y tiempo real, o indica que las correcciones siguen en desarrollo. Red Hat afirma que sus correcciones están «actualmente aplazadas hasta una futura actualización». Ni Red Hat ni Ubuntu han anunciado una fecha de publicación.

Cómo funciona el fallo

La condición de carrera se produce durante el establecimiento de la conexión TCP. Cuando una conexión se completa, el kernel transfiere al nuevo socket las opciones IP almacenadas con la solicitud pendiente, sin copiarlas.

Si ese socket se destruye mientras otra CPU sigue utilizando esas opciones para responder a una solicitud de conexión retransmitida, el kernel lee memoria que ya ha sido liberada.

IPv6 no se ve afectado por esta condición de carrera porque el kernel copia las opciones en las conexiones IPv6.

El fallo se introdujo en Linux 4.4. Los desarrolladores del kernel aplicaron una corrección el 5 de octubre, diez días antes de que se publicara el CVE.

La corrección hace que el kernel espere a que las demás CPU terminen de leer las opciones antes de liberar la memoria correspondiente.

Por qué difieren las puntuaciones

El equipo de CVE del kernel añadió la puntuación de 9,8 al registro CVE el 24 de octubre, nueve días después de publicar el CVE.

Su evaluación supone que un atacante envía una solicitud de conexión TCP que contiene opciones IPv4 Record Route o Timestamp y después retransmite la solicitud para intentar ganar la condición de carrera. El equipo considera baja la complejidad del ataque, ya que ambas partes de la carrera pueden ser «provocadas por el atacante».

En esas condiciones, el equipo señala que el fallo podría devolver al atacante datos de memoria cercana del kernel, corromper la memoria del kernel o provocar una caída del sistema.

A fecha de 28 de octubre, la Base de Datos Nacional de Vulnerabilidades (NVD) todavía no había añadido una puntuación propia y mostraba la del equipo del kernel, de 9,8. La página de Ubuntu también muestra esa puntuación.

La página CVE de Red Hat califica el fallo como moderado y le asigna 5,9 porque considera difícil ganar la condición de carrera. Según Red Hat, el resultado más probable es una caída del kernel, mientras que la corrupción de memoria es teóricamente posible. La empresa afirma que «no se ha demostrado ningún impacto en la confidencialidad ni en la integridad».

Sin embargo, el archivo de avisos de seguridad de Red Hat, actualizado el 29 de octubre, clasifica el impacto como importante y asigna al fallo una puntuación de 8,1, con un impacto elevado sobre la confidencialidad y la integridad. El mismo día, el seguimiento del error de Red Hat cambió la gravedad del problema de media a alta. Ese día, la página CVE seguía indicando una gravedad moderada y una puntuación de 5,9.

Oracle y SUSE también asignan al fallo una puntuación de 8,1, con el mismo vector CVSS que el archivo de avisos de Red Hat. Estas puntuaciones coinciden con las del equipo del kernel en todos los parámetros, excepto en la complejidad del ataque: los proveedores la consideran alta, mientras que el equipo del kernel la considera baja. Amazon le asigna 7,0.

Qué afirma Anthropic que ha desarrollado

Anthropic describió el exploit de Linux en una publicación del 27 de octubre sobre vulnerabilidades que su modelo de IA, Claude, había encontrado y explotado. The Hacker News informó sobre la publicación el 28 de octubre. Según Anthropic, Claude escribió el exploit después de recibir «instrucciones iniciales».

El exploit funciona en dos etapas. Primero, la condición de carrera hace que el kernel envíe bytes adicionales al atacante. Cuando una de esas respuestas contiene una dirección del kernel, el atacante puede eludir KASLR, la técnica de aleatorización de las direcciones de memoria del kernel.

En segundo lugar, el mismo fallo provoca un desbordamiento de búfer y sobrescribe un puntero de función de retorno de llamada (callback) con la dirección de una carga útil que el atacante ya había colocado en la memoria del kernel. Cuando el kernel llama a ese puntero, la carga útil ejecuta como root un comando de shell elegido por el atacante.

Según la empresa, perder la condición de carrera solo hace fracasar ese intento de conexión y no bloquea el sistema, por lo que el atacante puede seguir intentándolo. En su prueba, obtener una dirección del kernel requirió 48 minutos, y conseguir la ejecución de comandos necesitó cinco minutos adicionales.

La publicación no incluye el código del exploit, la versión del kernel ni la configuración que Anthropic utilizó en sus pruebas.

Red Hat afirma que un atacante remoto capaz de acceder a un servicio TCP expuesto podría desencadenar la condición de carrera. Sin embargo, el exploit de Anthropic que permite obtener acceso como root se dirigía a servidores con un servicio de escucha MPTCP. La publicación no indica si los servidores que carecen de este servicio pueden verse comprometidos de la misma manera.

A fecha de 29 de octubre, ninguno de los avisos de los proveedores, el registro CVE ni la publicación de Anthropic informa de ataques que hayan aprovechado esta vulnerabilidad. Tampoco aparece en una copia del catálogo de vulnerabilidades explotadas conocidas de CISA que el CIRCL de Luxemburgo actualizó por última vez el 28 de octubre.

Qué hacer ahora

Si tu distribución ya ha publicado un kernel corregido, instálalo. La tabla anterior recoge los paquetes y avisos correspondientes a Debian, Oracle Linux, SUSE y Amazon Linux.

Si compilas tu propio kernel, la corrección está incluida en Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 y 7.3. El equipo de CVE del kernel recomienda actualizar a la última versión estable del kernel. También señala que la comunidad del kernel no admite seleccionar e incorporar correcciones individuales (cherry-picking).

Ubuntu, RHEL y algunas versiones de Amazon Linux y SUSE todavía no disponen de un kernel corregido que se pueda instalar. Red Hat afirma que ninguna medida de mitigación disponible cumple sus requisitos de facilidad de implementación, adecuación a la mayoría de las instalaciones y estabilidad. Ninguno de los demás avisos de los proveedores menciona una alternativa.

Los avisos de seguridad y la publicación de Anthropic no indican si desactivar TCP multipath o bloquear las solicitudes de conexión entrantes que incluyan opciones IP reduciría el riesgo.