15 avril 2014

Heartbleed, la faille d’OpenSSL

heartbleed

La semaine dernière, Heartbleed, une faille catastrophique a été découverte dans OpenSSL, compromettant la plupart des services majeurs d’Internet (http://heartbleed.com). L’impact est très important, puisque l’utilisation de cette faille permet à un attaquant de lire les données en mémoire d’un serveur (pouvant contenir des identifiants, des mots de passe en clair et bien d’autres informations personnelles). Le code d’exploitation de cette vulnérabilité circule librement sur Internet et est disponible pour Metasploit (https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb).

Après les failles impactant la vérification de certificats dans iOS et GnuTLS dont nous avions parlé le mois dernier, c’est une nouvelle vulnérabilité qui ébranle la confiance que l’on peut porter aux mécanismes de cryptographie qui sont essentiels à la confidentialité et à l’intégrité des échanges sur le web.

Techniquement, il s’agit une nouvelle fois d’une grossière erreur d’implémentation d’une extension de TLS, « Heartbeat ». Cette extension permet de maintenir des connexions TLS notamment au travers d’un firewall. Le client peut demander au serveur de lui répéter un message en lui spécifiant la longueur (sur 16 bits) sans qu’aucune vérification de cette longueur ne soit faite. Si une longueur supérieure au message est fournie, le serveur répond gracieusement avec le contenu de sa mémoire en complément (un fragment de 2^16 bits maximum soit 64K). Ce XKCD le montre très bien en images : http://xkcd.com/1354/.

Si la plupart des services ont été patchés la semaine dernière, il est nécessaire de détecter si la zone mémoire contenant la clé privée du serveur a pu être révélée, alors toute communication passée ou future n’est pas à l’abri d’un déchiffrement, à moins que de la « Perfect forward secrecy » soit utilisée par le serveur. Un renouvellement des certificats devrait donc être une remédiation à court termes. Des outils permettent de déterminer si un site est vulnérable(https://www.ssllabs.com/ssltest/index.htmlhttp://filippo.io/Heartbleed/).

Côté utilisateur, une bonne pratique à prendre est de renouveler ses mots de passe et d’envisager, si ce n’est pas déjà le cas, une authentification trois facteurs pour les services les plus critiques. Mashable fournit une liste de sites qui peut servir de référence : http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/?utm_cid=mash-com-fb-main-link.

 Quels enseignements pouvons-nous tirer de ce trio de vulnérabilités apparues en l’espace de deux mois ?

La conversation sur Hacker News apporte des éléments de réponse intéressants : https://news.ycombinator.com/item?id=7548991. Le langage C, par sa nature permet par exemple ce genre d’erreur. Sa rapidité, son ubiquité, son maigre « memory fingerprint » et sa capacité à être appelé par d’autres langages en fait le langage universel par excellence. Peut-être que dans les temps à venir le développement de Go (http://golang.org/) ou de Rust (http://www.rust-lang.org/) offriront des alternatives plus sûres pour le développement de librairies de sécurité.

On peut craindre que cette vulnérabilité (introduite en 2011) ait déjà été découverte par des groupes de hackers ou des organisations gouvernementales. Il est très probable que la NSA dispose de tout une panoplie d’automatismes ou d’outils d’analyse statique visant à détecter les possibles dépassements de tampon de ce genre dans les librairies open source.

Cette découverte doit sonner comme un signal d’alarme pour tous les acteurs de l’industrie informatique et les développeurs. L’implication des compagnies dans le développement des outils open source de sécurité doit continuer à croître, et de nouvelles solutions doivent être imaginées pour rendre plus difficile l’apparition de ce type de vulnérabilité.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *