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.

La dernière dépêche de cette catégorie LinuxFr.org qui ne soit pas une dépêche récurrente type « Les meilleurs journaux du mois » ou « Les prix du mois » ou « Les statistiques de l'année » remonte à mai 2014 pour une mise à jour du serveur. Voici donc, à l'aube de l'été, quelques actualités de type « en coulisses ».

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.

Il y a quelques mois était publiée la version 5.3.7 de PHP, sans s'assurer que certains bugs critiques, comme celui de la fonction crypt(), avaient été corrigés.

Cela avait conduit a une sortie précipitée de PHP 5.3.8 contenant les correctifs nécessaires avec une alerte pour la version 5.3.7 .

Beaucoup ont alors espéré que les développeurs de PHP allaient changer de méthodes de travail.

Le 10 janvier sortait la version 5.3.9 de PHP qui contenait, entre autres, un correctif pour une vieille faille de sécurité qui permettait de fabriquer facilement des collisions dans une hashtable conduisant à un déni de service (faille déjà mentionnée ici-même).

Le hic fut que le correctif introduisait une nouvelle faille de sécurité qui, pour éviter de permettre de faire des collisions, permettait une exécution arbitraire de code.

Le 2 février fut publié la version 5.3.10, qui corrige la faille introduite par le correctif précédent.

Une vulnérabilité (CVE-2014-9390) a été annoncée hier soir concernant le logiciel de gestion de versions le plus en vogue en ce moment, j'ai nommé Git, ainsi que sur Mercurial, autre logiciel de la même catégorie. Elle a déjà été corrigée, je vous invite donc à mettre à jour vos installations.

Github, le service d'hébergement de dépôt Git lui aussi très en vogue, a de son côté annoncé avoir vérifié tous les dépôts présents sur ses serveurs à la recherche d'exploitations de cette vulnérabilité. Mesure de sécurité supplémentaire, il refuse désormais les push exploitant cette faille.

NdM : Merci à RoM1 et Sébastien Douche pour les précisions apportées dans la dépêche. La faille a été trouvée par le créateur de Mercurial, Matt Mackall, et Augie Fackler. La vulnérabilité se décline en trois parties :

• la sensibilité à la casse dans Git, déjà corrigé dans Mercurial en 2008 ;
• l’expansion des noms courts sous Windows (PROGRA~1 → Program Files), déjà corrigé dans Mercurial ;
• la découverte récente de la façon non documentée dont Darwin (Apple) s’amuse avec HFS+ à ignorer certains caractères spéciaux et qui peut créer de nouvelles collisions de nom (cf la correction chez Mercurial, qui a permis la correction côté Git).

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.