Heartbleed: des services autres que HTTPS sont-ils concernés?


65

La vulnérabilité «heartbleed» d’OpenSSL ( CVE-2014-0160 ) affecte les serveurs Web servant le protocole HTTPS. D'autres services utilisent également OpenSSL. Ces services sont-ils également vulnérables aux fuites de données analogues à celles du cœur

Je pense en particulier à

  • sshd
  • sécurisé SMTP, IMAP, etc. - pigeonnier, exim et postfix
  • Serveurs VPN - OpenVPN et amis

qui, sur mes systèmes au moins, sont liés aux bibliothèques OpenSSL.


Correction pour Ubuntu: apt-get update && apt-get install openssl libssl1.0.0 && service nginx restart; puis
réémettez

Utilisez cet outil pour détecter les hôtes vulnérables: github.com/titanous/heartbleeder
Homer6

1
apt-get updatedevrait être suffisant pour Ubuntu maintenant sans rétrograder, le correctif est apparu dans le référentiel principal hier soir.
Jason C

10
apt-get update n'est pas suffisant. update ne montre que les dernières modifications, apt-get UPGRADE sera appliqué après la mise à jour.
Sjakubowski

1
Je suis sûr que c'est ce que @JasonC voulait dire, mais +1 pour le rendre clairement explicite.
Craig

Réponses:


40

Tout service utilisant OpenSSL pour sa mise en œuvre TLS est potentiellement vulnérable. Il s'agit d'une faiblesse de la bibliothèque de cryptographie sous-jacente, et non de la manière dont elle est présentée via un serveur Web ou un package de serveur de messagerie. Vous devez au moins considérer tous les services liés vulnérables à la fuite de données .

Comme vous le savez sans doute, il est tout à fait possible d'enchaîner les attaques. Même dans les il est parfaitement possible les attaques les plus simples, par exemple, utiliser heartbleed pour compromettre SSL, lire les informations d' identification webmail, utilisez les informations d' identification de webmail pour accéder à d' autres systèmes avec un rapide « help desk Cher, pouvez - vous me donner un nouveau mot de passe pour foo $, amour PDG " .

Il y a plus d'informations et de liens dans The Heartbleed Bug , et dans une autre question posée par un habitué de Server Fault, Heartbleed: Qu'est-ce que c'est et quelles sont les options pour l'atténuer? .


3
"C’est une faiblesse du système sous-jacent, pas de la façon dont elle est présentée via un système de niveau supérieur tel que SSL / TLS" - Non, c’est faux. C'est une faiblesse dans la mise en œuvre de l'extension de pulsation TLS. Si vous n'utilisez jamais TLS, vous êtes en sécurité. Je conviens avec votre conclusion, cependant, que vous devez faire très attention dans votre analyse de ce qui pourrait être affecté par des attaques chaînées.
Perséides

6
@ Perseids, vous avez raison bien sûr. J'essayais de trouver un moyen facilement compréhensible de dire que les gens ne sont pas en sécurité car ils utilisent cette version du serveur Web X ou cette version du serveur SMTP Y. Je fais une modification j'espère que cela améliorera les choses, alors merci de l'avoir signalé.
Rob Moir

35

Il semble que vos clés ssh sont en sécurité:

Il convient de souligner qu'OpenSSH n'est pas affecté par le bogue OpenSSL. Bien que OpenSSH utilise openssl pour certaines fonctions de génération de clé, il n’utilise pas le protocole TLS (et en particulier l’extension de pulsation TLS attaquée par heartbleed). Vous n'avez donc pas à craindre de compromettre SSH, bien que ce soit toujours une bonne idée de mettre OpenSL à jour vers 1.0.1g ou 1.0.2-beta2 (mais vous n'avez pas à vous soucier de remplacer les paires de clés SSH). - dr jimbob Il y a 6 heures

Voir: https://security.stackexchange.com/questions/55076/what-should-one-do-about-the-heartbleed-openssl-exploit


N'est-il pas indirectement affecté comme l'a déclaré @RobM? Quelqu'un lit le mot de passe de root dans la mémoire à l'aide de la vulnérabilité Heartbleed, obtient tout accès non-SSH au système, puis vole le contenu SSH.
Thomas Weller

1
Vous ne pouvez pas lire 64k de mémoire avec ce bogue, seulement 64k près du lieu où le paquet entrant est stocké. Malheureusement, de nombreux goodies ont tendance à y être stockés, tels que des requêtes HTTP déchiffrées avec des mots de passe en texte clair, des clés privées et des images de chatons.
Lars

4

En plus de la réponse de @RobM, et puisque vous posez des questions sur SMTP en particulier: il existe déjà un PoC pour exploiter le bogue sur SMTP: https://gist.github.com/takeshixx/10107280


4
Plus précisément, il exploite la connexion TLS établie après la commande "starttls", si je lis correctement le code.
Perséides

3

Oui, ces services peuvent être compromis s’ils reposent sur OpenSSL

OpenSSL est utilisé pour protéger, par exemple, les serveurs de messagerie (protocoles SMTP, POP et IMAP), les serveurs de discussion (protocole XMPP), les réseaux privés virtuels (VPN SSL), les appliances réseau et une grande variété de logiciels côté client.

Pour une description plus détaillée des vulnérabilités, des systèmes d'exploitation affectés, etc., vous pouvez consulter http://heartbleed.com/


3

Tout ce qui est lié à libssl.sopeut être affecté. Vous devez redémarrer tout service lié à OpenSSL après la mise à niveau.

# lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | grep libssl | sort -u
bacula-fd: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/php/modules/openssl.so
python2: /usr/lib/libssl.so.1.0.0
python2: /usr/lib/python2.7/lib-dynload/_ssl.so
python: /usr/lib/libssl.so.1.0.0
ruby-timer-thr: /usr/lib/libssl.so.1.0.0
ruby: /usr/lib/libssl.so.1.0.0

Avec l'aimable autorisation d'Anatol Pomozov de la liste de diffusion Arch Linux .


2
Tout ce qui est lié à libssl et utilise TLS. Openssh utilise openssl mais n'utilise pas TLS, il n'est donc pas affecté.
StasM

2
@StasM C'est pourquoi j'ai écrit peut être affecté , n'est pas affecté . De plus, le serveur OpenSSH ne se lie PAS du tout à OpenSSL. Des utilitaires comme ssh-keygen le font, mais ils ne sont pas utilisés par le serveur OpenSSH lui-même. Ce qui est clairement visible dans la sortie lsof que j'ai fournie - OpenSSH n'y est pas répertorié, bien qu'il soit exécuté sur le serveur.
Nowaker

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.