Les correctifs KernelCare+ pour CVE-2020-1971 sont arrivés

Grandes nouvelles de l'équipe OpenSSL - ils ont publié le correctif pour une nouvelle CVE-2020-1971 qui provoque des perturbations sur les serveurs via les champs de certificats x509v3. La bonne nouvelle est qu'il ne peut pas entraîner de vol de données ; en revanche, il a la capacité d'arrêter vos serveurs et de paralyser les flux de fonctionnement de l'entreprise. Les versions OpenSSL 1.1.1 et 1.0.2 sont concernées par ce problème. Les autres versions d'OpenSSL sont sans soutienn'ont pas été vérifiés et, selon toute probabilité, ne seront pas traités par le vendeur.

En ce moment, l'équipe KernelCare effectue un travail délicat de portage des correctifs 1.1.1 du fournisseur vers la version 1.1.0 et les enrichit avec la technologie des correctifs en direct. Les correctifs sans redémarrage pour les versions supportées et non supportées d'OpenSSL seront livrés dans 24 heures pour CentOS6 et 7, les correctifs pour les autres distributions supportées étant publiés plus tard dans la semaine.

MISE À JOUR du 9 décembre :

Les correctifs pour CentOS 6 et CentOS 7 ont été publiés. Les clients de KernelCare commenceront à recevoir les mises à jour dans les 4 prochaines heures.

Pour limiter les risques supplémentaires, nous publierons demain une nouvelle version de l'agent KernelCare.

Contenu :

1. Que s'est-il passé ?
2. Comment atténuer les effets de CVE-2020-1971 sans redémarrage du système ?
3. A propos de CVE-2020-1971

Que s'est-il passé ?

Le pire est arrivé pour les utilisateurs de CentOS6 et d'autres distributions EOL qui utilisent des versions d'OpenSSL antérieures à 1.1.1 et 1.0.2 : d'après les sources ouvertes, les versions antérieures d'OpenSSL ne sont plus prises en charge et on peut supposer que le fournisseur ne publiera pas les correctifs pour CVE-2020-1971 pour les anciennes versions de la bibliothèque, laissant ainsi les serveurs d'entreprise susceptibles d'être arrêtés par des acteurs malveillants. À l'heure actuelle, KernelCare+ est l'un des rares services à disposer des correctifs pour CVE-2020-1971 dont la publication est prévue dans les 24 heures et à pouvoir mettre à jour l'ancien et le nouveau OpenSSL sans redémarrage du service ou du serveur.

Ceux qui s'en tiennent aux systèmes d'exploitation ou aux bibliothèques partagées en fin de vie ont plusieurs raisons constructives de le faire. Regardons les choses en face : la migration vers une nouvelle bibliothèque partagée ou un nouveau système d'exploitation est une affaire fastidieuse et coûteuse. Et même si les administrateurs système sont d'accord pour mettre à jour des milliers de parcs de serveurs, la direction de l'entreprise évalue correctement le montant des ressources financières et en temps nécessaires, et reste donc hésitante.

Alors, quel choix avez-vous maintenant ? La plus évidente : si vous utilisez la version 1.1.x d'OpenSSL, retroussez vos manches et corrigez CVE-2020-1971 manuellement. Si vous utilisez la version 1.0, passez à la version la plus récente d'OpenSSL pour obtenir le correctif. Quel que soit votre choix, les deux requièrent un redémarrage des services ou de l'ensemble du système pour que la mise à jour de la bibliothèque partagée prenne effet. Quel que soit votre choix, les conséquences sont les mêmes : temps d'arrêt et charge de travail supplémentaire.

Comment atténuer les effets de CVE-2020-1971 sans redémarrage du système ?

Il existe également une troisième option de mise à jour d'OpenSSL sans migration vers la version la plus récente ni correctif manuel. Celle qui n'ajoute pas une charge extrême à votre charge de travail causée par les mises à jour d'urgence. Laissez KernelCare+ patcher OpenSSL pour vous automatiquement.

L'équipe de KernelCare+ est actuellement en train de porter les correctifs 1.1.1 du fournisseur vers la version 1.1.0 et de les enrichir avec la technologie du live patching. KernelCare+ est un correctif en direct pour les bibliothèques partagées qui applique les mises à jour de sécurité sans affecter l'état opérationnel de vos applications - pas de redémarrage, pas de reboots. Outre l'application de correctifs en direct pour Glibc et OpenSSL, KernelCare+ protège également les noyaux Linux.

Les correctifs de KernelCare seront publiés le 9 décembre 2020. D'abord - pour les distributions les plus affectées - CentOS 6 et CentOS 7. Les correctifs pour le reste des distributions seront disponibles dans les prochains jours.

Obtenez un essai GRATUIT de 7 jours avec assistance de KernelCare 

Votre quatrième option est d'acheter un support de cycle de vie étendu auprès d'un CloudLinux, ou d'opter pour un duo puissant : l'offre de CloudLinux intitulée CentOS 6 ELS et KernelCare+ Bundle de CloudLinux. Le processus d'installation est simple : exécutez une commande pour ajouter un nouveau fichier de dépôt. Ensuite, CloudLinux vous fournira des mises à jour pour OpenSSL, Glibc, cPanel, Apache, PHP, MySQL, OpenSSH, Zlib, etc. Le travail de KernelCare+ sera de vous donner ces mises à jour sans redémarrage et sans perturbation de vos processus et opérations.

A propos de CVE-2020-1971

OpenSSL a récemment (8 décembre 2020) publié un correctif pour une vulnérabilité à haut risque de déréférencement de pointeur nul trouvée dans la fonction GENERAL_NAME_cmp() de la bibliothèque de chiffrement. Si cette vulnérabilité n'est pas corrigée, un attaquant peut envoyer des paramètres malveillants à la fonction GENERAL_NAME_cmp() et faire planter le système en provoquant un déni de service (DoS). La vulnérabilité a été attribuée à CVE-2020-1971.

L'objectif de la fonction GENERAL_NAME_cmp() est double :

1. Il compare les noms des points de distribution des listes de révocation de certificats (CRL) entre la CRL disponible téléchargée à l'aide de l'option "-crl_download" et le point de distribution de la CRL inclus dans le certificat X.509.
2. Il vérifie que le signataire du jeton de réponse d'horodatage correspond au nom de l'autorité d'horodatage.

Si un attaquant peut contrôler les deux paramètres comparés, il peut faire tomber le système en utilisant des LCR malicieusement conçues ou des certificats X.509 malveillants.

OpenSSL utilise un type générique appelé GeneralName pour effectuer les comparaisons. L'un des types est appelé EDIPartyName. Si les deux paramètres contiennent le type EDIPartyName, le code OpenSSL le traite comme "autre" et une erreur de segmentation en résulte.

Tous les serveurs utilisant les versions 1.1.1-1.1.1h et 1.0.2-1.0.2w d'OpenSSL doivent être mis à jour vers la dernière version 1.1.1i ou 1.0.2x. Les développeurs qui utilisent OpenSSL comme dépendance doivent également mettre à jour la bibliothèque de chiffrement, en particulier s'ils implémentent les outils s_server, s_client et verify pour les certificats. Ces outils utilisent GENERAL_NAME_cmp() dans leur fonctionnalité, et le chercheur en sécurité de Google, David Benjamin, qui a découvert la vulnérabilité a prouvé et démontré qu'OpenSSL se bloquera si une entrée malformée leur est envoyée.