La faille Heartbleed
En avril dernier, la découverte d’une vulnérabilité sur certains serveurs utilisant le protocole SSL a enflammé la toile. La divulgation de cette faille, nommée Heartbleed, a déclenché tous types de réactions. Jusqu’aux plus alarmistes qui voyaient là la fin du protocole SSL, voire des algorithmes de chiffrement employés. Mais que s’est-il vraiment passé ?
I) La cible de la faille : OpenSSL
Les premières news venant de sources reconnues ont très vite rassuré le monde de la sécurité informatique : le problème ne vient ni du protocole SSL (ou plutôt son successeur TLS), ni des algorithmes cryptographiques sur lesquels il est basé. Tous ont probablement encore de beaux jours devant eux. La victime – ou le coupable suivant la manière de voir les choses – est OpenSSL, une implémentation open-source du protocole TLS. Si ce n’est pas aussi grave que la découverte d’une attaque sur RSA ou AES, l’affaire est tout de même sérieuse puisqu’OpenSSL est très largement utilisée.
II) Fonctionnement de la vulnérabilité
Pas de découverte mathématique révolutionnaire qui aurait mis à mal le monde de la cryptographie donc. Le problème vient de quelque chose de beaucoup plus trivial : une erreur de programmation.
Le protocole TLS comprend une fonctionnalité nommée Heartbeat. Il s’agit d’un mécanisme de type « écho », qui permet à l’une des extrémités d’une communication TLS – client ou serveur – d’envoyer à l’autre un message, que l’interlocuteur doit répéter en retour. Cette fonctionnalité permet de vérifier que la connexion chiffrée est toujours active.
Techniquement, un client qui veut s’assurer que le serveur répond toujours lui envoie un message ainsi qu’un entier représentant la longueur de ce message. Et c’est là que le bât blesse. Les développeurs d’OpenSSL ont enfreint l’un des principes de sécurité majeurs en programmation : toujours vérifier les données entrantes.
La faille se base sur le fait que le serveur ne vérifie pas que l’entier correspond réellement à la taille du message. Et pourtant il renvoie autant d’octets que demandé. Ainsi, si le client malintentionné indique une taille supérieure à cette du message, le serveur comble la différence avec ce qui se trouve dans sa mémoire. Soit potentiellement des données confidentielles, mots de passe, ou encore clés privées de certificats.
Cette petite bande dessinée illustre très bien le fonctionnement d’Heartbleed :
III) Etendue des dégats
La partie vulnérable du code a été ajoutée dans la version 1.0.1 d’OpenSSL, publiée le 14 mars 2012. L’existence d’Heartbleed n’a été révélée que le 7 avril 2014, quelques jours après sa découverte par une équipe Google. C’est également à cette date qu’est parue la version 1.0.1g qui corrige la faille, toutes les versions intermédiaires depuis la 1.0.1 étant vulnérables. Pendant ces deux ans il est impossible d’évaluer les pertes qu’Heartbleed a pu occasionner. Les plus optimistes penseront que personne n’a remarqué ni exploité ce bug. Pour les autres, il est facile d’imaginer des hackers et autres agences gouvernementales en tirer profit tout en se gardant bien d’en révéler l’existence.
IV) Un problème toujours d’actualité
Les premières estimations faisaient état d’environ 600000 serveurs vulnérables. Moins d’un mois après plus de la moitié avaient réglé le problème Heartbleed en mettant à jour OpenSSL et en révoquant les certificats qui avaient pu être compromis. Cependant, ce chiffre a très peu progressé depuis. En cause, des serveurs où les opérations de maintenance sont rares et/ou difficiles, indépendamment de la criticité des données traitées. On peut s’attendre, même dans plusieurs années, à trouver encore des systèmes où la faille Heartbleed sera toujours exploitable.
Emile
Consultant Sécurité
Références et lectures supplémentaires :
http://en.wikipedia.org/wiki/OpenSSL
http://www.cnet.com/news/heartbleed-still-a-threat-over-300000-servers-remain-exposed/
