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

Tout d’abord , avant de paniquer, assurez-vous de bien comprendre si cette vulnérabilité s’applique ou non à vous. 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 avez déjà eu des applications compatibles TLS, alors vous êtes prêt à vous régaler. 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 la société finlandaise de tests de sécurité informatique Codenomicon (2 avril 2014).

Quelle est la cause?

Eh bien, code errant dans OpenSSL. Voici le commit qui a introduit la vulnérabilité, et voici 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 s'il s'agissait vraiment d'une erreur ou éventuellement d'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. See Man qui a introduit une grave faille de sécurité 'Heartbleed' 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 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 connu 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 Wild at Heart de l'EFF : les agences de renseignement ont-elles utilisé 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 NSA dit avoir exploité Heartbleed Bug pour l'intelligence pendant des années . Cependant, les services de renseignement américains nient les affirmations de Bloomberg. Voir IC ON THE RECORD .

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

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

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Si la distribution maintient OpenSSL, vous pouvez probablement pas déterminer la version d'OpenSSL en raison de revenir rapiéçage en utilisant la opensslcommande ou les informations de package (par exemple, apt-get, dpkg, yumou rpm). Le processus de correction en arrière utilisé par la plupart des distributions (toutes?) Utilise uniquement le numéro de version de base (par exemple, "1.0.1e"); et n'inclut pas une version de sécurité effective (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étermination de la version de sécurité effective en cas de 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 avaient annoncé des applications Web accessibles au public, censées permettre de 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?

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

1. Corrigez les systèmes vulnérables.
2. Régénérez de nouvelles clés privées.
3. Soumettez un nouveau CSR à votre autorité de certification.
4. Obtenez et installez le 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 devrait 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é compromises? Quels autres effets secondaires devrais-je m'inquiéter?

Absolument. Les administrateurs système doivent supposer 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:

• OpenSSL SECADV 2014047
• CVE-2014-0160
• Heartbleed
• Annonce Ubuntu
• Annonce RHEL
• Annonce officielle OpenSSL

Une chronologie assez détaillée des événements de divulgation peut être trouvée dans Chronologie 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 le msg_cbrappel OpenSSL , consultez l' Avis de sécurité 2014047 d'OpenSSL .

Une explication simple du bogue, par XKCD:

Ubuntu 12.04, 12.10 et 13.10

Ubuntu a publié le document USN-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 configuré à cette fin. Ces trois commandes vont ajouter my PPA à votre système, mettre à jour la liste des packages disponibles et tout mettre à niveau:

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 sa 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 avait 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 effectuer la mise à niveau maintenant, soit à partir de zéro, soit par une mise à niveau non destructive en 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 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é

Pour l’essentiel, exécutez openssl version -aet assurez-vous que la date de compilation est le 7 avril 2014 ou plus tard, mais voyez-en plus ici .

Redémarrage

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

RedHat 6.5 et CentOS 6.5

Ce sont vulnérables. L'erratum RHSA-2014-0376 de RedHat indique qu'il existe des bibliothèques corrigées disponibles, et que toute personne concernée doit effectuer la mise à niveau à la première occasion.

Au moment de la rédaction, CentOS n’avait pas encore de version corrigée, mais l’affichage de Karanbir Singh sur CentOS-advert indique qu’ils ont produit une version mise à jour de openssl ( openssl-1.0.1e-16.el6_5.4.0.1notez les quatre derniers chiffres, qui sont importants) et qui contient le TLS exploitable. Cette commande est désactivée et peut être appliquée en toute sécurité car elle sera écrasée par une version corrigée lors de sa publication.

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

Edit : comme le dit Iain, il semble qu’il existe maintenant une version entièrement corrigée pour C6.5, qui semble avoir été rapidement déplacée autour des miroirs. Une quinte l'a yum updateeu 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'affectait pas les versions de 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-annonc est tout aussi claire à propos du versioning:

Plus tôt dans la journée, nous avons été informés d'un problème grave sous openssl, tel que livré dans CentOS-6.5.

Debian Wheezy

Debian a publié le DSA-2896-1 et des 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 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 serveur / services

Pour une meilleure protection, redémarrez tout le serveur 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

J'aimerais souligner que les clés privées ne sont pas les seuls actifs qui doivent être considérés comme compromis. Le bogue risque de laisser fuir toute mémoire s'exécutant 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, toute information déjà traitée par ce processus , y compris les mots de passe, les numéros de carte de crédit et d'autres données personnelles, doit être considérée comme potentiellement compromise.

FreeBSD 10.0 ou openssl depuis les ports

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

     Les systèmes exécutant une version RELEASE de FreeBSD sur les plates-formes i386 ou amd64 peuvent être mis à 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 approprié à partir de l'emplacement ci-dessous et vérifiez la 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 buildworld et installworld comme décrit dans le manuel de FreeBSD .

2. Mettre à jour le port openssl avec la 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 la réponse plus générale de l' EEAA ).

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 version 0.9.x plus ancienne de la bibliothèque openssl , à moins que vous n'ayez installé openssl à partir des ports (voir ci-dessus).

Si ces systèmes ne sont pas vulnérables au problème Heartbleed , il pourrait être judicieux de mettre votre système à niveau le plus tôt possible 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 peut-être espionner un processus de signature et pourrait récupérer la clé de signature à partir de celui-ci. [CVE-2014-0076]

Note :

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

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 contrôles sur des hôtes et des ports arbitraires à l'aide du module de test de FiloSottile . Au premier coup d’œil, le code semble solide.

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

Mots d'avertissement

Ce script et cette machine virtuelle afficheront uniquement l'état 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 priorité majeure à réparer, mais cela ne vous empêche pas d’appliquer des mises à jour et de modifier toutes vos clés.

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 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'à 64k 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'une 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