web-dev-qa-db-fra.com

Comment patcher le bogue Heartbleed (CVE-2014-0160) dans OpenSSL?

À ce jour, un bogue dans OpenSSL a été détecté dans les versions 1.0.1 à 1.0.1f (inclus) et 1.0.2-beta.

Depuis Ubuntu 12.04, nous sommes tous vulnérables à ce bogue. Afin de corriger cette vulnérabilité, les utilisateurs affectés doivent mettre à jour OpenSSL 1.0.1g.

Comment chaque utilisateur concerné peut-il appliquer cette mise à jour maintenant ?

securityopenssl
153
Lucio

Les mises à jour de sécurité sont disponibles pour les versions 12.04, 12.10, 13.10 et 14.04 voir Avis de sécurité Ubuntu USN-2165-1 .

Donc, vous devez d’abord appliquer les mises à jour de sécurité disponibles, par exemple en exécutant

Sudo apt-get update
Sudo apt-get upgrade

à partir de la ligne de commande.

N'oubliez pas de redémarrer les services (HTTP, SMTP, etc.) qui utilisent la version OpenSSL concernée, sinon vous êtes toujours vulnérable. Voir aussi Heartbleed: De quoi s'agit-il et quelles sont les options pour l'atténuer? sur Serverfault.com.

La commande suivante affiche (après une mise à niveau) tous les services devant être redémarrés:

Sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp

Après cela, vous devez régénérer toutes les clés SSL du serveur , puis déterminer si vos clés ont pu fuir, auquel cas des attaquants peut avoir récupéré des informations confidentielles de vos serveurs.

141
Florian Diesch

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 exécutez tout 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. C'est un bogue d'implémentation, pas une faille dans le protocole, donc seuls les programmes qui utilisent la bibliothèque OpenSSL sont affecté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, à moins que 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?

Le bogue permet à tout client qui peut 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 récupérer sur un serveur?

  1. Mettez tous les serveurs concernés hors ligne. Tant qu'ils sont en cours d'exécution, ils risquent de laisser échapper des données critiques.

  2. Mettez à niveau le package libssl1.0.0 et assurez-vous que tous les serveurs concerné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`

  3. Génère 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).

  4. Maintenant que vous avez de nouvelles clés sans compromis, vous pouvez remettre votre serveur en ligne .

  5. Révoquer les anciens certificats.

  6. Evaluation des dommages : toute donnée conservée dans la mémoire d'un processus servant des connexions SSL peut potentiellement avoir été divulguée. 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 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, 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. (Ainsi, si vous venez d'exécuter wget pour 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

71
Gilles

Pour voir quelle version d'OpenSSL est installée sur Ubuntu, exécutez:

dpkg -l | grep openssl

Si vous voyez la version suivante sortie, le correctif pour CVE-2014-0160 devrait être inclus.

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...

En regardant https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12 , cela indique le type de bogues corrigés:

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...
40
crimi

Si votre apt-get référentiels ne contient aucun fichier précompilé 1.0.1g OpenSSL version, il suffit donc de télécharger les sources sur le site officiel et de les compiler.

Sous la ligne de commande unique, compilez et installez la dernière version de openssl.

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && Sudo ./config && Sudo make && Sudo make install

Remplacez l'ancien fichier binaire openssl par le nouveau via un lien symbolique.

Sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`

Vous êtes tous bons!

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014

Cf this article de blog .

NB: Comme indiqué dans l'article du blog, cette solution de contournement ne résoudra pas "le serveur Nginx et Apache qui doivent être recompilés avec des sources openSSL 1.0.1g".

17
Quentin Rousseau

Pour ceux qui ne veulent pas faire une mise à jour de paquet à l'échelle du serveur. J'ai lu un tas de ces guides aujourd'hui et apt-get upgrade openssl === apt-get upgrade cela s'appliquera à tous les correctifs de sécurité requis par votre machine. Merveilleux, à moins que vous ne vous appuyiez explicitement sur une ancienne version de paquet quelque part.

Il s’agit de l’action minimale requise sur Ubuntu 12.04 LTS exécutant Apache 2:

  • Allez à cette adresse et prouvez que vous avez la vulnérabilité. Vous devez utiliser l’ADRESSE EXTERNE DIRECTE DE VOTRE SERVEUR WEB. Si vous utilisez un équilibreur de charge (par exemple, ELB), il est possible que vous ne contactiez pas directement votre serveur Web.

  • Exécutez le 1 liner suivant pour mettre à niveau les packages et redémarrez. Oui, j'ai vu tous les guides dire que vous devriez avoir un horodatage plus tard que le 4 avril 2014, cela ne semble pas être le cas.

    apt-get update && apt-get install openssl libssl1.0.0 && /etc/init.d/Apache2 restart

  • Assurez-vous que les versions de package appropriées sont installées et vérifiez de nouveau la vulnérabilité de votre serveur Web.

Les packages de clés sont les suivants. J'ai déterminé ces informations à l'aide de la commande ci-dessous, puis les ai supprimées (vous n'avez pas besoin d'en savoir beaucoup sur l'état de mes machines).

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools

1.0.1-4ubuntu5.12 ne devrait PAS contenir la vulnérabilité. Assurez-vous que tel est le cas en consultant à nouveau le site Web ci-dessous et en testant votre serveur Web.

http://filippo.io/Heartbleed/

12
Adrian

J'ai remarqué que de nombreux commentateurs ont besoin d'aide de toute urgence. Ils suivent les instructions, mettent à niveau, redémarrent et restent vulnérables lorsqu'ils utilisent certains des sites Web de test.

Vous devez vérifier que vous n'avez pas de paquet en attente tel que libssl.

:~$ Sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.

Pour mettre à niveau ces apt-mark unhold libssl1.0.0 (par exemple). Ensuite, mettez à niveau: apt-get upgrade -V. Ensuite, redémarrez les services affectés.

11
Domino