Intersect insta a los operadores de Cardano a parchear una vulnerabilidad crítica del kernel de Linux CVE202698432

Intersect, organización de Cardano integrada por miembros, pidió a los operadores de stake pools aplicar parches y reiniciar sus productores de bloques y servidores de retransmisión a medida que haya correcciones disponibles para una vulnerabilidad crítica del kernel de Linux. En su actualización del 30 de octubre, Intersect indicó a los operadores revisar los kernels de ambos tipos de servidor e instalar el kernel corregido de su distribución en cuanto se publique. La vulnerabilidad, CVE202698432, tiene una puntuación CVSS 3.1 de 9,8, es decir, crítica, según kernel.org. El fallo afecta la gestión que hace el kernel de las conexiones TCP IPv4 entrantes y puede hacer que acceda a memoria ya liberada. El boletín de seguridad de Red Hat señala que un atacante remoto sin credenciales podría aprovechar la condición de carrera para ejecutar código; su descripción de la vulnerabilidad también identifica caídas del sistema y corrupción de memoria como riesgos. En Cardano, la advertencia abarca tanto las máquinas que producen bloques como los relays que las conectan a la red global. La documentación para operadores de Cardano recomienda que los productores de bloques se conecten solo a relays propios o de confianza para aislarlos de internet. El aviso de Intersect no reporta explotación contra Cardano ni cuantifica cuántos pools ejecutan kernels vulnerables. Parches y medidas provisionales El rastreador de Ubuntu, actualizado por última vez el 30 de octubre, marca sus kernels estándar para Ubuntu 22.04, 24.04, 26.04 y 26.10 como vulnerables, con correcciones en curso. El boletín de Red Hat del 30 de octubre enumera RHEL 8, 9 y 10 como afectados y afirma que está acelerando las correcciones. AlmaLinux informó el 30 de octubre de que los kernels corregidos para sus versiones 8, 9 y 10 estaban disponibles en repositorios de pruebas, antes de su publicación en producción. Señaló que en ese momento no había un kernel de RHEL corregido disponible. El fallo se remonta a Linux 4.4, y las correcciones upstream se han retroportado a las ramas estables mantenidas. El ataque demostrado utilizó Multipath TCP, o MPTCP. Investigadores de Anthropic indicaron que su prueba de concepto podía enviar paquetes a un servidor Linux con un listener MPTCP y ejecutar comandos como root, sin credenciales ni interacción del usuario. El Go Security Team advirtió que el fallo subyacente no es específico de MPTCP, por lo que los sistemas sin esos listeners también podrían ser vulnerables. AlmaLinux aconseja desactivar MPTCP donde no sea necesario y reiniciar los servicios con listeners MPTCP existentes: el cambio de configuración por sí solo únicamente impide la creación de nuevos sockets MPTCP. Red Hat también ofrece una mitigación de firewall que filtra paquetes TCP IPv4 entrantes que contengan opciones IP. Aconseja a los operadores probar la regla con sus cargas de trabajo antes de desplegarla y señala que el filtrado puede reducir la exposición, pero no evitar por completo la explotación. Ambos proveedores subrayan que las medidas provisionales no sustituyen la instalación de un kernel corregido; Intersect indica explícitamente a los operadores que reinicien después de actualizar.