Question Heartbleed: De quoi s'agit-il et quelles sont les options pour l'atténuer?


C'est un Question canonique comprendre et résoudre le problème de sécurité Heartbleed.

Qu'est-ce que CVE-2014-0160 AKA "Heartbleed"? Quelle est la cause, quels systèmes d’exploitation et versions d’OpenSSL sont vulnérables, quels sont les symptômes, existe-t-il des méthodes permettant de détecter un exploit réussi?

Comment puis-je vérifier si mon système est affecté? Comment cette vulnérabilité peut-elle être atténuée? Dois-je m'inquiéter du fait que mes clés ou d'autres données privées ont été compromises? Quels autres effets secondaires devrais-je m'inquiéter?


204
2018-04-08 00:26


origine


Atténuation pour Heartbleed implique plus que de nouvelles clés. (Lien vers ma réponse sur Information Security StackExchange) - scuzzy-delta
Je vous entends, mais je pense que la EEAA a couvert de manière assez détaillée la question ci-dessous. - MadHatter
Je suis d'accord: c'est une excellente réponse, mais heartbleed.com fait de gros efforts pour souligner qu’il ya des considérations qui vont au-delà des nouvelles paires de clés, telles que le forçage des modifications de mot de passe et l’invalidation de session. - scuzzy-delta
@ scuzzy-delta - bon point. Ma réponse est maintenant CW, alors n'hésitez pas à la modifier / l’améliorer avec cette information. - EEAA
Meilleur exemple de ce que c'est - (sans surprise) XKCD: xkcd.com/1354 - Wayne Werner


Réponses:


PremierAvant de paniquer, assurez-vous de bien comprendre si cette vulnérabilité s’applique réellement à vous ou non. Si vous avez un serveur, mais que vous n’avez jamais eu d’applications utilisant TLS, il ne s’agit donc pas d’une tâche hautement prioritaire à réparer. Si, par contre, vous ont déjà eu Les applications compatibles TLS, eh bien, vous êtes pris au dépourvu. Continuer à lire:

Qu'est-ce que CVE-2014-0160, autrement dit "Heartbleed"?

C'est un gros bazar, c'est ce que c'est. En résumé, une vulnérabilité exploitable à distance a été découverte dans les versions OpenSSL 1.0.1 à 1.0.1f par lesquelles un attaquant peut lire certaines parties de la mémoire système. Ces éléments sont ceux qui contiennent des données sensibles telles que des clés privées, des clés pré-partagées, des mots de passe et des données d'entreprise de grande valeur, entre autres.

Le bogue a été découvert de manière indépendante par Neel Mehta de Google Security (21 mars 2014) et par la société finlandaise de tests de sécurité informatique Codenomicon (2 avril 2014).

Quelle est la cause?

Eh bien, code errant dans OpenSSL. Ici est le commit qui a introduit la vulnérabilité, et ici est le commit qui a corrigé la vulnérabilité. Le bogue est apparu en décembre 2011 et a été corrigé aujourd'hui, le 7 avril 2014.

Le bogue peut également être considéré comme un symptôme d'un problème plus vaste. Les deux problèmes liés sont (1) quel processus est en place pour garantir que le code errant n'est pas introduit dans une base de code, et (2) pourquoi les protocoles et les extensions sont-ils si complexes et difficiles à tester. L'élément (1) est un problème de gouvernance et de processus avec OpenSSL et de nombreux autres projets. De nombreux développeurs résistent simplement à des pratiques telles que la révision de code, l'analyse et le scan. Le point (2) est en discussion sur le groupe de travail TLS de l'IETF. Voir Heartbleed / complexité du protocole.

Le code errant a-t-il été malicieusement inséré?

Je ne spéculerai pas sur le point de savoir si c'était vraiment une erreur ou éventuellement un peu de code inséré de la part d'un mauvais acteur. Cependant, la personne qui a développé le code pour OpenSSL a déclaré que c'était par inadvertance. Voir Un homme qui a introduit une grave faille de sécurité 'Heartbleed' nie l'avoir inséré délibérément.

Quels systèmes d'exploitation et versions d'OpenSSL sont vulnérables?

Comme mentionné ci-dessus, tout système d'exploitation utilisant ou toute application liée à OpenSSL 1.0.1 à 1.0.1f.

Quels sont les symptômes, existe-t-il des méthodes pour détecter un exploit réussi?

