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

À ce jour, un bogue dans OpenSSL affectant les versions 1.0.1via 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 ?

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 .

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 évaluer si vos clés ont peut-être fui, auquel cas des attaquants pourraient avoir récupéré des informations confidentielles de vos serveurs.

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?

1. Mettez tous les serveurs affectés hors ligne. Tant qu'ils fonctionnent, ils risquent de laisser échapper des données critiques.

2. 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`

3. 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).

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. É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

• The Heartbleed Bug (par l'une des deux équipes qui ont découvert le bogue indépendamment)
• Comment fonctionne exactement l'exploit OpenSSL TLS Heartbeat (Heartbleed)?
• Heartbleed signifie-t-il de nouveaux certificats pour chaque serveur SSL?
• Heartbleed: Qu'est-ce que c'est et quelles sont les options pour l'atténuer?

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 , il indique quel type de bogue est corrigé:

...
 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
...

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

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

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

Pour ceux qui ne veulent pas faire une mise à jour de paquet à l'échelle du serveur. J'ai lu un grand nombre de ces guides aujourd'hui et apt-get upgrade openssl=== apt-get upgradecela 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.12NE 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/

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 les mettre à niveau apt-mark unhold libssl1.0.0(par exemple). Ensuite , la mise à niveau: apt-get upgrade -V. Ensuite, redémarrez les services affectés.