Le ciel ne nous tombe pas sur la tête : les bogues OpenSSL divulgués sont sérieux mais pas critiques

Les experts en sécurité ont décrit deux vulnérabilités très attendues que l'équipe du projet OpenSSL a corrigées mardi comme des problèmes qui doivent être résolus rapidement, mais qui ne méritent pas nécessairement une réponse d'urgence de type abandon de tout le reste.

La version 3.0.7 de la bibliothèque cryptographique presque omniprésente corrige deux vulnérabilités de dépassement de tampon, qui existent dans les versions 3.0.0 à 3.0.6 d'OpenSSL.

Avant la divulgation, les experts en sécurité avaient averti que l'un des problèmes, initialement qualifié de « critique » problème d'exécution de code à distance, pourrait présenter un problème de niveau Heartbleed, impliquant tout le monde. Heureusement, cela ne semble pas être le cas – et en révélant la faille, l'équipe du projet OpenSSL a déclaré qu'elle avait décidé de déclasser la menace à « élevée » basé sur les commentaires des organisations qui avaient testé et analysé le bug.

Une paire de débordements de tampon

Le premier bug (CVE-2022-3602) pourrait en effet – dans un ensemble de circonstances spécifiques – permettre le RCE, ce qui a initialement conduit certains experts en sécurité à craindre que la faille puisse avoir des répercussions à l'échelle de l'industrie. Mais il s’avère qu’il existe des circonstances atténuantes : d’une part, c’est difficile à exploiter, comme expliqué ci-dessous. De plus, tous les systèmes ne sont pas concernés.

Plus précisément, seuls les navigateurs prenant en charge OpenSSL 3.0.0 à 3.0.6, tels que Firefox et Internet Explorer, sont concernés pour le moment, selon Mark Ellzey, chercheur principal en sécurité chez Censys ; Google Chrome, qui est le principal navigateur Internet, n'est notamment pas affecté.

« L’impact devrait être minime en raison de la complexité de l’attaque et des limites de la manière dont elle peut être menée », dit-il. « Les organisations devraient perfectionner leur formation en matière de phishing et garder un œil sur les sources de renseignements sur les menaces pour s'assurer qu'elles sont prêtes si elles sont la cible d'une attaque comme celle-ci. »

Pour démarrer, Alex Ilgayev, chercheur principal en sécurité chez Cycode, a noté que la faille ne peut pas être exploitée sur certaines distributions Linux ; et de nombreuses plates-formes de système d'exploitation modernes mettent en œuvre des protections contre le débordement de pile pour atténuer de telles menaces dans tous les cas, explique Ilgayev.

La deuxième vulnérabilité (CVE-2022-3786), qui a été découvert lors du développement d'un correctif pour la faille d'origine, pourrait être utilisé pour déclencher des conditions de déni de service (DoS). L'équipe OpenSSL a évalué la vulnérabilité comme étant de haute gravité mais a exclu la possibilité qu'elle soit utilisée pour l'exploitation de RCE.

Les deux vulnérabilités sont liées à une fonctionnalité appelée Punycode pour encoder les noms de domaine internationalisés.

« Les utilisateurs d'OpenSSL 3.0.0 – 3.0.6 sont encouragé à passer à la version 3.0.7 dès que possible", a déclaré l'équipe OpenSSL dans un blog accompagnant la divulgation du bug et la publication de la nouvelle version de la bibliothèque cryptographique. "Si vous obtenez votre copie d'OpenSSL auprès de votre fournisseur de système d'exploitation ou d'un autre tiers, vous devez chercher à obtenir une version mise à jour de leur part dès que possible."

Pas un autre saignement de cœur

La divulgation du bug va certainement atténuer – pour le moment, du moins – l'inquiétude généralisée a suscité par la notification de l’équipe OpenSSL la semaine dernière de sa divulgation de bug alors imminente. La description de la première faille comme étant « critique », en particulier, avait donné lieu à plusieurs comparaisons avec le bug « Heartbleed » de 2014 – le seul autre bug d’OpenSSL à obtenir une note critique. Ce bug (CVE-2014-0160) a touché une large partie d'Internet et, même aujourd'hui, n'a pas été entièrement résolu dans de nombreuses organisations.

"Heartbleed était exposé par défaut sur tout logiciel utilisant une version vulnérable d'OpenSSL, et il était très facilement exploitable par des attaquants pour voir les clés cryptographiques et les mots de passe stockés dans la mémoire du serveur", explique Jonathan Knudsen, responsable de la recherche mondiale au Synopsys Cybersecurity Research Center. . "Les deux vulnérabilités qui viennent d'être signalées dans OpenSSL sont graves mais pas de la même ampleur."

Les bogues OpenSSL sont difficiles à exploiter…

Pour exploiter l'une ou l'autre de ces nouvelles failles, les serveurs vulnérables devraient demander une authentification par certificat client, ce qui n'est pas la norme, explique Knudsen. Et les clients vulnérables devraient se connecter à un serveur malveillant, ce qui constitue un vecteur d'attaque courant et défendable, explique-t-il.

« Personne ne devrait être en feu à propos de ces deux vulnérabilités, mais elles sont graves et doivent être traitées avec la rapidité et la diligence appropriées », note-t-il.

Dans un article de blog, le SANS Internet Storm Center a quant à lui décrit la mise à jour d'OpenSSL comme correction d'un dépassement de tampon lors du processus de vérification du certificat. Pour qu'un exploit fonctionne, le certificat devrait contenir un nom malveillant codé en Punycode, et la vulnérabilité ne serait déclenchée qu'après vérification de la chaîne de certificat.

"Un attaquant doit d'abord pouvoir faire signer un certificat malveillant par une autorité de certification en laquelle le client a confiance", a noté SANS ISC. « Cela ne semble pas exploitable contre les serveurs. Pour les serveurs, cela peut être exploitable si le serveur demande un certificat au client.

Conclusion : la probabilité d'exploitation est faible car la vulnérabilité est complexe à exploiter, tout comme le flux et les exigences pour la déclencher, explique Ilgayev de Cycode. De plus, cela affecte un nombre relativement restreint de systèmes, par rapport à ceux utilisant des versions antérieures à 3.0 d'OpenSSL.

…Mais soyez diligent

Dans le même temps, il est important de garder à l'esprit que des vulnérabilités difficiles à exploiter ont été exploitées dans le passé, explique Ilgayev, soulignant que un exploit sans clic que le groupe NSO a développé pour une vulnérabilité dans iOS l'année dernière.

« [Aussi], comme le dit l'équipe OpenSSL, il n'y a « aucun moyen de savoir comment chaque combinaison de plate-forme et de compilateur a disposé les tampons sur la pile », et donc l'exécution de code à distance peut toujours être possible sur certaines plates-formes », prévient-il.

Et en effet, Ellzey décrit un scénario sur la façon dont les attaquants pourraient exploiter CVE-2022-3602, la faille que l'équipe OpenSSL avait initialement évaluée comme critique.

« Un attaquant hébergerait un serveur malveillant et tenterait d'amener ses victimes à s'authentifier auprès d'une application vulnérable à OpenSSL v3.x, potentiellement par le biais de tactiques de phishing traditionnelles », dit-il, bien que la portée soit limitée en raison du fait que l'exploit est principalement client. côté.

Des vulnérabilités comme celle-ci soulignent l'importance d'avoir un nomenclature du logiciel (SBOM) pour chaque binaire utilisé, note Ilgayev. "Il ne suffit pas d'examiner les gestionnaires de packages, car cette bibliothèque pourrait être liée et compilée dans diverses configurations qui affecteront l'exploitabilité", dit-il.