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


A partir d'aujourd'hui, un bug dans OpenSSL a été trouvé affectant les versions 1.0.1 par 1.0.1f (inclus) et 1.0.2-beta.

Depuis Ubuntu 12.04, nous sommes tous vulnérables à ce bogue. Pour 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? à présent?


152
2018-04-07 22:17


origine


Avez-vous une version affectée de openssl? - Braiam
J'ai la version corrigée 1.0.1-4ubuntu5.12 et j'ai redémarré le service apache mais filippo.io/Heartbleed tester sur mon site dit toujours que je suis vulnérable Toute idée pourquoi?
@ Mat Je ne sais pas ce que le site teste, mais peut-être détecte-t-il que vous utilisez une ancienne clé. Comme la clé peut avoir fui, vous devez la régénérer. - Gilles
Vous ne voulez vraiment pas mettre à jour OpenSSL vers de nouvelles versions de gros, c'est une douleur incroyable. Il est beaucoup plus simple d'installer le package mis à jour qui corrige le problème: ubuntu.com/usn/usn-2165-1 - sarnold
avez-vous redémarré vos services après la mise à niveau? - Axel


Réponses:


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

à partir de la ligne de commande.

N'oublie pas de redémarrer les services (HTTP, SMTP, etc.) qui utilisent la version OpenSSL concernée, sinon vous êtes toujours vulnérable. Voir également Heartbleed: qu'est-ce que c'est et quelles sont les 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 ça, tu dois régénérer toutes les clés SSL du serveur, puis évaluez si vos clés ont pu fuir, auquel cas les attaquants peuvent avoir récupéré des informations confidentielles sur vos serveurs.


141
2018-04-07 22:46



Pas sûr que cela fonctionne sur Ubuntu 12.04.4 LTS. Après mise à jour complète, openssl version donne OpenSSL 1.0.1 14 Mar 2012. Ce n’est pas la version corrigée, non? Ou suis-je mal compris? - Paul Cantrell
Que faire avec Ubuntu 13.04? Aucun openssl mis à jour disponible :-( - Frodik
Sur Ubuntu 12.04, même la version fixe d'OpenSSL affiche 1.0.1 14 Mar 2012. Lis réponse de crimi pour savoir si votre installation inclut le correctif. - dan
Merci @dan! Resummarizing @ crimi's answer here: si vous courez dpkg -l | grep ' openssl ' et vous obtenez 1.0.1-4ubuntu5.12 alors vous êtes prêt à partir. - Paul Cantrell
Le correctif et le redémarrage ne suffisent pas. Vous devez régénérer les clés et évaluer si vos clés ont été divulguées ainsi que d’autres éléments confidentiels. Voir par exemple Est-ce que Heartbleed signifie de nouveaux certificats pour chaque serveur SSL? - Gilles


Le bug est connu sous le nom Heartbleed.

Suis-je vulnérable?

En règle générale, 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 bug permet n'importe quel client qui peut se connecter à votre serveur SSL pour récupérer environ 64 Ko de mémoire sur le 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 usurper l'identité de votre serveur.

Comment puis-je récupérer sur un serveur?

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

  2. Mettre à niveau le libssl1.0.0 paquetet 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 libssl `` grep '.(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, 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 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 remettez 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 peuvent 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 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 certain temps.) Vérifiez vos journaux et modifiez les mots de passe de tous les utilisateurs concernés.
    • 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 la vulnérabilité peuvent être restées 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 a été assuré - si vous ne savez pas, ce ne était pas.)

Comment est-ce que je récupère 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 ait pris conscience de la vulnérabilité, donc probablement après le 04/04/2014.
  • Le processus client avait des données confidentielles en mémoire qui n'étaient pas partagées avec le serveur. (Donc, si vous venez de courir wget pour télécharger un fichier, il n'y avait pas de données à 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.

Les références


71
2018-04-08 10:02



Je ne crois pas que "seul le côté serveur des connexions SSL / TLS est affecté" est vrai. openssl.org/news/secadv_20140407.txt dit qu'il peut révéler des secrets de client ou de serveur. ubuntu.com/usn/usn-2165-1 accepte Les chances d'utiliser des certificats clients lors de la connexion à un serveur malveillant sont faibles, mais la possibilité existe. - armb
@armb Vous faites 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 de certificats. J'ai enrôlé l'aide de professionnels. - Gilles
Les certificats clients sont le cas où vous feriez une fuite de clés privées, mais oui, les mots de passe, les cookies d'autorisation, etc., pourraient fuir de toute façon. Cependant, avec un client basé sur OpenSSL tel que curl ou wget dans un usage typique, vous n'auriez pas de secrets pour les autres sites en mémoire lors de la connexion à un serveur malveillant, donc je pense que la seule fuite serait si vous donniez des secrets au client anticipant de les donner à un site légitime, et Heartbleed les a divulgué pendant la poignée de main avant que la vérification du certificat révèle que vous n'êtes pas connecté au bon site. - armb
@Gilles Vous pourriez être intéressé par les réponses à Quels clients se sont avérés vulnérables à Heartbleed?. J'ai réussi à gagner de la mémoire "intéressante" sur nginx (mode proxy), wget, liens et autres. - Lekensteyn
@ MuhamedHuseinbašić Le paquet openssl contient des outils en 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 devez simplement appliquer les mises à jour de sécurité de la distribution. - Gilles


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