C'est la partie effrayante. À notre connaissance, il n’existe aucun moyen de détecter si cette vulnérabilité a été exploitée ou non. Il est théoriquement possible que des signatures IDS soient détectées prochainement pour détecter cet exploit, mais à ce jour, elles ne sont pas disponibles.

Il a été prouvé que Heartbleed était activement exploité dans la nature dès novembre 2013. Voir le FEP Sauvage au cœur: les agences de renseignement utilisaient-elles Heartbleed en novembre 2013? Et Bloomberg rapporte que la NSA avait armé l'exploit peu de temps après l'introduction de la vulnérabilité. Voir La NSA exploitée depuis des années pour exploiter le virus Heartbleed. Cependant, les services de renseignement américains nient les affirmations de Bloomberg. Voir IC SUR LE RECORD.

Comment puis-je vérifier si mon système est affecté?

Si vous maintenez OpenSSL sur votre système, alors vous pouvez simplement émettre openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Si la distribution maintient OpenSSL, vous ne pourrez probablement pas déterminer la version d’OpenSSL en raison de la correction des correctifs à l’aide de openssl commande ou les informations sur le package (par exemple, apt-get, dpkg, yum ou rpm). Le processus de correction de correctif utilisé par la plupart des distributions (toutes?) Utilise uniquement le numéro de version de base (par exemple, "1.0.1e"); et fait ne pas inclure un version de sécurité efficace (par exemple, "1.0.1g").

Une question ouverte sur le super utilisateur consiste à déterminer la version de sécurité effective pour OpenSSL et les autres packages lorsque les packages sont renvoyés en arrière. Malheureusement, il n'y a pas de réponses utiles (autres que consulter le site Web de la distribution). Voir Déterminer la version de sécurité effective face à Backpatching?.

En règle générale: si vous avez déjà installé l'une des versions concernées et avez exécuté des programmes ou des services liés à OpenSSL pour la prise en charge de TLS, vous êtes vulnérable.

Où puis-je trouver un programme pour tester la vulnérabilité?

Quelques heures après l’annonce de Heartbleed, plusieurs utilisateurs d’Internet ont annoncé des applications Web accessibles au public, censées être utilisées pour vérifier la présence de cette vulnérabilité sur un serveur. Au moment de la rédaction de cet article, je n’en ai examiné aucune, je ne publierai donc plus leurs applications. Ils peuvent être trouvés relativement facilement à l'aide de votre moteur de recherche préféré.

Comment cette vulnérabilité est-elle atténuée?

Effectuez une mise à niveau vers une version non vulnérable et réinitialisez ou sécurisez de nouveau les données vulnérables. Comme indiqué sur le Heartbleed site, les étapes de réponse appropriées sont généralement:

  1. Corrigez les systèmes vulnérables.
  2. Régénérez de nouvelles clés privées.
  3. Soumettez une nouvelle CSR à votre autorité de certification.
  4. Obtenez et installez un nouveau certificat signé.
  5. Invalider les clés de session et les cookies
  6. Réinitialiser les mots de passe et les secrets partagés
  7. Révoquer les anciens certificats.

Pour une analyse plus détaillée et une réponse, voir Que doit faire un exploitant de site Web à propos de l’exploit Heartbleed OpenSSL?sur le Security Stack Exchange.

Dois-je m'inquiéter du fait que mes clés ou d'autres données privées ont été   compromis? Quels autres effets secondaires devrais-je m'inquiéter?

Absolument. Les administrateurs de systèmes doivent assumer que leurs serveurs utilisant des versions vulnérables d'OpenSSL sont effectivement compromis et réagissent en conséquence.

Peu de temps après la divulgation de la vulnérabilité, Cloudfare a lancé un défi pour savoir si la clé privée d'un serveur pouvait être récupérée dans la pratique. Le défi a été remporté indépendamment par Fedor Indutny et Ilkka Mattila. Voir Le défi Heartbleed.

Où puis-je trouver plus d'informations?

Lien de vidage, pour ceux qui recherchent plus de détails:


Une chronologie assez détaillée des événements de divulgation peut être trouvée à Calendrier de divulgation de Heartbleed: qui savait quoi et quand.


Si vous êtes programmeur et êtes intéressé par diverses astuces de programmation telles que la détection d'une attaque Heartbleed via OpenSSL msg_cb rappel, puis voir OpenSSL Avis de sécurité 2014047.


118
2018-04-08 04:23



