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

152

À 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 ?

Lucio
la source
Avez-vous une version affectée d’openssl?
Braiam
J'ai la version 1.0.1-4ubuntu5.12 corrigée et j'ai redémarré le service Apache mais les tests filippo.io/Heartbleed sur mon site indiquent toujours que je suis vulnérable. Vous savez pourquoi?
1
@Mat Je ne sais pas ce que le site teste, mais peut-être qu'il détecte que vous utilisez une ancienne clé. Puisque la clé a peut-être fui, vous devez la régénérer.
Gilles
1
Vous ne voulez vraiment pas mettre à jour OpenSSL vers les nouvelles versions en gros, c'est une douleur incroyable. Beaucoup plus facile est d'installer uniquement le package mis à jour que les correctifs de la question: ubuntu.com/usn/usn-2165-1
sarnold
avez-vous redémarré vos services après la mise à niveau?
Axel

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 .

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.

Florian Diesch
la source
23
Pas sûr que cela fonctionne sur Ubuntu 12.04.4 LTS. Après la mise à jour complète, openssl versiondonne OpenSSL 1.0.1 14 Mar 2012. Ce n'est pas la version patchée, non? Ou est-ce que je me trompe?
Paul Cantrell
7
Que faire avec Ubuntu 13.04? Aucune mise à jour disponible disponible :-(
Frodik
20
Sur Ubuntu 12.04, même la version d’affichage OpenSSL corrigée 1.0.1 14 Mar 2012. Lisez la réponse de Crimi pour savoir si votre installation inclut le correctif.
dan
7
Merci, @dan! Résumer la réponse de @ crimi ici: si vous courez dpkg -l | grep ' openssl 'et vous obtenez 1.0.1-4ubuntu5.12alors vous êtes prêt à partir.
Paul Cantrell
20
Corriger et redémarrer ne suffit pas. Vous devez régénérer les clés et déterminer si vos clés ont été divulguées, ainsi que d'autres documents confidentiels. Voir, par exemple, Heartbleed signifie-t-il de nouveaux certificats pour chaque serveur SSL?
Gilles
71

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

Gilles
la source
4
Je ne crois pas que "seul le côté serveur des connexions SSL / TLS soit affecté" est vrai. openssl.org/news/secadv_20140407.txt indique qu'il peut révéler des secrets du client ou du serveur. ubuntu.com/usn/usn-2165-1 accepte. Les chances que vous utilisiez des certificats clients lors de la connexion à un serveur malveillant sont faibles, mais cette possibilité existe.
Armb
@armb Vous faites valoir un bon point. Peu importe que les certificats clients soient utilisés ou non, la fuite de données n’est pas liée à l’utilisation des certificats. J'ai fait appel à des professionnels .
Gilles
Les certificats de client sont le cas où vous perdriez des clés privées, mais oui, les mots de passe, les cookies d'autorisation, etc. pourraient néanmoins fuir. Cependant, avec un client basé sur OpenSSL tel que curl ou wget dans une utilisation typique, vous n'auriez pas de secrets pour d'autres sites en mémoire lors de la connexion à un serveur malveillant. Dans ce cas, je pense que la seule fuite serait si vous donniez les secrets du client. anticipant de les donner à un site légitime, et Heartbleed les a divulguées lors d'une poignée de main avant que la vérification du certificat révèle que vous n'êtes pas connecté au bon site.
Armb
1
@ Gilles Vous voudrez peut-être connaître les réponses à Quels clients sont-ils vulnérables à Heartbleed? . J'ai réussi à gagner de la mémoire "intéressante" sur nginx (mode proxy), wget, liens et autres.
Lekensteyn
1
@ MuhamedHuseinbašić Le paquet opensslcontient des outils de ligne de commande. Il n'est pas utilisé par les applications qui utilisent la bibliothèque OpenSSL pour implémenter le protocole SSL (tel qu'Apache). Mais vous devriez simplement appliquer les mises à jour de sécurité de la distribution.
Gilles
40

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
...
crimi
la source
2
J'ai mis à jour et j'obtiens la version 5.12 mais cet outil me dit toujours que je suis vulnérable. Filippo.io/Heartbleed Thoughts?
Toxaq
3
J'ai testé nos serveurs mis à jour de ce côté et il m'a dit que je ne suis pas affecté. Avez-vous redémarré votre système ou au moins êtes-vous sûr que tous les processus nécessaires ont été redémarrés?
Crimi
3
Après la mise à jour de l'OPENSSL, tout ce que je devais faire était de redémarrer le service Apache, mais gracieux ne m'a pas aidé . Je devais y aller et recommencer en utilisantsudo service apache2 restart
Tom Hert
1
Je viens de trouver la cause de ma vulnérabilité: j'avais installé mod-spdy-beta. Après l'avoir retiré et redémarré apache, tous les tests sont maintenant verts.
Andreas Roth
3
La mise à jour opensslne corrige pas les applications telles qu'Apache, Nginx ou postfix. Vous devez les mettre à jour libssl1.0.0et les redémarrer comme expliqué dans d'autres publications.
tnj
17

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

