SACK Pánico y Lentitud: Ya están aquí los parches KernelCare Live
Recientemente, el tipo equivocado de Netflix Original se reveló al público. El gigante del streaming anunció que había descubierto cuatro nuevas vulnerabilidades de denegación de servicio (DoS) y consumo de recursos que afectaban a servidores Linux y FreeBSD. Netflix ofreció todos los detalles en un aviso publicado en GitHub. Las vulnerabilidades amenazan a cualquier empresa que ejecute grandes flotas de ordenadores Linux de producción.
En el mejor de los casos: Ralentización
Todas las vulnerabilidades que amenazan a Linux aprovechan la función TCP Selective Acknowledgement del kernel (de ahí "TCP SACK"). Dos de las vulnerabilidades - CVE-2019-11478, y CVE-2019-11479 - hacen que la cola de retransmisión TCP se fragmente tanto que el kernel gasta excesivos recursos gestionando los elementos SACK de esa conexión TCP. Aunque esto no es desastroso, podría causar una ralentización significativa de la CPU. CVE-2019-11478 afecta a todos los kernels anteriores a 4.15; CVE-2019-11479 afecta a todas las versiones de Linux desde 2.6.29.
El peor escenario posible: Catástrofe
La tercera vulnerabilidad - CVE-2019-11477 - ha sido acertadamente apodada "SACK Panic". Afectando a todos los kernels 2.6.29 y posteriores, SACK Panic es una vulnerabilidad de desbordamiento de enteros que explota la función TCP Selective ACKnowledgement del kernel ajustando los valores del MSS (Maximum Segment Size). Una secuencia particular de paquetes puede inducir un kernel panic.
Al igual que las vulnerabilidades de lentitud, SACK Panic es especialmente preocupante porque puede desencadenarse de forma remota. Los actores maliciosos pueden desencadenar un pánico total, que puede bloquear completamente un sistema operativo, forzando el reinicio de un host y causando un cierre temporal de los servicios. Esto significa la caída de servidores, la interrupción de las comunicaciones y el riesgo de graves pérdidas de datos. Son muy malas noticias para los servicios que utilizan sistemas basados en Linux para prestar servicios en línea.
Por si fuera poco: SACK Panic afecta a todos los núcleos 2.6.29 y posteriores.
Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare
Proteja sus núcleos y sus dispositivos IoT, sin reiniciar
Los parches en vivo SACK Panic & Slowness de KernelCare, incluyendo el importantísimo PATCH_net_1_4.patchPATCH_net_1a.patch, están aquí para todas las distribuciones soportadas excepto UEK (que está en progreso ahora mismo). Y con una vulnerabilidad tan grave como SACK Panic, querrá parchearla lo antes posible. Sí, hay algunas soluciones para los archivos de configuración, pero están lejos de ser seguras.
Sin embargo, si vas a reiniciar para aplicar parches, esto supone un serio quebradero de cabeza. Reiniciar los servidores es un gran inconveniente; no puedes hacerlo sin planificarlo de antemano, y es muy tentador retrasarlo todo lo posible. (Esto es especialmente cierto en el caso de los dispositivos IoT, que pueden ser difíciles y llevar mucho tiempo parchear). Esto significa que cada vez que aparece una vulnerabilidad, te enfrentas a una disyuntiva: la molestia de reiniciar tu flota de servidores, o el riesgo de retrasar ese reinicio hasta la medianoche del sábado, cuando el tiempo de inactividad será el menos problemático.
Además, retrasar sus reinicios no sólo le hace inseguro: le hace incumplidor. Las pólizas de seguro de errores y omisiones (E&O) de la mayoría de las empresas, así como las cláusulas de sus contratos SLA, exigen el cumplimiento de las mejores prácticas de aplicación de parches. Normalmente, esto equivale a un intervalo entre la emisión del parche y su aplicación no superior a 30 días. Pero muchas empresas todavía tienden a planificar sus ciclos de reinicio en términos de meses o trimestres, lo que las sitúa en una violación perpetua de sus pólizas de seguros. Cuanto antes se parchee, antes se estará protegido y más se cumplirá la normativa.
Este fin de semana, los usuarios de KernelCare han recibido parches que se han aplicado automáticamente, sin necesidad de reiniciar el sistema. La próxima vez que aparezca una CVE peligrosa, no hay necesidad de enfrentarse a la molestia de reiniciar sus servidores. No hay necesidad de incumplir las normas de seguridad del sector. Live-patch con KernelCare, y usted estará totalmente protegido sin tener que mover un dedo.
Obtenga una prueba GRATUITA de 7 días con soporte de KernelCare
Más información:
- Zombieload 2: ¡El equipo KernelCare está en ello!
- Zombieload 2: ¡Los parches para CVE-2018-12207 están en la sección de pruebas!
- SWAPGS: Parches KernelCare en camino
- RIDL - Otro ataque MDS del que Live Patching le habría salvado
- QEMU-KVM vhost/vhost_net Guest to Host Kernel Escape Vulnerability (Vulnerabilidad de fuga de kernel de huésped a host en QEMU-KVM)
- Nueva vulnerabilidad en el núcleo de Linux, parcheada por KernelCare
- Existen parches de fallo del terminal L1 (L1TF)
- Informe sobre la vulnerabilidad de Intel DDIO 'NetCat
- Fallout - el ataque de canal lateral de MDS que no es Zombieload