+1 pour FERMER. VERS LE BAS. VOTRE. LES SERVEURS.* - Si vous faites quelque chose pour lequel SSL est vraiment important, fermez-le jusqu'à ce que vous résolviez le problème. N'oubliez pas non plus d'installer de nouveaux certificats (avec nouvelles clés) après avoir corrigé vos serveurs - la réutilisation de vos anciennes clés (qui ont peut-être été compromises) annule l’objet de la correction de la vulnérabilité ... - voretaq7
ÉGALEMENT - redémarrez tous les services liés aux bibliothèques OpenSSL. Mettre à jour OpenSSL sans redémarrer vos démons équivaut à ne pas mettre à jour du tout. - EEAA
En effet, après tout type de correctif majeur (comme OpenSSL), j’estime qu’il est judicieux de redémarrer la machine pour s’assurer de ne rien manquer. - voretaq7
L'un des testeurs a été open-source: github.com/FiloSottile/Heartbleed - Riking
@EEAA, "arrêter vos serveurs" ne signifie pas que vous devez tirer le courant. Cela signifie arrêter (ou reconfigurer pour désactiver ssl / tls) apache, ou quel que soit le service servant le serveur. - psusi


Une explication simple du bogue, par XKCD:

XKCD 1354


42
2018-04-08 07:28





Ubuntu 12.04, 12.10 et 13.10

Ubuntu a publié USN-2165-1, qui indique que les paquets mis à jour sont maintenant disponibles dans les archives. Exécutez les deux commandes suivantes pour récupérer le correctif.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

J'ai téléchargé un paquet Debian contenant la nouvelle version (1.0.1g) sur un PPA que j'ai configuré à cette fin. Ces trois commandes vont ajouter my PPA à votre système, mettre à jour la liste des paquetages disponibles et tout mettre à jour:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

Remarque: PPA fournit également des packages pour Ubuntu 12.04 et 13.10, juste au cas où vous préférez exécuter la nouvelle version (1.0.1g) au lieu d’utiliser uniquement les versions corrigées des archives.

Ubuntu 10.04

Ceci est une version LTS, la version du serveur est toujours prise en charge et reçoit des mises à jour de sécurité. Mais la vulnérabilité heartbleed n'a pas affecté le paquet openssl d'une installation standard d'ubuntu 10.04, car la version est inférieure à 1.0.1.

La version de bureau est en fin de vie et doit être mise à niveau / réinstallée.

Ubuntu 13.04 et autres versions obsolètes

Ubuntu 13.04 a eu un cycle de support très court auquel vous ne pourriez pas vous attendre. Il est déjà en fin de vie et ne reçoit plus les mises à jour de sécurité. Il devrait depuis longtemps être mis à niveau. Si quelqu'un l'utilise encore, veuillez mettre à niveau maintenant, soit à partir de zéro ou il peut être mis à niveau de manière non destructive à 13.10 en suivant cette procédure simple: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail-to-ubuntu-13-10-saucy-salamander/ Après la mise à niveau, le système reçoit le correctif heartbleed de 13.10.

Pour toutes les autres versions obsolètes d'ubuntu, cela signifie essentiellement qu'une nouvelle installation est nécessaire.

Vérifiez que le correctif a été appliqué

Essentiellement, courir openssl version -a et assurez-vous que la date de construction est le 7 avril 2014 ou plus tard, mais voyez plus ici.

Redémarrer

Le meilleur moyen de vous assurer que tous les services dépendant de OpenSSL sont redémarrés est de: redémarrer.


36
2018-04-08 10:37



Je ne peux pas parler pour d'autres versions, mais il semble y avoir un correctif disponible pour precise (12.04). Bien que je ne puisse pas affirmer avec certitude que cela corrige la vulnérabilité, elle a au moins été compilée après le commit correspondant (Mon Apr 7 20:31:55 UTC 2014). - Calrion
@Calrion: Un patch pour OpenSSL ou le paquetage Debian pour OpenSSL? OpenSSL a déjà été corrigé et une nouvelle version publiée. - Nathan Osman
qu'adviendra-t-il des connexions existantes lors de la mise à jour d'OpenSSL? seront-ils lâchés? - pdeva
Cela dépend du serveur Web que vous utilisez et de la façon dont vous mettez à jour. Cela étant dit, je ne crains pas de perdre des connexions existantes, car elles utilisent la version vulnérable. - Nathan Osman
14.04 a depuis reçu un patch. - Seth


RedHat 6.5 et CentOS 6.5

