Support technique
Documentation
Connexion
Nous contacter
Nouvelles vulnérabilités OpenSSL corrigées par KernelCare Enterprise
Joao Correia
22 février 2023 - Évangéliste technique
Les correctifs pour les vulnérabilités OpenSSL récemment découvertes sont déjà disponibles via KernelCare Enterprise de TuxCare. Pour certaines distributions, nous avons publié les correctifs avant que les mises à jour fournies par les fournisseurs ne soient disponibles. Lisez la suite pour en savoir plus sur chaque vulnérabilité.
Avec KernelCare Enterprise, vous obtenez des correctifs de sécurité en direct pour le noyau Linux et, grâce à son composant LibCare, vous obtenez également des correctifs en direct pour les bibliothèques système critiques, comme glibc et OpenSSL.
Il s'agit de cibles attrayantes pour les acteurs de la menace, mais aussi de composants très perturbants à corriger si vous n'utilisez pas une approche de correction en direct, car les mises à jour de sécurité traditionnelles nécessitent un redémarrage supplémentaire du système ou, à tout le moins, des services, pour être effectuées.
Lorsque vous vous appuyez sur OpenSSL pour garantir la sécurité de vos communications cryptées, de vos certificats et de tout autre travail cryptographique, l'apparition de nouvelles vulnérabilités est toujours préoccupante. Pour garder vos systèmes protégés, comme nous l'avons de nombreuses autres fois dans le passél'équipe de KernelCare travaille sans relâche pour vous fournir les dernières mises à jour dans de telles situations.
L'avis
Le 7 février, l'équipe OpenSSL a divulgué publiquement des informations sur quatre nouvelles vulnérabilités affectant la branche OpenSSL 1.x (CVE-2023-0286, CVE-2023-0215, CVE-2022-4304, et CVE-2023-4450). Ils présentent un risque modéré à élevé. Cette branche d'OpenSSL est la plus largement déployée dans les distributions Linux d'entreprise.
Des correctifs vivants pour corriger ces vulnérabilités sont déjà disponibles pour les utilisateurs de KernelCare Enterprise utilisant CentOS7/Oracle EL7/Cloud Linux 7/RHEL7, CentOS8/Oracle EL8/Cloud Linux 8/RHEL 8/RockyLinux 8/AlmaLinux 8, Amazon2, Debian10, Ubuntu-Bionic et Ubuntu-Focal. Les correctifs pour les autres systèmes pris en charge seront publiés sous peu, et cet article sera mis à jour à ce moment-là.
Il est important de noter que les correctifs sont publiés avant certaines mises à jour régulières de la distribution Linux, de sorte que vos systèmes sont sécurisés non seulement sans interruption, mais aussi plus rapidement qu'avec les mises à jour traditionnelles fournies par les fournisseurs. Les fournisseurs de distributions Linux prennent parfois plus de temps que souhaité pour diffuser les paquets mis à jour à leurs utilisateurs.
D'autres distributions, comme RHEL 7 (et ses dérivés), sont affectées, mais ne recevront pas du tout de correctifs du fournisseur, car elles tombent dans le champ d'application "hors support" du fournisseur. "hors du champ d'application du support".
Vous recevrez toujours ces mises à jour via LibCare de TuxCare, car notre équipe de développement a transféré le code corrigé directement depuis le code OpenSSL en amont.
Un regard plus attentif sur les vulnérabilités
Comme mentionné ci-dessus, OpenSSL permet d'accomplir de nombreuses tâches liées à la cryptographie, notamment la signature, l'analyse et la validation de certificats. Il a été découvert qu'en fabriquant un certificat avec un type de valeur spécifique (une adresse de type adresse X.400) à l'intérieur d'un certificat X.509 GeneralName, un attaquant pouvait forcer une application à lire des contenus mémoire spécifiques. Cela peut conduire à la divulgation d'informations ou à un déni de service (en plantant l'application).
Bien que les résultats d'une exploitation réussie soient dangereux, rien n'indique une utilisation active "dans la nature", et la mise en place de l'attaque implique une série d'étapes alambiquées et une utilisation particulière du côté de l'application.
OpenSSL fournit une fonctionnalité de type flux aux applications, au niveau du code, avec une abstraction appelée "BIO." Son concept est similaire à celui d'un "FILE *" en C, et permet à un développeur de s'appuyer sur la fonctionnalité de cryptage de manière transparente, les fonctions cryptographiques sous-jacentes, parfois difficiles à comprendre, étant cachées dans OpenSSL.
"BIO_new_NDEF"est une fonction d'aide utilisée pour transmettre des données ASN.1 en continu. La façon dont les différentes fonctions "BIO" peuvent être enchaînées pour fournir une fonctionnalité de haut niveau (par exemple, réception->décryptage->copie->encryptage) pourrait être abusée en déclenchant un résultat NULL de "BIO_new_NDEF" et en rompant la chaîne de façon inattendue. Dans ce scénario, il y aurait un use-after-free et l'application pourrait se planter (ou pire, être laissée dans un état indéfini).
De nombreuses fonctions publiques d'OpenSSL font appel en interne à la fonction affectée et, de ce fait, la surface d'attaque est bien plus grande qu'une seule fonction défectueuse.
Les attaques par canal latéral s'appuient sur un comportement observable qui n'est pas nécessairement lié au code attaqué, mais plutôt sur des caractéristiques, telles qu'une opération donnée prenant plus ou moins de temps pour s'exécuter, utilisant plus ou moins de mémoire, ou des paramètres particuliers d'un environnement donné, pour en déduire des informations cachées.
Il a été constaté qu'il était possible de récupérer des informations en clair à distance en envoyant un grand nombre de messages à décrypter et en mesurant le temps de traitement de ces messages. Il serait possible de déduire les valeurs premières utilisées dans une poignée de main de connexion TLS qui utilise le chiffrement RSA (la divulgation d'OpenSSL compare cela à une "attaque Bleichenbacher").
Il convient de noter que les informations initiales concernant une possibilité de canal latéral de synchronisation ont été présentées dès juillet 2020, et ce n'est que maintenant que le problème a été circonscrit et réglé.
Le traitement de tout type d'entrée contrôlée par l'utilisateur est toujours risqué pour une application, car les acteurs malveillants peuvent concevoir des entrées élaborées qui abusent d'un code spécifique et conduisent à des résultats inattendus. Toujours dans la partie traitement des certificats d'OpenSSL, un certificat codé PEM spécialement conçu avec 0 octet de données utiles pourrait déclencher un bogue "use-after-free" et entraîner un plantage de l'application (et un déni de service).
Ce type de vérification est très courant dans les applications et les services, ainsi que directement dans les utilitaires de ligne de commande fournis par OpenSSL.
Sécuriser les systèmes plus rapidement et de manière plus fiable
KernelCare Enterprise, par l'intermédiaire de LibCare, fournit les mises à jour nécessaires pour maintenir la sécurité du système dans des situations critiques, où tout délai, tel que l'attente d'une fenêtre de maintenance, est tout simplement trop long pour être toléré. Bien que nous préférions traditionnellement utiliser les correctifs de distributions spécifiques, lorsque ces distributions sont lentes à réagir, nous fournirons néanmoins le correctif à nos clients.
Avec KernelCare Enterprise, vous pouvez être sûr que nous suivons les dernières menaces et que nous vous fournissons les défenses adéquates pour renforcer votre sécurité et votre conformité, tout en maintenant la disponibilité de votre entreprise sans aucune interruption.
