web-dev-qa-db-fra.com

La vulnérabilité Heartbleed affecte-t-elle les clients aussi gravement?

Si j'ai un robot d'exploration Web (utilisant une version non corrigée d'OpenSSL) qui peut être cajolé pour se connecter à un site https maléfique, peut-il tout récupérer de ma mémoire de processus? Pour attaquer un serveur, vous pouvez continuer à vous reconnecter pour obtenir plus de blocs de 64 Ko (si je comprends bien), mais un client peut-il être forcé de se reconnecter plusieurs fois, pour obtenir plus de blocs?

opensslheartbleed
61
Gurgeh

Oui, les clients sont vulnérables aux attaques.

Les avis de sécurité initiaux indiquaient qu'un serveur malveillant pouvait utiliser la vulnérabilité Heartbleed pour compromettre un client affecté. Sources ci-dessous (toute emphase est sur moi).

Depuis lors, preuve de concept les attaques ont validé cette position - il est tout à fait certain que les clients exécutant des applications qui utilisent OpenSSL pour les connexions TLS peuvent être vulnérables.

heartbleed.com :

... Lorsque [Heartbleed] est exploité, il entraîne une fuite du contenu de la mémoire du serveur vers le client et du client au serveur .

Avis de sécurité Ubuntu USN-2165-1 :

Un attaquant pourrait utiliser ce problème pour obtenir jusqu'à 64 Ko de contenu mémoire à partir du client ou du serveur

RFC652 :

5. Cas d'utilisation
Chaque point de terminaison envoie des messages HeartbeatRequest ...

Avis de sécurité OpenSSL du 07 avril 2014 :

Une vérification des limites manquantes dans la gestion de l'extension de pulsation TLS peut être utilisée pour révéler jusqu'à 64 Ko de mémoire à un client ou serveur connecté .

Applications clientes signaléespour être vulnérables (crédit à @ Lekensteyn sauf indication contraire):

  • MariaDB 5.5.36
  • wget 1.15 (fuite de mémoire des connexions antérieures et de son propre état)
  • curl 7.36.0
  • git 1.9.1 (clone/Push testé, fuites peu)
  • nginx 1.4.7 (en mode proxy, fuit la mémoire des requêtes précédentes)
  • liens 2.8 (fuit le contenu des visites précédentes!)
  • Toutes les applications KDE utilisant KIO (Dolphin, Konqueror).
  • Serveur de messagerie Exim
  • OwnCloud Version inconnue | Source

Notez que certains de ces programmes utilisent pas utilisent OpenSSL. Par exemple, curl peut être construit avec Mozilla NSS et Exim peut être construit avec GnuTLS (comme cela se fait sur Debian).

Autres clients communs:

  • Windows (toutes les versions): Probablement non affecté ( tilise SChannel/SSPI ), mais il convient de prêter attention aux implémentations TLS dans les applications individuelles. Par exemple, les utilisateurs de Cygwin doivent mettre à jour leurs packages OpenSSL .

  • OSX et iOS (toutes les versions): probablement pas affecté. SANS implique il peut être vulnérable en disant " OS X Mavericks n'a AUCUN PATCH disponible ", maisautresnote que OSX 10.9 est livré avec OpenSSL 0.9.8y, qui n'est pas affecté. Apple dit : "Les bibliothèques OpenSSL dans OS X sont obsolètes, et OpenSSL n'a jamais été fourni dans le cadre d'iOS")

  • Chrome (toutes les plateformes sauf Android): Probablement non affecté ( tilise NSS )

  • Chrome sur Android: 4.1.1 peut être affecté ( tilise OpenSSL ). Source. 4.1.2 ne devrait pas être affecté, car il est compilé avec battements de cœur désactivés . Source.
  • Produits Mozilla (par exemple Firefox, Thunderbird, SeaMonkey, Fennec): Probablement non affectés, tous utilisent NSS
50
scuzzy-delta

Oui, cela affecte les clients aussi sévèrement, comme indiqué sur le site Web Heartbleed:

De plus, vous pourriez avoir un logiciel côté client sur votre ordinateur qui pourrait exposer les données de votre ordinateur si vous vous connectez à des services compromis.

Bien sûr, et ce n'est pas seulement le cas pour cette vulnérabilité ou pour un client particulier, le client a toujours pour initier la connexion pour être attaqué. En aucun cas, cette vulnérabilité ne permet à un attaquant d'établir une connexion avec votre robot d'exploration Web et d'exploiter la vulnérabilité.

Dans votre cas cependant, comme vous avez un contrôle direct sur le code client OpenSSL (et je suppose que c'est le cas en fonction de votre publication), vous voulez vous assurer que votre version d'OpenSSL ne vient pas avec l'option Heartbeat, et si il le fait, pour le supprimer. Pour ce faire, vous pouvez:

  • afficher les options spécifiques utilisées pour compiler votre version d'OpenSSL:

    openssl version -o

  • ou afficher toutes les informations de votre version OpenSSL:

    openssl version -a

  • compilez OpenSSL sans le support Heartbeat, en utilisant simplement cet indicateur au moment de la compilation:

    -DOPENSSL_NO_HEARTBEATS

Une fois cela fait, ou si votre version d'OpenSSL ne l'incluait pas initialement, alors vous n'êtes plus vulnérable.

Edit: Une autre méthode consiste à récupérer votre version d'OpenSSL avec:

openssl version

Et comparez-le à la liste des versions affectées disponibles sur heartbleed :

  • OpenSSL 1.0.1 à 1.0.1f (inclus) sont vulnérables
  • OpenSSL 1.0.1g n'est [~ # ~] pas [~ # ~] vulnérable
  • La branche OpenSSL 1.0.0 est [~ # ~] pas [~ # ~] vulnérable
  • La branche OpenSSL 0.9.8 est [~ # ~] non [~ # ~] vulnérable
9
ack__