Ce sont vulnérables. Erratum RHSA-2014-0376 de RedHat indique que des bibliothèques mises à jour sont disponibles, et que toutes les personnes concernées doivent procéder à la mise à niveau dès que possible.

Au moment de la rédaction, CentOS n’avait pas encore de version corrigée, mais Annonce de Karanbir Singh sur CentOS dit qu'ils ont produit une version mise à jour de openssl (openssl-1.0.1e-16.el6_5.4.0.1Notez les quatre derniers chiffres importants) pour lesquels la commande TLS exploitable est désactivée et qui peut être appliquée en toute sécurité car elle sera écrasée par une version corrigée lors de sa publication ultérieure.

La version temporairement corrigée ne semble pas encore être sur tous les miroirs, mais se trouve dans le référentiel principal à http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (et pareillement pour i686).

modifier: comme le dit Iain, il semble qu’il existe maintenant une version entièrement corrigée pour C6.5, qui semble avoir été déplacée à la hâte autour des miroirs. Une suite yum update Je l'ai eu pour mes serveurs; ses openssl-1.0.1e-16.el6_5.7.

Versions de RH6 et C6 antérieures à 6.5

Ce ne sont pas vulnérables. Selon cet avis de Red Hat,

Ce problème n’affectait pas les versions d’openssl livrées avec Red.   Hat Enterprise Linux 5 et Red Hat Enterprise Linux 6.4 et versions antérieures.

Annonce de Karanbir Singh sur CentOS est tout aussi clair sur le versioning:

Plus tôt dans la journée, nous avons été informés d’une grave   question dans openssl telle que livrée dans CentOS-6.5


14
2018-04-08 13:07



N'est pas listes.centos.org/pipermail/centos-announce/2014-avril/… la sortie du correctif? - Iain


Debian Wheezy

Debian a publié DSA-2896-1 et les bibliothèques patchés sont disponible ici. Un script shell est disponible ici.

1. Patch

Le référentiel Apt-get a été mis à jour et des bibliothèques patchés sont maintenant disponibles via apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Alternativement (non recommandé), les packages peuvent être mis à niveau manuellement:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Redémarrez le serveur / les services

Pour une meilleure protection, redémarrez le serveur entier ou si le serveur ne peut pas être hors ligne, redémarrez les services nécessaires.

3. Vérifiez la version OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

13
2018-04-08 11:23



Si vous recevez des mises à jour de wheezy/security alors vous serez bon avec apt-get update && apt-get upgrade. Ou utilisez un gestionnaire de paquets interactif pour mettre à jour uniquement les paquets openssl, libssl1.0.0, libssl1.0.0-dbg et libssl-dev (tel qu'installé sur votre système). - α CVn
utiliser apt-get ne résout pas le problème pour moi - il continue d'afficher OpenSSL 1.0.1e 11 février 2013 - user568829
Merci @ michael-kjorling, ce n'était pas disponible quand j'ai fait ça, mais c'est la manière la plus sûre et la plus correcte de mettre à jour. - jacksoncage
@ user568829 après l'application du correctif, la version openssl reste affichée OpenSSL 1.0.1e 11 Feb 2013 comme le patch s'appelle 1.0.1e-2. Vous pouvez vérifier avec dpkg -l openssl et il devrait montrer la version 1.0.1e-2+deb7u6 - jacksoncage
Je suggérerais de redémarrer l'hôte après la mise à jour d'OpenSSL, non pas parce que c'est strictement nécessaire, mais pour votre tranquillité d'esprit, au moins tout ce qui charge les bibliothèques OpenSSL de manière dynamique utilise la nouvelle version. (La liaison statique est un autre problème.) Cela dit, je reconnais que certains serveurs ne peuvent pas être facilement redémarrés dans toutes les situations où un redémarrage du service peut être acceptable. - α CVn


J'aimerais souligner que les clés privées ne sont pas les seuls actifs qui doivent être considérés comme compromis. Le bug a le potentiel de fuir tout mémoire fonctionnant dans le même espace adresse (c'est-à-dire le même processus) qu'OpenSSL. Par conséquent, si vous exécutez un processus serveur dans lequel une version vulnérable d'OpenSSL est liée statiquement ou dynamiquement, tout élément d'information que ce processus a jamais traité, y compris les mots de passe, les numéros de carte de crédit et d’autres données personnelles, doivent être considérés comme potentiellement compromis.


9
2018-04-08 20:23





FreeBSD 10.0 ou openssl des ports

