Fort justement baptisée Heartbleed, la dernière vulnérabilité découverte au sein de la librairie Linux OpenSSL a de quoi, effectivement, faire saigner le coeur des administrateurs systèmes. Certains n’hésitent d’ailleurs pas à la comparer à la grande faille des clés OpenSSL sous Debian de 2008, en pire…

La faille CVE-2014-0160 permet à un attaquant de récupérer jusqu’à 64k de la mémoire du serveur vulnérable. Et dans ces 64k, l’on peut y trouver en vrac la clé privée du serveur (le saint des saints qui protège les échanges chiffrés par SSL), ainsi que des morceaux d’informations entrains d’être échangés avec des clients et que l’on pense évidemment être à l’abris des regards indiscrets (des mots de passe, le contenu de conversations en cours, etc…).

Les informations contenues dans les 64k renvoyés par le serveur sont aléatoires : il est impossible de « demander » spécifiquement à obtenir la clé privée du certificat serveur, par exemple. Mais puisque l’opération est invisible dans les journaux, un attaquant a tout le loisir d’essayer en boucle jusqu’à ce qu’il obtienne des informations de valeurs.

Parmi les données qui peuvent être dérobées de la sorte, la clé privée du serveur est de loin la plus précieuse : cela permet alors à un attaquant capable d’intercepter le trafic du site web de le déchiffrer dans sa totalité, puisque cette clé est utilisée lors de la négociation initiale avec tous les clients, avant même que ne soient générées les clés de sessions spécifiques (sauf à utiliser la technique de perfect forward secrecy, au prix d’un impact sur les performances CPU du serveur d’environ 15%).

Heureusement, selon l’un des ingénieurs à l’origine de la découverte de cette vulnérabilité, les « chances » pour un attaquant de récupérer la clé privée sont plutôt faibles :

Heap allocation patterns make private key exposure unlikely for #heartbleed #dontpanic.

— Neel Mehta (@neelmehta) April 8, 2014

Mais même sans perte de la clé privée, les dégâts peuvent être sérieux : entre les mots de passe des utilisateurs connectés sur le serveur et leurs cookies de session, le risque d’usurpation d’identité et de vol de données des utilisateurs est réel.

Fort heureusement tous les serveurs fonctionnant sous OpenSSL ne sont pas obligatoirement vulnérables. D’abord parce que seules les branches 1.0.1 et 1.0.2-beta sont concernées, jusqu’aux versions 1.0.1f et 1.0.2-beta1. Et ensuite parce qu’il faut que le serveur ait activé l’extension Heartbeat de SSL. C’est elle, en effet, qui contient le code vulnérable.

Selon la société Netcraft environ 17,5% des serveurs Apache et nginx dans le monde fonctionneraient avec OpenSSL et Heartbeat activé. Cela ferait au total un demi-million de sites vulnérables (et vous pouvez savoir si vous en faite partie grâce à un service en ligne créé pour l’occasion. Par ailleurs le SSL Labs – notre propre suite gratuite de tests SSL en ligne – a été également mise à jour en ce sens)

Pour se protéger contre une telle attaque la meilleure solution est de mettre à jour OpenSSL. La version 1.0.1g fraîchement publiée corrige l’erreur (les utilisateurs de Debian stable ont droit quant à eux à une version 1.0.1e-2+deb7u6 qui corrige aussi la vulnérabilité). Si la mise à jour n’est pas possible il reste l’option de recomplier OpenSSL en désactivant l’extension Heartbeat, avec la ligne de commande -DOPENSSL_NO_HEARTBEATS. Enfin, il est également conseillé d’activer PFS (Perfect Forward Secrecy) pour les échanges SSL.

Une fois protégé, cependant, rien ne prouve que la clé privée du certificat serveur n’est pas déjà partie dans la nature : la vulnérabilité existe en effet depuis 2012 et a très bien pu être découverte plus tôt par des acteurs moins scrupuleux. En fonction du niveau de risque acceptable il est donc fort possible qu’il faille re-générer des centaines de milliers de certificats SSL à travers le monde.

Enfin, la question se pose également pour les utilisateurs de services en ligne dont les serveurs pouvaient être vulnérables : il existe un risque, certes réduit, que leurs identifiants aient été dérobés. Là encore, chacun décidera en son âme et conscience s’il doit changer tous ses mots de passe…