Le bogue s'appelle Heartbleed .
Suis-je vulnérable?
Généralement, vous êtes affecté si vous utilisez un serveur pour lequel vous avez généré une clé SSL à un moment donné. La plupart des utilisateurs finaux ne sont pas (directement) touchés. au moins Firefox et Chrome n'utilisent pas OpenSSL. SSH n'est pas affecté. La distribution des paquets Ubuntu n'est pas affectée (elle repose sur les signatures GPG).
Vous êtes vulnérable si vous utilisez un type de serveur utilisant les versions 1.0 à 1.0.1f d'OpenSSL (à l'exception des versions de cours corrigées depuis la découverte du bogue). Les versions concernées d'Ubuntu sont les versions 11.10 oneiric à 14.04, versions préliminaires fiables. Il s’agit d’un bogue d’implémentation et non d’une faille dans le protocole. Seuls les programmes utilisant la bibliothèque OpenSSL sont concernés. Si vous avez un programme lié à l'ancienne version OpenSSL 0.9.x, il n'est pas affecté. Seuls les programmes qui utilisent la bibliothèque OpenSSL pour implémenter le protocole SSL sont concernés. les programmes qui utilisent OpenSSL pour d'autres tâches ne sont pas affectés.
Si vous avez exécuté un serveur vulnérable exposé à Internet, considérez qu'il est compromis sauf si vos journaux n'indiquent aucune connexion depuis l'annonce du 2014-04-07. (Cela suppose que la vulnérabilité n'a pas été exploitée avant son annonce.) Si votre serveur était uniquement exposé en interne, la nécessité de modifier les clés dépendra des autres mesures de sécurité en place.
Quel est l'impact?
Ce bogue permet à tout client pouvant se connecter à votre serveur SSL de récupérer environ 64 Ko de mémoire sur le serveur. Le client n'a pas besoin d'être authentifié de quelque manière que ce soit. En répétant l'attaque, le client peut vider différentes parties de la mémoire lors de tentatives successives.
L’une des données critiques que l’attaquant peut récupérer est la clé privée SSL du serveur. Avec ces données, l'attaquant peut emprunter l'identité de votre serveur.
Comment puis-je récupérer sur un serveur?
Mettez tous les serveurs affectés hors ligne. Tant qu'ils fonctionnent, ils risquent de laisser échapper des données critiques.
Mettez à niveau le libssl1.0.0package et assurez-vous que tous les serveurs affectés sont redémarrés.
Vous pouvez vérifier si les processus affectés sont toujours en cours d’exécution avec «grep» libssl. (supprimé) '/ proc / / maps`
Générer de nouvelles clés . Cela est nécessaire car le bogue aurait peut-être permis à un attaquant d'obtenir l'ancienne clé privée. Suivez la même procédure que vous avez utilisée initialement.
- Si vous utilisez des certificats signés par une autorité de certification, soumettez vos nouvelles clés publiques à votre autorité de certification. Lorsque vous obtenez le nouveau certificat, installez-le sur votre serveur.
- Si vous utilisez des certificats auto-signés, installez-le sur votre serveur.
- Quoi qu'il en soit, déplacez les anciennes clés et certificats hors de portée (mais ne les supprimez pas, assurez-vous simplement qu'ils ne sont plus utilisés).
Maintenant que vous avez de nouvelles clés sans compromis, vous pouvez remettre votre serveur en ligne .
Révoquer les anciens certificats.
Évaluation des dommages : toutes les données qui ont été dans la mémoire d'un processus servant des connexions SSL peuvent potentiellement avoir été divulguées. Cela peut inclure des mots de passe utilisateur et d'autres données confidentielles. Vous devez évaluer ce que ces données peuvent avoir été.
- Si vous exécutez un service qui autorise l'authentification par mot de passe, les mots de passe des utilisateurs qui se sont connectés peu de temps avant l'annonce de la vulnérabilité devraient être considérés comme compromis. (Un peu avant, car le mot de passe peut rester inutilisé en mémoire pendant un moment.) Consultez vos journaux et modifiez les mots de passe de tout utilisateur concerné.
- Invalide également tous les cookies de session, car ils peuvent avoir été compromis.
- Les certificats clients ne sont pas compromis.
- Toutes les données échangées un peu avant la vulnérabilité pourraient être restées dans la mémoire du serveur et auraient donc pu être divulguées à un attaquant.
- Si quelqu'un a enregistré une ancienne connexion SSL et récupéré les clés de votre serveur, il peut maintenant déchiffrer sa transcription. (Sauf si PFS était assuré - si vous ne le savez pas, ce n'était pas le cas.)
Comment puis-je récupérer sur un client?
Il existe peu de situations dans lesquelles les applications clientes sont affectées. Le problème côté serveur est que tout le monde peut se connecter à un serveur et exploiter le bogue. Pour exploiter un client, trois conditions doivent être remplies:
- Le programme client a utilisé une version buggy de la bibliothèque OpenSSL pour implémenter le protocole SSL.
- Le client connecté à un serveur malveillant. (Ainsi, par exemple, si vous vous êtes connecté à un fournisseur de messagerie électronique, ce n'est pas un problème.) Cela devait se produire après que le propriétaire du serveur a pris connaissance de la vulnérabilité, probablement après le 2014-04-07.
- Le processus client contenait en mémoire des données confidentielles non partagées avec le serveur. (Donc, si vous venez
wgetde télécharger un fichier, aucune donnée ne doit fuir.)
Si vous avez fait cela entre la nuit 2014-04-07 UTC et la mise à niveau de votre bibliothèque OpenSSL, considérez que toutes les données contenues dans la mémoire du processus client sont compromises.
Références