le L'équipe de sécurité de FreeBSD a émis un avis concernant CVE-2014-0160 (alias "Heartbleed") et: FreeBSD-SA-14: 06.openssl

  1. Mise à jour de FreeBSD

    • Mise à jour de FreeBSD via un patch binaire

      Systèmes exécutant un Version finale de FreeBSD sur le i386 ou amd64 les plateformes peuvent être mises à jour via l'utilitaire freebsd-update (8):

      # freebsd-update fetch
      # freebsd-update install
      
    • Mise à jour de FreeBSD à partir des sources

      1. Téléchargez le correctif correspondant à l’emplacement ci-dessous et vérifiez le signature PGP détachée à l’aide de votre utilitaire PGP.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        
      2. Exécutez les commandes suivantes en tant que root:

        # cd /usr/src
        # patch < /path/to/patch
        
      3. Recompiler le système d'exploitation

        en utilisant monde bâti et installworld comme décrit dans le Manuel FreeBSD.

  2. Mettre à jour le openssl port avec version minimale 1.0.1_10

  3. Redémarrez tous les démons à l'aide de la bibliothèque ou redémarrez le système.

  4. Agissez comme si votre système avait été compromis, réémettez toutes vos clés et / ou vos certificats SSL et les informations potentiellement divulguées (voir EEAA réponse plus générale).

FreeBSD 9.x et FreeBSD 8.x

Ces systèmes sont pas vulnérable au Heartbleed problème par défaut, s’appuyant sur l’ancienne version 0.9.x du openssl bibliothèque, sauf si vous avez installé openssl  des ports (voir en haut).

Si ces systèmes ne sont pas vulnérables à la Heartbleed problème, il pourrait être sage de mettre à niveau votre système plutôt tôt que tard en raison d’une autre local vulnérabilité (voir FreeBSD-SA-14: 06.openssl et la section "FreeBSD 10.0" en haut):

Un attaquant local pourrait être en mesure de surveiller un processus de signature et pourrait récupérer   la clé de signature de celui-ci. [CVE-2014-0076]

Remarque:

L'original Heartbleed consultatif répertorie FreeBSD 8.4 et 9.1 comme potentiellement vulnérables. Ce n'est pas vrai en raison du manque de Extension de battement de coeur (La bibliothèque OpenBSL FreeBSD par défaut est la version 0.9.x).


9
2018-04-11 08:03





J'ai trouvé presque impossible de déterminer les versions de SSL utilisées sur plusieurs des appliances avec lesquelles je travaille. Bien que ce ne soit pas techniquement correct, pouvoir identifier les hôtes actuellement vulnérables était en haut de ma liste.

J'ai mis en place une petite machine virtuelle qui effectuera des vérifications sur des hôtes et des ports arbitraires à l'aide de Module de test de FiloSottile. Au premier coup d’œil, le code semble solide.

La publication de la machine virtuelle terminée est ici. C'est au format VMX.

Mots d'avertissement

Ce script et VM vont seulement affiche le statut actuel de vos systèmes. Il est tout à fait possible que, par le passé, vos systèmes étaient dans un état vulnérable et auraient pu faire l'objet d'abus.

Quelque chose qui se présente ici est définitivement une grande priorité à corriger, mais cela ne se produit pas. ne pas vous échapper pour appliquer des mises à jour et changer toutes vos clés.


3



Je viens de recevoir un email de Snapt, le leur. BOLO (Être à l'affut) ! - Jacob


Amazon Linux (distribution Linux utilisée dans Amazon EC2)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

Aperçu du problème: Une vérification des limites manquante a été trouvée dans la manière dont OpenSSL a traité les paquets d'extension de pulsation TLS. Cette faille pourrait être utilisée pour révéler jusqu'à 64 ko de mémoire d'un client ou d'un serveur connecté.

Versions concernées: Toute AMI Amazon Linux sur laquelle openssl 1.0.1 est installée, qu'il s'agisse d'un Amazon Linux AMI 2013.03 ou version ultérieure ou de toute AMI Amazon Linux mise à niveau vers 2013.03 ou une version ultérieure. OpenSSL est installé par défaut sur l'AMI Amazon Linux.

Paquets concernés: openssl

Correction du problème: Exécutez yum update openssl pour mettre à jour votre système. Une fois le nouveau package installé, il est nécessaire de redémarrer manuellement tous les services utilisant openssl ou de redémarrer votre instance. Bien que le nouveau package porte toujours le nom openssl-1.0.1e, il contient le correctif de CVE-2014-0160.

Nouveaux forfaits: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64

2