Heartbleed: Qu'est-ce que c'est et quelles sont les options pour l'atténuer?

Question

Il s'agit d'une Question canonique sur la compréhension et la résolution du 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 pour 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 craindre que mes clés ou autres données privées aient été compromises? Quels autres effets secondaires dois-je craindre?

EEAA · Answer

Tout d'abord , avant de paniquer, assurez-vous de comprendre si cette vulnérabilité s'applique réellement à vous. Si vous avez un serveur, mais que vous n'avez jamais eu réellement d'applications utilisant TLS, ce n'est pas une chose prioritaire à corriger. Si, d'un autre côté, vous avez déjà eu des applications compatibles TLS, eh bien, vous êtes dans un régal. Continuer à lire:

Qu'est-ce que CVE-2014-0160 alias "Heartbleed"?

C'est un gros bordel, c'est ce que c'est. En bref, une vulnérabilité exploitable à distance a été découverte dans les versions d'OpenSSL 1.0.1 à 1.0.1f à travers laquelle un attaquant peut lire certaines parties de la mémoire système. Ces parties étant celles qui contiennent des données sensibles telles que les clés privées, les clés prépartagées, les mots de passe et les 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 la société finlandaise de tests de sécurité informatique Codenomicon (2 avril 2014).

Quelle est la cause?

Eh bien, le 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 bug est apparu en décembre 2011 et a été corrigé aujourd'hui, le 7 avril 2014.

Le bogue peut également être considéré comme le symptôme d'un problème plus important. 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. Le point (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, l'analyse et l'analyse de code. Le point (2) est en cours de discussion sur le GT TLS de l'IETF. Voir Heartbleed/complexité du protocole .

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

Je ne vais pas spéculer sur le fait que ce soit vraiment une erreur ou peut-être un peu de code glissé au nom d'un mauvais acteur. Cependant, la personne qui a développé le code pour OpenSSL déclare que c'était par inadvertance. Voir n homme qui a introduit une faille de sécurité "Heartbleed" sérieuse nie l'avoir insérée 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 qui utilise ou 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?

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

Il y a des preuves que Heartbleed était activement exploité dans la nature dès novembre 2013. Voir les EFF Wild at Heart: Were Intelligence Agencies Using Heartbleed in November 2013? Et Bloomberg rapporte le NSA avait armé l'exploit peu de temps après l'introduction de la vulnérabilité. Voir NSA a dit d'exploiter Heartbleed Bug for Intelligence pendant des années . Cependant, la US Intelligence Community nie les affirmations de Bloomberg. Voir IC SUR LE DOSSIER .

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, alors vous ne pouvez probablement pas déterminer la version d'OpenSSL en raison de l'application de correctifs à l'aide de la commande openssl ou des informations sur le package (par exemple, apt-get, dpkg, yum ou rpm). Le processus de correction arrière utilisé par la plupart des distributions (toutes?) Utilise uniquement le numéro de version de base (par exemple, "1.0.1e"); et est-ce que pas inclut une version de sécurité efficace (par exemple, "1.0.1g").

Il y a une question ouverte sur Super User pour déterminer la version de sécurité efficace pour OpenSSL et d'autres packages lorsque les packages sont backpatch. Malheureusement, il n'y a pas de réponses utiles (à part vérifier le site Web de la distribution). Voir Déterminer la version de sécurité efficace face au backpatching ?.

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

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

Dans les heures qui ont suivi l'annonce de Heartbleed, plusieurs personnes sur Internet avaient rendu public des applications Web accessibles au public qui pourraient être utilisées pour vérifier la présence de cette vulnérabilité sur un serveur. Au moment d'écrire ces lignes, je n'en ai pas examiné, donc je ne ferai plus de publicité sur leurs candidatures. 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?

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

Corrigez les systèmes vulnérables.
Régénérez de nouvelles clés privées.
Soumettez un nouveau CSR à votre CA.
Obtenez et installez un nouveau certificat signé.
Clés de session et cookies invalides
Réinitialiser les mots de passe et les secrets partagés
Révoquer les anciens certificats.

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

