Le projet OpenSSL a cette semaine annoncé son intention de publier la version 3.0.7 le 1er novembre afin de corriger une faille de sécurité critique touchant les versions 3.0 et ultérieures. Son cofondateur Mark J. Cox a souligné qu’il ne s’agissait que du deuxième correctif critique « depuis que nous avons commencé à évaluer la gravité des failles, en 2014 ».
OpenSSL considère comme critiques les problèmes touchant les configurations courantes et susceptibles d’être exploités, notamment « la divulgation importante du contenu de la mémoire du serveur (pouvant révéler des informations sur les utilisateurs), les vulnérabilités facilement exploitables à distance pour compromettre les clés privées du serveur, ou encore les situations où l’exécution de code à distance est considérée comme probable dans des circonstances courantes ».
Art Manion, analyste senior des vulnérabilités chez ANALYGENCE, a fait observer que le 1er novembre, jour de la Toussaint, est malheureusement un jour férié dans plusieurs pays de l’UE, et Cox a reconnu : « Nous ne l’avions pas réalisé. Il est assez difficile d’éviter tous les jours fériés partout. »
Voir les meilleurs outils de débogage et de sécurité du code
Que faire dès maintenant concernant OpenSSL
Le développeur de logiciels Carlos Solís a demandé, « Alors, quelles mesures temporaires devons-nous appliquer à nos serveurs pendant la levée de l’embargo ? » Cox, sans détour, a répondu : « Nous n’avons fourni aucune autre information pour le moment. »
Les chercheurs de Sophos ont néanmoins recommandé une mesure cruciale à prendre avant mardi prochain, conseillant : « Tous les utilisateurs d’OpenSSL devraient profiter de ce délai pour recenser les instances d’OpenSSL et se préparer à appliquer immédiatement le correctif dès sa publication. »
Cox a abondé dans ce sens : « C’est un bon conseil. Si vous savez à l’avance où vous utilisez OpenSSL 3.0+ et comment vous l’utilisez, vous pourrez rapidement déterminer, à la publication de l’avis, si vous êtes concernés et de quelle manière, ainsi que les éléments à corriger. »
Pour faciliter ce processus, Johannes B. Ullrich, doyen de la recherche au SANS, a publié une liste des versions d’OpenSSL pour plus de 25 systèmes d’exploitation, précisant : « MacOS utilise par défaut LibreSSL, et non openssl installé. Mais openssl peut être installé ultérieurement par d’autres logiciels comme Homebrew et MacPorts. »
À lire également : La réponse aux vulnérabilités serait-elle la gestion des correctifs sous forme de service ?
Le prochain Heartbleed ?
Mattias Gees, responsable produit conteneurs chez Venafi, a déclaré que cette annonce rappelait des failles aux conséquences considérables comme Heartbleed et Log4Shell. « Heartbleed a eu un impact considérable sur les équipes chargées des opérations partout dans le monde et, depuis, les infrastructures informatiques sont devenues dix fois plus complexes », a-t-il déclaré.
« Lorsque Heartbleed a été découvert, la majorité des entreprises informatiques utilisaient du matériel dédié ou des machines virtuelles (VM) », a expliqué Gees. « Mais nous sommes désormais à l’ère du Cloud Native, qui a donné naissance à des conteneurs avancés et à des architectures sans serveur. Le vecteur d’attaque est devenu bien plus vaste et, au lieu de devoir simplement examiner leurs VM, les entreprises doivent commencer à se préparer à corriger toutes leurs images de conteneurs en réponse à cette annonce. »
Les entreprises qui ont déjà audité leurs dépendances en réponse à Log4Shell seront, selon Gees, bien placées pour déployer un correctif aussi efficacement que possible.
Le fait que la faille ne touche que la version 3.0 et les versions ultérieures devrait, a-t-il ajouté, au moins limiter son impact potentiel. « Mais les équipes d’ingénierie des plateformes devraient continuer à investir dans un meilleur audit de leurs environnements et de leurs dépendances en prévision de la prochaine menace, qui est toujours à deux doigts de surgir. »
À lire ensuite :