dpkg -l | grep openssl

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

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

Regarder https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12, il montre quels types de bogues sont 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
2018-04-08 06:40



J'ai mis à jour et obtenir la version 5.12 mais cet outil me dit toujours que je suis vulnérable filippo.io/Heartbleed Pensées? - toxaq
J'ai testé nos serveurs mis à jour de ce côté et il m'a dit que je n'étais pas affecté. Avez-vous redémarré votre système ou du moins êtes-vous sûr que tous les processus nécessaires ont été redémarrés? - crimi
Après avoir mis à jour OPENSSL, il suffisait de redémarrer le service apache, mais gracieux n'a pas aidé. Je devais aller et redémarrer en utilisant sudo service apache2 restart - Tom Hert
Je viens de trouver la cause de ma vulnérabilité: j'ai installé mod-spdy-beta. Après l'avoir retiré et redémarré apache, tous les tests sont maintenant verts. - Andreas Roth
Mise à jour openssl ne répare pas les applications telles qu'Apache, Nginx ou postfix. Vous devez mettre à jour libssl1.0.0 et les redémarrer comme expliqué dans d'autres articles. - tnj


Si ton apt-get repositories ne contient pas de précompilé 1.0.1g OpenSSL version, téléchargez simplement les sources du site officiel et compilez-le.

Sous 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

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 cela article de blog.

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


17
2018-04-08 02:18



Comme d'habitude, Ubuntu ne fournit pas la nouvelle version en amont, mais a corrigé les versions de toutes les versions prises en charge pour limiter les modifications au minimum. - Florian Diesch
Remarque: Assurez-vous de redémarrer votre serveur après avoir mis à jour OpenSSL. Apache et Nginx ont récupéré la nouvelle lib et la vulnérabilité a été fermée. - dAngelov
Heh, maintenant que je prends le temps de lire le détails Dans cet article, je suis encore plus bouleversé - le téléchargement d'une archive depuis un endroit quelconque d'Internet, le déballage et l'exécution d'éléments comme root ne sont que des comportements imprudents. Ce serait un peu mieux si les signatures tarball étaient téléchargées et vérifiées, mais s’assurer que vous validez les signatures signées par la bonne clé est en soi une question difficile. Des distributions ont déjà été effectuées pour assurer la sécurité de la provenance des archives et des patches. Merci. - sarnold
il pourrait être une bonne idée de compiler à partir de source MAINTENANT, et installer un plus récent à partir d'apt, de cette façon votre plus sûr que sans attente sur les anciennes versions d'ubuntu de toute façon juste mes deux cents - nwgat
@sarnold openssl.org ne semble pas être un endroit aléatoire pour télécharger la source de openssl. Canonical devrait rendre cela inutile, mais openssl.org devrait être l'autorité en amont pour travailler. - Rustavore


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

Voici l'action minimale requise sur Ubuntu 12.04 LTS exécutant Apache 2:

  • Aller à cette adresse et prouver 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 la ligne suivante pour mettre à jour les paquets et redémarrer. Oui, j'ai vu tous les guides dire que vous devriez avoir un horodatage après le 4 avril 2014, cela ne semble pas être le cas pour moi.

    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 votre vulnérabilité sur le serveur Web une fois de plus.

Les paquets clés sont les suivants, j'ai déterminé cette information en utilisant la commande ci-dessous, puis édité la version précédente (vous n'avez pas besoin d'en savoir plus 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 c'est le cas en revenant sur le site Web ci-dessous et en testant votre serveur Web.

http://filippo.io/Heartbleed/


12
2018-04-08 21:56



L'utilisation d'un site externe pour prouver une vulnérabilité sur un serveur semble être une mauvaise approche pour moi. - Rinzwind
Les scripts de test de vulnérabilité externes sont de plus en plus courants. Il fait exactement ce que fait un script interne, la connexion est simplement initiée à partir d'un serveur Web externe. Vous pouvez rechercher des sites comme WhiteHatSecurity.com pour un exemple de programme qui lance toutes les connexions à distance. Il y a des cas où cela ne volerait pas, par exemple le test de vulnérabilité du réseau, mais pour tester un serveur Web vers l'avant (qui en général sera un serveur SSL), c'est presque idéal. - Adrian
Pourquoi installer le paquet s'il est mis à niveau? - Braiam
apt-get install openssl libssl1.0.0 l'a fait pour moi Fonctionnement openssl version -a montre maintenant: built on: Mon Apr 7 20:33:29 UTC 2014 - topher
«Les scripts de tests de vulnérabilité externes sont de plus en plus courants», ce qui 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 de le corriger. Non, ce n'est pas la bonne façon. (et oui je héberge mes propres sites avec apache et openssl). - Rinzwind


J'ai remarqué beaucoup de 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 pour vous assurer 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 à jour ceux apt-mark unhold libssl1.0.0 (par exemple). Ensuite, mettez à niveau: apt-get upgrade -V. Ensuite, redémarrez les services affectés.


11
2018-04-08 17:51