Les correctifs OpenSSL sont sortis - Le bogue CRITIQUE a été rétrogradé à ÉLEVÉ, mais corrigez quand même !

Nous allons commencer par l'essentiel : les corrections de bugs OpenSSL très attendues annoncées la semaine dernière sont sortis.

OpenSSL 1.1.1 va à version 1.1.1s, et corrige un bogue lié à la sécurité répertorié, mais ce bogue n'a pas d'évaluation de sécurité ni de numéro CVE officiel.

Nous vous recommandons vivement de mettre à jour, mais la mise à jour CRITIQUE que vous aurez pu voir dans les médias cybersécurité ne s'applique pas à cette version.

OpenSSL 3.0 va à Version 3.0.7, et corrige non pas un mais deux bogues de sécurité numérotés CVE qui sont officiellement désignés comme ayant une gravité ÉLEVÉE.

Nous vous recommandons fortement de mettre à jour, avec autant d'urgence que possible, mais le correctif CRITIQUE dont tout le monde parle a maintenant été rétrogradé à une gravité ÉLEVÉE.

Cela reflète l'opinion de l'équipe OpenSSL :

Annonces préalables de CVE-2022-3602 décrit ce problème comme CRITIQUE. Une analyse plus approfondie basée sur certains des facteurs atténuants décrits [dans les notes de version] a conduit à le rétrograder à ÉLEVÉ. Les utilisateurs sont toujours encouragés à passer à une nouvelle version dès que possible.

Ironiquement, un deuxième bogue similaire, surnommé CVE-2022-3786, a été découvert lors de la préparation du correctif pour CVE-2022-3602.

Le bogue d'origine ne permet à un attaquant de corrompre que quatre octets sur la pile, ce qui limite l'exploitabilité du trou, tandis que le deuxième bogue permet un débordement de pile illimité, mais apparemment uniquement du caractère "point" (ASCII 46, ou 0x2E ) répétée maintes et maintes fois.

Les deux vulnérabilités sont exposées lors de la vérification du certificat TLS, où un client ou un serveur piégé "s'identifie" au serveur ou au client à l'autre bout avec un certificat TLS délibérément mal formé.

Bien que ces types de débordement de pile (l'un de taille limitée et l'autre de valeurs de données limitées) semblent difficiles à exploiter pour l'exécution de code (en particulier dans les logiciels 64 bits, où quatre octets ne représentent que la moitié d'une adresse mémoire) …

… ils sont presque certains d'être facilement exploitables pour les attaques DoS (déni de service), où l'expéditeur d'un certificat escroc pourrait planter le destinataire de ce certificat à volonté.

Heureusement, la plupart des échanges TLS impliquent que les clients vérifient les certificats du serveur, et non l'inverse.

La plupart des serveurs Web, par exemple, n'exigent pas que les visiteurs s'identifient avec un certificat avant de les autoriser à lire le site, de sorte que la "direction de plantage" de tout exploit fonctionnel est susceptible d'être des serveurs malveillants qui plantent des visiteurs malheureux, ce qui est généralement considéré beaucoup moins grave que les serveurs qui plantent à chaque fois qu'ils sont consultés par un seul visiteur malveillant.

Néanmoins, toute technique par laquelle un serveur Web ou de messagerie piraté peut planter gratuitement un navigateur ou une application de messagerie en visite doit être considérée comme dangereuse, notamment parce que toute tentative du logiciel client de réessayer la connexion entraînera le plantage de l'application encore et encore. encore.

Vous souhaitez donc absolument correctif contre cela dès que vous le pouvez.

Que faire?

Comme mentionné ci-dessus, vous avez besoin OpenSSL 1.1.1s or OpenSSL 3.0.7 pour remplacer la version que vous avez actuellement.

OpenSSL 1.1.1s obtient un correctif de sécurité décrit comme fixant "une régression [an old bug that reappeared] introduite dans OpenSSL 1.1.1r ne rafraîchit pas les données du certificat à signer avant de signer le certificat", ce bogue n'a pas de gravité ou de CVE qui lui est attribué…

… mais ne vous laissez pas décourager par la mise à jour dès que possible.

OpenSSL 3.0.7 obtient les deux correctifs de haute gravité numérotés CVE répertoriés ci-dessus, et même s'ils ne semblent pas aussi effrayants maintenant qu'ils l'ont fait dans le news-fest qui a précédé cette version, vous devez supposer que :

• De nombreux attaquants comprendront rapidement comment exploiter ces failles à des fins de DoS. Cela pourrait au mieux perturber le flux de travail et au pire des problèmes de cybersécurité, en particulier si le bogue peut être utilisé à mauvais escient pour ralentir ou interrompre des processus automatisés importants (tels que les mises à jour) dans votre écosystème informatique.
• Certains attaquants peuvent être en mesure de résoudre ces bogues pour l'exécution de code à distance. Cela donnerait aux criminels une bonne chance d'utiliser des serveurs Web piégés pour détourner les logiciels clients utilisés pour les téléchargements sécurisés dans votre propre entreprise.
• Si une preuve de concept (PoC) est trouvée, elle suscitera un énorme intérêt. Comme vous vous en souviendrez de Log4Shell, dès que les PoC ont été publiés, des milliers de «chercheurs» autoproclamés ont sauté dans le train en marche scan-the-internet-and-attack-as-you-go sous prétexte d '«aider» les gens à trouver problèmes sur leurs réseaux.

Notez qu'OpenSSL 1.0.2 est toujours pris en charge et mis à jour, mais en privé uniquement, pour les clients qui ont payé des contrats avec l'équipe OpenSSL, c'est pourquoi nous n'avons aucune information à divulguer ici à ce sujet, autre que de confirmer que le CVE -les bogues numérotés dans OpenSSL 3.0 ne s'appliquent pas à la série OpenSSL 1.0.2.

Vous pouvez lire la suite, et obtenez votre Mises à jour OpenSSL, du Site Web OpenSSL.

Oh, et si les PoC commencent à apparaître en ligne, s'il vous plaît, ne soyez pas des sabots intelligents et commencez à "essayer" ces PoC contre les ordinateurs d'autres personnes sous l'impression que vous "aidez" avec n'importe quelle sorte de "recherche".

---