OpenSSL avertit d’une vulnérabilité de sécurité critique avec le correctif à venir
\nNous n'avons pas encore les détails, mais nous pouvons dire en toute sécurité que le 1er novembre, tout le monde -- et je veux dire tout le monde -- devra corriger OpenSSL 3.x.\n
Tout le monde dépend d’OpenSSL. Vous ne le savez peut-être pas, mais OpenSSL est ce qui permet d’utiliser TLS (Transport Layer Security) sécurisé sur Linux, Unix, Windows et de nombreux autres systèmes d’exploitation. C'est aussi ce qui est utilisé pour verrouiller à peu près toutes les applications et tous les appareils de communication et de réseau sécurisés.
MISE À JOUR : OpenSSL esquive une balle de sécurité
Nous devrions donc tous être préoccupés par le fait que Mark Cox, un ingénieur logiciel distingué de Red Hat et vice-président de la sécurité de l'Apache Software Foundation (ASF), a tweeté cette semaine : « Mise à jour OpenSSL 3.0.7 pour corriger CVE critique mardi prochain 1300-1700UTC. »
Quelle est la gravité de « Critique » ? Selon OpenSSL, un problème de gravité critique affecte les configurations courantes et est également probablement exploitable.
Il est susceptible d'être abusé pour divulguer le contenu de la mémoire du serveur, et potentiellement révéler les détails de l'utilisateur, et pourrait être facilement exploité à distance pour compromettre les clés privées du serveur ou exécuter du code exécuter à distance. En d'autres termes, à peu près tout ce que vous ne voulez pas qui se passe sur vos systèmes de production.
Eep !
La dernière fois qu’OpenSSL a eu un coup de pied dans ses dents de sécurité comme celle-ci, c’était en 2016. Cette vulnérabilité pourrait être utilisée pour planter et prendre le contrôle de systèmes. Même des années après son arrivée, la société de sécurité Check Point a estimé qu’elle affectait plus de 42% des organisations.
Celui-ci pourrait être pire. Nous ne pouvons qu'espérer que ce n'est pas aussi mauvais que ce champion de tous les temps des failles de sécurité d'OpenSSL, HeartBleed de 2014.
Alors, pourquoi annoncer la faille de sécurité avant que le patch ne soit en cours ? Cox a expliqué : « C'est notre politique ... pour fournir aux gens une date qu’ils connaissent pour être prêts à analyser un avis et à voir si le problème les affecte.
Mais un pirate ne pourrait-il pas le trouver et l'exploiter comme un jour zéro ? Il ne le pense pas. « Compte tenu du nombre de changements dans la section 3.0 et de l’absence de toute autre information contextuelle, un tel récurage est très peu probable. »
Il y a un autre petit côté positif dans ce nuage sombre. Ce nouveau trou affecte uniquement les versions 3.0.0 à 3.0.6 d’OpenSSL. Ainsi, les systèmes d’exploitation et les appareils plus anciens sont susceptibles d’éviter ces problèmes. Par exemple, Red Hat Enterprise Linux (RHEL) 8.x et versions antérieures et Ubuntu 20.04 ne seront pas frappés par elle. RHEL 9.x et Ubuntu 22.04, cependant, sont une histoire différente. Ils utilisent OpenSSL 3.x.
Si vous êtes un utilisateur Linux, vous pouvez vérifier votre propre système en exécutant la commande shell :
# version openssl
Dans mon cas, mon ordinateur portable devant moi exécute Debian Bullseye, qui utilise OpenSSL 1.1, donc cette machine est bonne.
Mais, si vous utilisez quelque chose avec OpenSSL 3.x dans -- n'importe quoi -- préparez-vous à patcher mardi. Il s’agit probablement d’une mauvaise faille de sécurité, et les exploits suivront bientôt. Vous voudrez rendre vos systèmes sûrs dès que possible.