La fuite ‘Heartbleed’ d’OpenSSL a de sérieuses conséquences

Une erreur d’implémentation dans SSL/TLS d’OpenSSL a causé la fuite d’importantes informations sécuritaires d’installations.

C’est sous l’appellation ‘Heartbleed’ qu’un problème s’est récemment manifesté au niveau de l’implémentation de SSL/TLS (Secure Socket Layer/Transport Layer Security) d’OpenSSL. Après sa découverte par des chercheurs chez Google et chez le spécialiste finnois de la sécurité Codenomicon, il est apparu que suite à une erreur dans le code SSL (pas un ‘bounds check’), une requête ‘hearbeat’ de la part de TLS (un signal pour vérifier si un système est encore disponible) pouvait retourner au demandeur un fragment de la capacité mémoire pouvant atteindre 64 Ko. Le problème, c’est que dans l’espace mémoire impliqué se trouvent des informations à propos des clés de cryptage primaire et secondaire, destinées à l’établissement d’une connexion SSL sécurisée. Sur le site de ‘Heartbleed’, l’on explique comment le trafic (même plus ancien) peut être décrypté, alors que la fuite peut concerner aussi des noms d’utilisateurs, mots de passe, voire le contenu de messages. Le problème est d’importance car de nombreux services, entreprises, organisations et autres utilisent les bibliothèques OpenSSL impliquées.

Que faire?

Entre-temps, le code a été mis à jour, et OpenSSL affirme explicitement que seules les versions d’OpenSSL 1.0.1 jusqu’à et y compris 1.0.1f sont vulnérables (la version 1.0.1g est la version actualisée, lancée le 7 avril), ainsi que la 1.0.2 bêta (adaptée dans la 1.0.2 bêta2).

Le problème cause cependant pas mal de soucis parce que le code l’affichait depuis deux ans déjà et que l’on ne sait pas vraiment si durant cette période, le bug a été abusé ou non. Et comme l’affirme le site Heartbleed, “l’abus de ce bug ne laisse aucune trace d’une quelconque anormalité dans les historiques”. Il conseille donc aux fournisseurs de services qui utilisent les versions concernées “de rappeler les clés compromises et d’en distribuer de nouvelles”, en collaboration avec les ‘certificate authorities’ ad hoc. Ensuite, les utilisateurs peuvent modifier leurs mots de passe, etc. “Seuls les propriétaires des services sont à même d’évaluer la probabilité de ce qui aurait pu faire l’objet d’une fuite et devraient alors prévenir les utilisateurs.” Entre-temps, un outil http://filippo.io/Heartbleed/ a déjà été publié pour contrôler si un serveur utilise une version à problème (lire d’abord les FAQ, tout particulièrement ‘is this a live test? Demandez et rapatriez éventuellement vous-même l’outil, sur GitHub).

Le site Heartbleed signale que les producteurs de serveurs web open source tels Apache sont d’importants utilisateurs d’OpenSSL. Par ailleurs, il n’est pas question ici d’éconduire les développeurs open sourde d’OpenSSL ou de leur adresser des reproches, selon la tendance des nombreux commentaires. C’est ainsi que Matthew Green, un cryptographe de la John Hopkins University, prétend très clairement sur son blog que l’équipe “étonnamment réduite” d’OpenSSL a établi un “pretty amazing record” et qu’un peu plus de soutien (financier) de la part de nombreuses entreprises qui exploitent son travail, ne serait pas superflu.