Dois-je craindre que mes clés ou autres données privées aient été compromises? Quels autres effets secondaires dois-je craindre?

Absolument. Les administrateurs système doivent supposer que leurs serveurs qui utilisaient des versions OpenSSL vulnérables sont en effet compromis et répondent en conséquence.

Peu de temps après la révélation de la vulnérabilité, Cloudfare a offert un défi pour voir 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 à Chronologie de divulgation Heartbleed: qui savait quoi et quand .

Si vous êtes un programmeur et que vous êtes intéressé par diverses astuces de programmation comme la détection d'une attaque Heartbleed via le rappel msg_cb D'OpenSSL, alors consultez OpenSSL Security Advisory 2014047 .

200_success · Answer

Une explication simple du bug, par XKCD:

Nathan Osman · Answer

Ubuntu 12.04, 12.10 et 13.10

Ubuntu a publié SN-2165-1 , qui indique que les packages mis à jour sont désormais 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 mis en place à cet effet. Ces trois commandes ajouteront mon PPA à votre système, mettront à jour la liste des packages disponibles et mettront à niveau tout:

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

_{Remarque: le PPA fournit également des packages pour Ubuntu 12.04 et 13.10, juste au cas où vous préféreriez réellement exécuter la nouvelle version (1.0.1g) au lieu d'utiliser simplement les versions corrigées dans les archives.}

Ubuntu 10.04

Il s'agit d'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 a atteint la fin de sa durée 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 vous attendez pas. Il a déjà atteint la fin de sa durée de vie et ne reçoit plus de mises à jour de sécurité. Il aurait dû être amélioré depuis longtemps. Si quelqu'un l'utilise encore, veuillez le mettre à jour maintenant, soit à partir de zéro, soit il peut être mis à niveau de manière non destructive vers 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 patch Heartbleed à partir 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, exécutez openssl version -a et assurez-vous que la date de construction est le 7 avril 2014 ou une version ultérieure, mais voir plus ici .

Redémarrer

La meilleure façon de vous assurer que tous les services dépendant d'OpenSSL sont redémarrés est de reboot .

MadHatter · Answer

RedHat 6.5 et CentOS 6.5

Ce sont vulnérables. Erratum RHSA-2014-0376 de RedHat indique qu'il existe des bibliothèques corrigées disponibles, et que toute personne affectée doit effectuer la mise à niveau dès que possible.

Au moment d'écrire ces lignes, CentOS n'avait pas encore de version fixe, mais la publication de Karanbir Singh sur CentOS-annonce dit qu'ils ont produit une version mise à jour de openssl (openssl-1.0.1e-16.el6_5.4.0.1, notez les quatre derniers chiffres qui sont importants) qui a la commande TLS exploitable désactivée, et qui peut être appliquée en toute sécurité car elle sera écrasée par une version fixe lorsqu'elle sera finalement publiée.

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

Edit : comme le dit Iain, il semble maintenant y avoir une version entièrement corrigée pour C6.5, et elle semble avoir été repoussée dans les miroirs pressé. Une ligne droite yum update l'a obtenu pour mes serveurs; c'est 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'a pas affecté les versions d'openssl fournies avec Red Hat Enterprise Linux 5 et Red Hat Enterprise Linux 6.4 et versions antérieures.

la publication de Karanbir Singh sur CentOS-annonce est tout aussi clair sur le versioning:

Plus tôt dans la journée d'aujourd'hui, nous avons été informés d'un problème grave dans openssl tel qu'il était expédié dans CentOS-6.5

jacksoncage · Answer

Debian Wheezy

Debian a publié DSA-2896-1 et les bibliothèques corrigées sont disponibles ici . Un script Shell est disponible ici .

1. Patch

Le référentiel Apt-get a été mis à jour. Les bibliothèques corrigées sont désormais 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érifier la version d'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

Ouki · Answer

FreeBSD 10.0 ou openssl à partir des ports

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

Mise à jour de FreeBSD
- Mettre à jour FreeBSD via un patch binaire
  
  Systèmes exécutant une version RELEASE de FreeBSD sur le i386 ou Les plates-formes AMD64 peuvent être mises à jour via l'utilitaire freebsd-update (8):
```
# freebsd-update fetch # freebsd-update install 
```
- Mettre à jour FreeBSD à partir des sources
Mettez à jour le port openssl avec la version minimale 1.0.1_10
Redémarrez tous les démons à l'aide de la bibliothèque ou redémarrez le système
Agissez comme si votre système était compromis, réémettez toutes vos clés SSL et/ou certificats et les informations potentiellement divulguées (voir [~ # ~] eeaa [~ # ~] réponse plus générale) .

FreeBSD 9.x et FreeBSD 8.x

Ces systèmes ne sont pas vulnérables au problème Heartbleed par défaut, car ils reposent sur une ancienne version 0.9.x du = openssl bibliothèque, sauf si vous avez installé openssl depuis les ports (voir à l'étage).

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

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

Remarque :

L'avis original Heartbleed répertorie FreeBSD 8.4 et 9.1 comme étant potentiellement vulnérable. Ce n'est pas vrai en raison de l'absence de Extension Heartbeat (la bibliothèque OpenBSL FreeBSD par défaut étant la version 0.9.x).

200_success · Answer

Je voudrais souligner que les clés privées ne sont pas les seuls actifs à considérer comme compromis. Le bogue a le potentiel de fuir n'importe quel mémoire s'exécutant dans le même espace d'adressage (c'est-à-dire le même processus) qu'OpenSSL. Par conséquent, si vous exécutez un processus serveur où une version vulnérable d'OpenSSL est liée statiquement ou dynamiquement, toute information que ce processus a jamais gérée, y compris les mots de passe, les numéros de carte de crédit et d'autres données personnelles , doit être considéré comme potentiellement compromis.

Tim Brigham · Answer

J'ai trouvé quasiment impossible de déterminer les versions de SSL utilisées sur plusieurs des appareils avec lesquels je travaille. Bien qu'il ne s'agisse techniquement pas d'atténuation, la possibilité d'identifier les hôtes actuellement vulnérables était en haut de ma liste.

J'ai mis en place un petit VM qui effectuera des vérifications contre des hôtes et des ports arbitraires en utilisant module de test de FiloSottile . À première vue, le code semble sain.

La version finale VM est ici . Elle est au format VMX.

Mots d'avertissement

Ce script et VM affichera seulement afficher l'état actuel de vos systèmes. Il est tout à fait possible qu'à un certain moment dans le passé, vos systèmes étaient dans un état vulnérable et auraient pu être maltraités.

Quelque chose qui apparaît ici est certainement une priorité élevée à corriger, mais cela ne fait pas vous libérer du crochet pour appliquer les mises à jour et changer toutes vos clés.

Garreth McDaid · Answer

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

https://aws.Amazon.com/Amazon-linux-AMI/security-bulletins/ALAS-2014-320/

Présentation du problème: Une vérification des limites manquantes a été trouvée dans la façon 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 à partir d'un client ou serveur connecté.

Versions concernées: Toute Amazon Linux AMI sur laquelle openssl 1.0.1 est installée, qui est toute Amazon Linux AMI 2013.03 ou ultérieure, et toute Amazon Linux AMI qui a mis à niveau vers 2013.03 ou version ultérieure. OpenSSL est installé par défaut sur l'AMI Amazon Linux.

Packages concernés: openssl

Correction de problème: exécutez yum update openssl pour mettre à jour votre système. Une fois le nouveau package installé, vous devez soit redémarrer manuellement tous les services utilisant openssl, soit redémarrer votre instance. Bien que le nouveau package soit toujours nommé openssl-1.0.1e, il contient le correctif pour CVE-2014-0160.

Nouveaux packages: 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