Quentin Rousseau
la source
2
Comme d'habitude, Ubuntu ne fournit pas la nouvelle version en amont, mais corrige les versions de toutes les versions prises en charge pour limiter les modifications au minimum.
Florian Diesch
1
Remarque: assurez-vous de redémarrer votre serveur après la mise à jour de OpenSSL. Apache et Nginx ont récupéré la nouvelle bibliothèque et la vulnérabilité a été fermée.
dAngelov
6
Heh, maintenant que je prends le temps de lire les détails de cette publication, je suis encore plus consterné: télécharger une archive tar depuis un emplacement quelconque au hasard sur Internet, décompresser et exécuter certaines parties de celle-ci en tant que root ne constitue qu'un comportement téméraire. Ce serait un peu mieux si les signatures d'archive étaient téléchargées et vérifiées, mais s'assurer que vous validez les signatures ont été signées avec la bonne clé est en soi une question difficile. Les distributions ont déjà été consacrées aux efforts visant à garantir la provenance en toute sécurité des archives et des correctifs. Merci.
Sarlold
2
il pourrait être une bonne idée de compiler à partir des sources maintenant, et installer une version plus récente d' une suite de apt, de cette façon votre plus sûr que sans expectly sur les anciennes versions de ubuntu de toute façon que mes deux cents
nwgat
2
@sarnold openssl.org ne semble pas être un endroit aléatoire pour télécharger le source pour openssl. Canonical devrait rendre cela inutile, mais openssl.org devrait faire autorité en amont.
Rustavore
12

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/

Adrian
la source
2
Utiliser un site externe pour prouver une vulnérabilité sur un serveur semble être une mauvaise approche pour moi.
Rinzwind
Les scripts de tests de vulnérabilité externes sont de plus en plus courants. Il fait exactement ce que fait un script interne, la connexion est simplement établie à partir d'un serveur Web externe. Vous pouvez consulter des sites tels que WhiteHatSecurity.com pour un exemple de programme initiant toutes les connexions à distance. Il y a des cas où cela ne marcherait pas, par exemple, les tests de vulnérabilité du réseau, mais pour tester un serveur Web orienté vers l’avant (qui sera en général un serveur SSL), c’est presque idéal.
Adrian
Pourquoi installer le paquet s'il est mis à jour?
Braiam
1
apt-get install openssl libssl1.0.0l'a fait pour moi. Courir openssl version -amaintenant montre:built on: Mon Apr 7 20:33:29 UTC 2014
topher le
"Les scripts de tests de vulnérabilité externes sont de plus en plus courants ces temps-ci." Cela ouvre la possibilité que ce site externe abuse de mon système: tout ce dont ils ont besoin pour le savoir échoue et pirate mon système avant que je ne le corrige. Non ce n'est pas la bonne façon. (et oui j'héberge mes propres sites avec apache et openssl).
Rinzwind
11

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.

Domino
la source