Plus tôt cette semaine, l’OpenSSL Project avait prévenu les utilisateurs que les correctifs publiés jeudi répareraient plusieurs failles de sécurité, dont l'une jugée très sérieuse. Cette annonce avait donné lieu à plusieurs spéculations, certaines personnes imaginant même le pire : que cette nouvelle vulnérabilité ait un impact aussi dramatique que la faille Heartbleed dévoilée en avril dernier, qui avait affecté les serveurs Web, le logiciel client, les apps mobiles et même les appliances matérielles.

 Les versions 1.0.2a, 1.0.1m, 1.0.0r et 0.9.8zf livrées hier par OpenSSL viennent corriger 12 failles. Mais toutes les versions d'OpenSSL ne sont pas concernées par l’ensemble de ces vulnérabilités. La plus grave d’entre elles portant la référence CVE-2015-0291 peut exposer à des attaques par déni de service. Mais le problème ne concerne que la branche 1.0.2 d'OpenSSL. « Si un client se connecte à un serveur OpenSSL 1.0.2 et renégocie la connexion avec une extension de signature invalide, le déréférencement d’un pointeur NULL peut provoquer un déni de service », a déclaré l’OpenSSL Project dans son avis de sécurité. « Un attaquant distant pourrait exploiter le bug et provoquer le plantage des serveurs qui conduirait par ricochet à un déni de service », a expliqué dans un billet de blog Mark Cox, un membre de l’OpenSSL Project.

 Une faille mise en avant avec un POC

« Cependant, le nombre de cibles possibles reste limité, parce que la sortie d’OpenSSL 1.0.2 date de quelques mois seulement, et le nombre de serveurs utilisant cette version est encore modeste », a-t-il ajouté. OpenSSL assure le suivi de plusieurs versions majeures différentes en même temps, de sorte que les utilisateurs d'OpenSSL 1.0.1 n’ont aucune raison de passer à la version 1.0.2 s’ils n’ont pas besoin de ses nouvelles fonctionnalités. Et ils continueront à recevoir les correctifs de sécurité de la version 1.0.1.

 Selon Mark Cox, David Ramos de l'Université de Stanford, qui a trouvé et signalé la vulnérabilité CVE-2015-0291, a développé un exploit qu’il n’a pas diffusé. Mais Trey Ford, stratège en sécurité mondiale au sein du cabinet de sécurité Rapid7, pense que d'autres vont décortiquer le patch et développer un code d'attaque relativement rapidement. « Il faudrait livrer ces correctifs en priorité aux systèmes Internet vulnérables », a-t-il déclaré par courriel.

 Une nouvelle classification des failles attendue

Jeudi également, l’OpenSSL Project a reclassifié la vulnérabilité Freak au rang de sévérité élevée. La faille, rendue publique début mars, pourrait permettre des attaques man-in-the-middle pouvant réduire le niveau de sécurité des connexions SSL afin de casser les clefs de cryptage censées les protéger. La faille a été discrètement corrigée dans OpenSSL en janvier, mais à l'époque, la sévérité de la vulnérabilité avait été jugée « faible ». En effet, les premiers rapports indiquaient que la faille ne pouvait être exploitée que pour attaquer les connexions à des serveurs prenant en charge une suite de chiffrement obsolète connue sous le nom de RSA Export. Mais, « des études récentes ont montré que le support des suites de chiffrement RSA Export était beaucoup plus répandu que ce que l’on croyait. C’est pour cette raison que la vulnérabilité a été reclassée », a déclaré l’OpenSSL Project. Ces correctifs pour OpenSSL réparent également 8 failles de gravité modérée, dont certaines peuvent également servir, sous certaines conditions, à mener des attaques par déni de service, plus 3 failles dont la gravité est qualifiée de faible.

 Parce que l’annonce anticipée d'une faille sérieuse avait semé la confusion, le projet pourrait changer la hiérarchie de ses vulnérabilités. « Nous avons besoin d’une nouvelle classification. L’annonce de cette vulnérabilité a inutilement effrayé tout le monde », a déclaré sur Twitter Rich Salz, un membre de l’OpenSSL Project. « Nous allons modifier prochainement notre politique à ce sujet. OpenSSL a déjà connu des failles critiques, et les RSSI et les équipes informatiques chargées de la sécurité pourraient mettre au point un protocole préétabli pour y faire face. Il leur suffirait ensuite de suivre à chaque fois les mêmes procédures », a déclaré par courriel Cris Thomas, stratège en sécurité chez Tenable Network Security.