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

152

À ce jour, un bogue dans OpenSSL a été trouvé, affectant 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 concernés doivent mettre à jour OpenSSL 1.0.1g .

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

    
posée Lucio 08.04.2014 - 00:17
la source

6 réponses

141

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

Vous devez donc d'abord appliquer les mises à jour de sécurité disponibles, par exemple en exécutant

sudo apt-get update
sudo apt-get upgrade

depuis 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: qu'est-ce que c'est et que sont-ils? des options pour l'atténuer? sur Serverfault.com.

La commande suivante montre (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 avez besoin pour régénérer toutes les clés SSL du serveur , évaluez ensuite si vos clés peuvent avoir fui, auquel cas les attaquants peuvent avoir récupéré des informations confidentielles sur vos serveurs.

    
réponse donnée Florian Diesch 08.04.2014 - 00:46
la source
71

Le bogue est appelé Heartbleed .

suis-je vulnérable?

En général, vous êtes affecté si vous exécutez un serveur pour lequel vous avez généré une clé SSL. La plupart des utilisateurs finaux ne sont pas (directement) affecté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 n'importe quel type de serveur utilisant les versions 1.0-1.0.1f d'OpenSSL (à l'exception des versions bien sûr corrigées depuis la découverte du bogue). Les versions d'Ubuntu concernées sont 11.10 oneiric à 14.04. 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 0.9.x d'OpenSSL, il n'est pas affecté. Seuls les programmes utilisant la bibliothèque OpenSSL pour implémenter le protocole SSL sont affectés; les programmes qui utilisent OpenSSL pour d'autres choses ne sont pas affectés.

Si vous avez exécuté un serveur vulnérable exposé à Internet, considérez-le comme compromis à moins que vos journaux ne montrent 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 n’a été exposé qu’en interne, vous devez savoir si vous devez changer les clés en fonction des autres mesures de sécurité en place.

Quel est l'impact?

Le bogue permet à tout client qui peut se connecter à votre serveur SSL d’extraire environ 64 Ko de mémoire du serveur. Le client n'a pas besoin d'être authentifié. 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. Déconnectez tous les serveurs concernés. Tant qu’ils sont en cours d’exécution, ils risquent de générer des fuites de 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érer de nouvelles clés . Cela est nécessaire car le bogue peut avoir 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, envoyez 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.
    • D'une manière ou d'une autre, déplacez les anciennes clés et les anciens certificats (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 restaurer votre serveur en ligne .

  5. Révoquer les anciens certificats.

  6. Évaluation des dommages : toutes les données qui se trouvaient dans la mémoire d’un processus desservant des connexions SSL ont potentiellement é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 ont pu être.

    • Si vous exécutez un service autorisant l’authentification par mot de passe, les mots de passe des utilisateurs qui se sont connectés un peu avant l’annonce de la vulnérabilité doivent être considérés comme compromis. (Un peu avant, car le mot de passe est peut-être resté inutilisé en mémoire pendant un moment.) Vérifiez vos journaux et modifiez les mots de passe de tout utilisateur affecté.
    • 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 depuis un peu avant que la vulnérabilité ne soit restée dans la mémoire du serveur et peuvent donc avoir été 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 récupérer sur un client?

Il existe peu de situations dans lesquelles les applications client sont affectées. Le problème du côté du serveur est que n'importe qui peut se connecter à un serveur et exploiter le bogue. Pour exploiter un client, trois conditions doivent être remplies:

  • Le programme client utilisait une version boguée de la bibliothèque OpenSSL pour implémenter le protocole SSL.
  • Le client connecté à un serveur malveillant. (Par exemple, si vous vous connectez à un fournisseur de messagerie, cela ne pose aucun problème.) Cela doit se produire après que le propriétaire du serveur a pris conscience de la vulnérabilité, donc probablement après le 04/04/2014.
  • Le processus client contenait des données confidentielles qui n'étaient pas partagées avec le serveur. (Donc, si vous venez de lancer wget pour télécharger un fichier, il n'y avait aucune donnée à divulguer.)

Si vous avez fait cela entre le 04-04-2014 soir et la mise à niveau de votre bibliothèque OpenSSL, considérez que toutes les données présentes dans la mémoire du processus client sont compromises.

Références

réponse donnée Gilles 08.04.2014 - 12:02
la source
40

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

dpkg -l | grep openssl

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

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

En regardant lien , vous voyez quels types de bogues ont été 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
...
    
réponse donnée crimi 08.04.2014 - 08:40
la source
17

Si vos référentiels apt-get ne contiennent pas de version précompilée 1.0.1g OpenSSL , téléchargez-les simplement sur le site Web officiel et compilez-les.

Ci-dessous la ligne de commande unique pour compiler et installer la dernière version 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

Remplacer 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 ce billet de blog .

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

    
réponse donnée Quentin Rousseau 08.04.2014 - 04:18
la source
12

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

C'est l’action minimale requise sur Ubuntu 12.04 LTS exécutant Apache 2:

  • Allez à cette adresse et montrez 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), vous ne contacterez peut-être pas directement votre serveur Web.

  • Exécutez le liner suivant pour mettre à niveau les packages et redémarrer. Oui, j'ai vu tous les guides disant que vous devriez avoir un horodatage après le 4 avril 2014, cela ne semble pas être le cas pour moi.

    apt-get update & amp; & amp; apt-get install openssl libssl1.0.0 & amp; & amp; /etc/init.d/apache2 restart

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

Les paquetages clés sont les suivants, j'ai déterminé cette information en utilisant la commande ci-dessous puis édité la version tardive (vous n'avez pas besoin de 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 doit PAS contenir la vulnérabilité. Assurez-vous que c'est le cas en revenant sur le site Web ci-dessous et en testant votre serveur Web.

lien

    
réponse donnée Adrian 08.04.2014 - 23:56
la source
11

J'ai remarqué de nombreux commentateurs ici qui ont besoin d’aide d’urgence. Ils suivent les instructions, la mise à niveau et le redémarrage, et sont toujours vulnérables lors de l'utilisation de certains 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 ceux apt-mark unhold libssl1.0.0 (par exemple). Ensuite, mettez à niveau: apt-get upgrade -V . Ensuite, redémarrez les services affectés.

    
réponse donnée Domino 08.04.2014 - 19:51
la source

Lire d'autres questions sur les étiquettes