GnuTLS est une bibliothèque libre qui, au même titre que OpenSSL, permet d’établir une connexion chiffrée sur Internet via le protocole SSL/TLS.

Une faille de sécurité qui permet de faire planter GnuTLS et, dans certaines conditions, lui faire exécuter du code arbitraire a été découverte.

Concrètement, lors d’une poignée de main, l’envoi d’un identifiant de session extrêmement long par le serveur provoque un dépassement de tampon. Pour résumer, on veut enregistrer en mémoire l’identifiant de session qui est plus grand que l’espace prévu à cet effet, l’excédent est écrit à côté et, en particulier, sur le programme en mémoire. En choisissant bien l’identifiant de session, on peut donc altérer le fonctionnement du logiciel en cours d’exécution à son avantage.

Après les deux failles mettant en cause l’utilisation d’instructions goto (l’une chez Apple, l’autre chez GNUTLS) et la faille Heartbleed, une vulnérabilité a encore été découverte : Triple Handshake («Triple poignée de main»), aussi appelée 3Shake.

Contrairement aux autres failles, celle-ci ne concerne pas l’implémentation mais le protocole. Cela signifie qu’elle touche potentiellement toutes les implémentations et que la correction définitive de cette faille nécessiterait une modification dans le protocole. En pratique, les corrections ont été effectuées en faisant des vérifications supplémentaires ou en éliminant certains algorithmes de chiffrement.

Logo par @Raed667
Concrètement, cette faille exploite les différents types de poignées de main (handshake, procédure qui permet d’établir les différents paramètres de communication entre deux machines, étape particulièrement importante pour un protocole de sécurité) afin de se faire passer pour une autre machine et d’effectuer une attaque de l’homme du milieu.

La faille est cependant considérée moins grave que Heartbleed, en partie parce qu’elle est compliquée, s’attaque à une configuration assez spécifique et nécessite une position privilégiée entre deux machines.

Pour ceux qui se demandent encore si ils doivent vraiment changer leurs mots de passe suite à l'affaire Heartbleed, qui veulent comprendre pourquoi il ne fallait pas le faire trop tôt, ou qui n'ont pas vérifié si leur navigateur détecte les certificats révoqués, l'article Taxonomie des attaques Heartbleed recense et explique schématiquement les diverses attaques rendues possibles par le bug, y compris contre les logiciels clients (reverse heartbleed), Tor et les VPN.

« Heartbleed » est une des pires failles qui soient arrivées à la sécurité sur Internet. À cause d'elle, les pirates ont pu ou peuvent obtenir des données confidentielles sans avoir besoin d'intercepter les échanges. Après les premières réactions centrées sur la mise à jour des serveurs web vulnérables, la révocation des certificats et le renouvellement des mots de passe, il a fallu quelques jours de plus pour comprendre que la faille Heartbleed affecte également les logiciels clients, les échanges SSL/TLS autres que HTTPS, et une multitude d'appareils embarqués qui ne recevront jamais de mise à jour logicielle.

Plus de détails dans la suite de la dépêche.

La fondation NetBSD a annoncé le 25 janvier dernier une nouvelle fournée de versions de leur système d'exploitation éponyme. Point de nouvelle fonctionnalité ici, il ne s'agit que de correctifs de bugs, et surtout de sécurité. Le nombre de nouvelles versions mineures peut sembler important, mais il n'est que l'application du plan de version tel qu'il est défini par la fondation. Ces versions sont les suivantes : 6.1.3, 6.0.4, 5.2.2 et 5.1.4.

De plus, le 12 avril dernier, deux nouvelles versions de la branche 6 ont été rendues disponibles, afin de corriger la désormais connue faille Heartbleed : 6.1.4 et 6.0.5. La branche 5 n'est pas affectée par cette faille.

Une partie de ces corrections est abordée en deuxième partie de dépêche.

Une vulnérabilité dans l’implémentation de l’extension heartbeat (RFC 6520) d’OpenSSL a été découverte conjointement par une équipe de chercheurs en sécurité (Riku, Antti and Matti) à Codenomicon et Neel Mehta de Google Securité. On retrouve ici un vieux bogue des familles : le read overrun.

OpenSSL 1.0.1, jusqu’à 1.0.1f inclus, et OpenSSL 1.0.2-beta1 sont affectés. Ce sont les versions utilisées dans la plupart des distributions.

Cette dernière permet la lecture de 64 Kio dans la mémoire des clients et serveurs affectés (mais l’attaque peut être rejouée à chaque heartbeat), autorisant la lecture de données comme les clés privées et, bien sûr, les données échangées une fois ces dernières retrouvées (et ce, même en mode hors ligne s’il n’y avait pas de forward secrecy utilisé).

Il est difficile, voire impossible, de faire une détection post‐mortem d’infiltration, l’attaque ne laissant pas d’entrée suspecte dans le journal système.

Passer à OpenSSL 1.0.1g, redémarrer tous les services utilisant libssl et remplacer l’intégralité de ses certificats (la clef privée étant vulnérable) est donc nécessaire.

Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l’accès chiffré aux serveurs Web. Il n’y a donc plus aucun site Web qui est à l’abri d’une attaque « man in the middle ».

Concrètement, l’attaque consiste à injecter du texte connu dans une page Web (via du JavaScript introduit dans une publicité vérolée, par exemple). Après, il suffit d’écouter la conversion (il faut quand même une session de 30 minutes pour l’exploit actuel) pour découvrir la clef AES. L’exploit permet donc de déchiffrer la page, mais aussi les cookies, et donc de s’identifier sur le site visé.

La faille concerne la version 1.0 de TLS et est corrigée dans la version 1.1, sortie en 2006. En outre, OpenSSL propose un contournement depuis 2004 ; il consiste à injecter des données aléatoires dans la transaction. Malheureusement, les navigateurs utilisent principalement NSS plutôt qu’OpenSSL, et même si sur le serveur on peut forcer l’utilisation de TLS 1.1 ou 1.2, très peu de navigateurs Web les supportent, ce qui freine le déploiement sur les serveurs. Actuellement, seuls IE 9 et Opera en sont capables !

Il faut cependant noter que ces failles sont connues depuis longtemps, c’est ce qui avait mené au correctif dans OpenSSL et à la création de TLS 1.1. Mais c’est la première fois qu’une attaque est publiée, validant ces propositions.

Quelques conseils de navigation :

• utiliser l’extension Firefox noscript ;
• actuellement, là où l’attaque pourra faire le plus de dégât, est sur les webmails ou sur les systèmes de paiement tels que Paypal (ben oui, si quelqu’un pirate ma connexion sur LinuxFr.org, ce ne sera pas très grave, car j’utilise différents mots de passe). Privilégiez donc les clients de messagerie électronique comme mutt ou Thunderbird, en désactivant le HTML.

Merci à Altor pour son aide lors de la rédaction de cette dépêche.