Panique et lenteur de SACK : Les correctifs KernelCare Live sont arrivés

24 juin 2019 - L'équipe d'experts de TuxCare

Kernel Care-03 (2)

Récemment, le mauvais genre de Netflix Original a été révélé au public. Le géant du streaming a annoncé qu'il avait découvert quatre nouvelles vulnérabilités de déni de service (DoS) et de consommation de ressources affectant les serveurs Linux et FreeBSD. Netflix a fourni tous les détails dans un avis publié sur GitHub. Ces vulnérabilités menacent toute entreprise exploitant de grandes flottes d'ordinateurs Linux de production.

Le meilleur scénario : Ralentissement

Toutes les vulnérabilités menaçant Linux exploitent la fonction TCP Selective Acknowledgement du noyau (d'où "TCP SACK"). Deux de ces vulnérabilités - CVE-2019-11478 et CVE-2019-11479 - font que la file d'attente de retransmission TCP devient si fragmentée que le noyau dépense des ressources excessives pour gérer les éléments SACK de cette connexion TCP. Bien que cela ne soit pas désastreux, cela peut provoquer un ralentissement significatif du processeur. CVE-2019-11478 affecte tous les noyaux avant 4.15 ; CVE-2019-11479 affecte toutes les versions de Linux depuis 2.6.29.

Le pire des scénarios : Catastrophe

La troisième vulnérabilité - CVE-2019-11477 - a été baptisée à juste titre "SACK Panic". Affectant tous les noyaux 2.6.29 et plus récents, SACK Panic est une vulnérabilité de type débordement d'entier qui exploite la fonctionnalité TCP Selective ACKnowledgement du noyau en ajustant les valeurs du MSS (Maximum Segment Size). Une séquence particulière de paquets peut induire une panique du noyau.

Comme les vulnérabilités de lenteur, SACK Panic est particulièrement inquiétante car elle peut être déclenchée à distance. Les acteurs malveillants peuvent déclencher une panique totale, qui peut complètement bloquer un système d'exploitation, forcer le redémarrage d'un hôte ciblé et provoquer un arrêt temporaire des services. Cela signifie des serveurs en panne, des communications interrompues et un risque de pertes de données importantes. C'est une très mauvaise nouvelle pour les services qui utilisent des systèmes basés sur Linux pour fournir des services en ligne.

Comme si ce n'était pas assez mauvais : SACK Panic affecte tous les noyaux 2.6.29 et plus récents.

Obtenez un essai GRATUIT de 7 jours avec assistance de KernelCare

Protégez vos noyaux et vos appareils IoT - sans redémarrage.

Les correctifs en direct de KernelCare pour SACK Panic & Slowness, y compris le très important PATCH_net_1_4.patchPATCH_net_1a .patch, sont ici pour toutes les distributions supportées, à l'exception de UEK (qui est en cours actuellement). Et avec une vulnérabilité aussi sérieuse que SACK Panic, vous voulez être corrigé le plus rapidement possible. Oui, il existe des solutions de contournement des fichiers de configuration, mais elles sont loin d'être sans danger.

Cependant, si vous devez redémarrer pour appliquer un correctif, cela pose un sérieux problème. Le redémarrage des serveurs est un inconvénient majeur ; vous ne pouvez pas le faire sans planifier à l'avance, et il est très tentant de le retarder le plus longtemps possible. (Cela est particulièrement vrai pour les appareils IoT, qui peuvent être difficiles et longs à corriger). Cela signifie qu'à chaque fois qu'une vulnérabilité se présente, vous êtes confronté à un perdant-perdant : le tracas de redémarrer votre parc de serveurs, ou le risque de retarder ce redémarrage jusqu'à minuit le samedi, lorsque le temps d'arrêt sera le moins problématique.

En outre, retarder vos redémarrages ne vous rend pas seulement dangereux : cela vous rend non conforme. Les polices d'assurance contre les erreurs et omissions (E&O) de la plupart des entreprises, ainsi que les clauses de leurs contrats SLA, exigent le respect des meilleures pratiques en matière de correctifs. En général, cela signifie que l'intervalle entre l'émission d'un correctif et son application ne doit pas dépasser 30 jours. Mais beaucoup d'entreprises ont encore tendance à planifier leurs cycles de redémarrage en termes de mois ou de trimestres, ce qui les place en perpétuelle violation de leurs polices d'assurance. Plus tôt vous appliquez les correctifs, plus tôt vous êtes protégé - et plus vous devenez conforme.

Au cours du week-end, les utilisateurs de KernelCare ont reçu des correctifs qui ont été appliqués automatiquement, sans qu'aucun redémarrage ne soit nécessaire. La prochaine fois qu'un CVE dangereux apparaîtra, vous n'aurez pas à redémarrer vos serveurs. Il n'est pas nécessaire d'être non conforme aux normes de sécurité du secteur. Avec KernelCare, vous serez entièrement protégé sans avoir à lever le petit doigt.

Obtenez un essai GRATUIT de 7 jours avec assistance de KernelCare

Lire la suite :