Informations importantes concernant la vulnérabilité DROWN - CVE-2016-0800

Red Hat Product Security a découvert une vulnérabilité dans le protocole SSLv2. Cette vulnérabilité s'est vue attribuer CVE-2016-0800 et est utilisée dans des attaques sur différents protocoles intitulées DROWN (Decrypting RSA using Obsolete and Weakened eNcryption).

Vue d'ensemble

Un groupe de chercheurs en sécurité a découvert que SSLv2 (Secure Sockets Layer protocol version 2.0) est vulnérable à l'attaque d'oracle de remplissage RSA Bleichenbacher, qui peut être utilisée pour déchiffrer le message codé de RSA sans avoir à connaître la clé RSA privée correspondante. Cela est possible en observant les réponses d'un serveur possédant la clé privée et effectuant le déchiffrage des messages codés fournis par la personne malveillante à l'aide de cette clé. Les chercheurs ont également démontré une nouvelle attaque sur différents protocoles permettant un déchiffrage des sessions SSL/TLS à l'aide de versions de protocoles plus récentes (SSLv3 ou toute version de TLS (Transport Layer Security) actuelle (1.0 - 1.2)) en utilisant ce défaut SSLv2. Ce défaut est un incident de protocole SSLv2 et affecte toutes les implémentations du protocole. Les chercheurs appellent cette attaque general DROWN.

De plus, des défauts ont été trouvés dans la mise en œuvre du protocole SSLv2 dans le déchiffrage OpenSSL et la bibliothèque SSL/TLS, ce qui permet d'effectuer une variante de l'attaque DROWN plus efficace, intitulée special DROWN. Ces incidents se sont vues attribuer CVE-2016-0703 et CVE-2016-0704 et ont déjà été récemment corrigés dans le cadre du correctif pour CVE-2015-0293.

Davantage d'informations sur cette attaque peuvent être trouvées dans les documents des chercheurs intitulés DROWN: Breaking TLS using SSLv2.

Arrière-plan

Le protocole SSLv2 présente des problèmes de sécurité connus et est considéré comme non sécurisé depuis que sa nouvelle version, SSLv3, a été republiée en 1996. Il a également été rendu obsolète en 2011 avec RFC 6176. Son utilisation sur Internet est aujourd'hui limitée, puisque les clients SSL/TLS modernes ne prennent pas en charge cette version de protocole ou utilisent une version plus récente lorsque cela est possible. Cependant, ce protocole est toujours compatible avec beaucoup de serveurs SSL/TLS. De tels paramètres permettent même à d'anciens clients de se connecter. Avant la publication de l'attaque DROWN, il n'existait aucune menace connue pour la sécurité des connexions à partir de clients prenant en charge des versions de protocole plus récents.

Configurations touchées par l'attaque DROWN

Un serveur est vulnérable à l'attaque DROWN s'il active le protocole SSLv2 en plus de SSLv3 ou TLSv1.x et s'il utilise les suites cryptographiques d'échange de clés RSA. Un serveur n'activant pas SSLv2 peut également être vulnérable s'il partage sa clé RSA privée avec un autre serveur ou service sur lequel SSLv2 est activé. Par exemple, l'attaque DROWN peut toujours être utilisée pour déchiffrer les sessions HTTPS sur un serveur web n'activant pas SSLv2 s'il partage sa clé RSA avec, par exemple, un serveur IMAP, en exécution sur le même hôte, activant SSLv2. L'utilisation de cryptages SSLv2 faibles ou d'exportation est requise pour effectuer l'attaque de manière efficace.

Les connexions SSL/TLS utilisant un échange de clés non RSA, tel que Diffie-Hellman ou Elliptic Curve Diffie-Hellman, ne peut être déchiffré à l'aide de l'attaque DROWN.

Description et impact de l'attaque

L'attaque DROWN décrite par les chercheurs comprend les étapes suivantes :

• Une personne malveillante doit tout d'abord enregistrer un certain nombre de sessions SSL/TLS entre un client et un serveur à l'aide de toute version du protocole et de suites de déchiffrement RSA. L'une de ces sessions d'enregistrement sera déchiffrée. Les chercheurs indiquent qu'environ 1 000 sessions suffisent pour cette attaque.

• Ensuite, la personne malveillante ouvre plusieurs connexions SSLv2 sur le serveur. Pour certaines de ces connexions, la personne malveillante doit forcer une clé de session de 40 bits (si l'un des cryptages SSLv2 EXPORT peut être utilisé) ou 56 bits (pour une suite de cryptage utilisant DES). Les chercheurs estiment qu'environ 40 000 connexions sont nécessaires.

• Ensuite, la personne malveillante peut décrypter les données "premaster secret" à partir de l'une des liaisons précédemment enregistrées. Ces données sont utilisées pour générer des clés de session symétriques et donc décrypter la session SSL/TLS enregistrée entièrement. Des données sensibles supplémentaires peuvent être obtenues à partir de la session décryptée, telles que des informations d'identification ou des cookies.

Les chercheurs indiquent qu'ils ont su décrypter une liaison TLS 1.2 avec un serveur utilisant des clés RSA 2048 bits à l'aide de 1 000 liaisons enregistrées, 40 000 connexions SSLv2 et 2⁵⁰ offline computations. Leur attaque a duré moins de 8 heures grâce aux ressources d'un fournisseur de cloud public pour un coût de 440 USD.

Ils indiquent également que l'utilisation de l'attaque special DROWN réduit le nombre de connexions SSLv2 à 14 000 et peut être effectuée à l'aide d'un poste de travail unique en moins de 3 minutes. Cela permet d'utiliser ce flux pour effectuer une attaque « man-in-the-middle » (MITM) et imiter un serveur TLS pour connecter le client TLS.

Bibliothèques SSL et TLS avec support SSLv2

Les produits Red Hat incluent les composants suivants mettant en œuvre le support pour le protocole SSLv2. Ce support peut être activé selon la façon dont les applications utilisent ces bibliothèques SSL/TLS.

SSLv2 dans OpenSSL

Les applications utilisant OpenSSL doivent sélectionner une méthode de connexion pour informer la bibliothèque des versions du protocole SSL/TLS qu'elles souhaitent utiliser. Les méthodes de connexion OpenSSL activent une version de protocole unique, ou la méthode spéciale "SSLv23" peut être utilisée pour activer toutes les versions de protocole prises en charge par la bibliothèque. Cette méthode de connexion est la plus courante. Le protocole SSLv2 est automatiquement activé lorsque cette méthode est sélectionnée. Les applications doivent explicitement définir l'option "SSL_OP_NO_SSLv2" dans les objets "SSL_CTX" ou "SSL" correspondants pour désactiver SSLv2. Bien que beaucoup d'applications le font, de manière inconditionnelle ou selon leur configuration, d'autres applications utilisent l'ensemble par défaut des protocoles activés. Les applications utilisant la bilbiothèque OpenSSL peuvent donc exécuter avec SSLv2 d'activé.

Les modifications suivantes ont été appliquées à OpenSSL des produits Red Hat pour corriger cet incident :

• Le protocole SSLv2 n'est plus activé par défaut lors de l'utilisation de la méthode de connexion "SSLv23".
• Toutes les suites de cryptage SSLv2 utilisant des clés de chiffrage symétriques de 40 bits (EXPORT) ou 56 bit (single DES) sont désormaisn désactivées et ne sont plus utilisées. Les suites de cryptage suivantes ne sont plus disponibles :
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
• Les versions OpenSSL dans les paquets "openssl" dans toutes les mises à jour de Red Hat Enterprise Linux 4 et 5 vérifient maintenant la variable d'environnement "OPENSSL_ENABLE_SSL2" et si celle-ci est définie, SSLv2 sera activé par défaut lors de l'utilisation de la méthode de connexion "SSLv23". Cette variable d'environnement peut être utilisée pour réactiver SSLv2 le cas échéant.

La méthode de connexion "SSLv2" n'est pas affectée par le changement pour la méthode de connexion "SSLv23" et peut toujours être utilisée pour établir des connexions à l'aide du protocole SSLv2.

Veuillez également noter que bien que la liste de cryptage DEFAULT dans les versions OpenSSL telle que présente dans Red Hat Enterprise Linux 6 et 7 exclut toutes les suites de cryptage SSLv2, ce défaut n'empêche pas les serveurs d'accepter des connexions SSLv2 à partir de clients qui forcent l'utilisation d'une suite de cryptage désactivée. Cet incident s'est vu attribuer CVE-2015-3197 et est également corrigé dans les mises à jour corrigeant l'incident DROWN.

SSLv2 dans NSS (Network Security Services)

La bibliothèque de cryptographie NSS met en œuvre le protocole SSLv2, mais il ne l'active pas par défaut. Les applications doivent explicitement demander à la bibliothèque d'activer SSLv2 pour l'utiliser. Les version NSS contenues dans Red Hat Enterprise Linux 7 ne permettent pas l'activation du protocole SSLv2. Les applications utilisant la bibliothèque NSS ont peu de chance de s'exécuter avec SSLv2 d'activé.

Étant donné que la bibliothèque NSS n'active pas SSLv2 par défaut, aucune mise à jour immédiate n'est prévue pour corriger l'incident DROWN. Les prochaines mises à jour de Red Hat Enterprise Linux 6 devraient désactiver le protocole de manière similaire à Red Hat Enterprise Linux 7.

Bibliothèques SSL et TLS sans support SSLv2

Les produits Red Hat incluent les composants suivants mettant en œuvre des versions de protocole TLS ou SSL mais pas le support pour SSLv2. Ces composants ne sont donc pas affectés par cet incident. Veuillez noter que les applications utilisant ces bibliothèques non affectées peuvent tout de même être affectées par l'attaque DROWN si elles partagent leur clé privée RSA avec une autre application qui utilise une bibliothèque SSL/TLS prenant en charge SSLv2.

• GnuTLS
• OpenJDK (packages java-1.6.0-openjdk, java-1.7.0-openjdk, java-1.8.0-openjdk)
• Oracle JDK (packages java-1.6.0-sun, java-1.7.0-oracle, java-1.8.0-oracle)
• IBM JDK (packages java-1.6.0-ibm, java-1.7.0-ibm, java-1.7.1-ibm, java-1.8.0-ibm)

Résolution

Red Hat recommande aux clients d'effectuer une analyse des priorités basée sur les risques encourus par leurs systèmes affectés et d'appliquer immédiatement les correctifs disponibles pour remédier au problème. Réinitialiser le système après l'avoir mis à jour est la manière la plus sûre de vérifier que tous les services affectés utilisent la bibliothèque OpenSSL mise à jour. Si une réinitialisation n'est pas possible, le redémarrage de tous les services réseau qui dépendent d'OpenSSL après l'application des correctifs sera requis.

Remerciements

Red Hat remercie le projet OpenSSL d'avoir signalé ces incidents. Nimrod Aviram et Sebastian Schinzel sont reconnus en amont pour avoir signalé cet incident en premier.

Foire aux questions

Comment désactiver SSLv2 dans l'application X ?

Vous référer à l'article de base de connaissances Securing Application 'X' in RHEL 'Y' ? pour obtenir des informations sur la façon de modifier les paramètres relatifs à SSL/TLS, tels que les versions de protocole activées, dans diverses applications contenues dans différentes versions de Red Hat Enterprise Linux.

Doit-on générer à nouveau les clés ou certificats de serveurs suite à ce problème ?

Non. DROWN n'expose pas directement les clés RSA privées, mais cible les clés des sessions individuelles qui sont générées pendant les poignées de mains des connexions SSL/TLS et utilisées pour le chiffrement symétrique. Le compromis de ces clés permet le déchiffrement de sessions SSL/TLS spécifiques. Ainsi, même si un service est détecté comme étant vulnérable à une attaque DROWN, il n'est pas nécessaire de générer à nouveau une clé ou un certificat de service.

SSLv2 est-il activé dans les versions du serveur web httpd Apache contenu dans les produits Red Hat ?

Le serveur web httpd Apache peut utiliser l'un des modules suivants pour fournir un service HTTPS :

• mod_ssl - Ce module utilise la bibliothèque cryptographique OpenSSL et est inclu dans la distribution du serveur web httpd Apache.
• mod_nss - Ce module utilise la bibliothèque cryptographique NSS et est développé et distribué séparément du projet httpd Apache.

Ces deux modules sont inclus dans les produits Red Hat.

Les paramètres par défaut pour httpd en utilisant mod_sslsont :

• Les versions httpd contenues dans Red Hat Enterprise Linux 7, dans la collection httpd24 des collections de logiciels Red Hat et avec Red Hat JBoss Web Server 3, sont basées sur la version version 2.4 httpd en amont et ne peuvent être configurées pour activer le protocole SSLv2.

• Les versions httpd contenues dans Red Hat Enterprise Linux 5 et 6, Red Hat JBoss Web Server 1 et 2, et Red Hat JBoss Enterprise Application Platform 6 sont basées sur les versions 2.2 httpd en amont. Ces versions peuvent être configurées pour utiliser SSLv2, cependant ce protocole est désactivé dans la configuraiton par défaut. Le fichier de configuration /etc/httpd/conf.d/ssl.conf inclut la directive de configuration suivante désactivant SSLv2:

SSLProtocol all -SSLv2

• Les versions httpd contenues dans Red Hat Enterprise Linux 4 sont basées sur les versions 2.0 httpd en amont. La configuration par défaut active SSLv2, qui peut être désactivé en ajoutant la même directive SSLProtocol telle que listées ci-dessus sur le fichier de configuration /etc/httpd/conf.d/ssl.confet redémarrant le service httpd.

Les paramètres par défaut pour httpd en utilisant mod_nsssont :

• Les versions mod_nss contenues dans Red Hat Enterprise Linux 5, 6, et 7 n'activent pas SSLv2 par défaut. Le fichier de configuration /etc/httpd/conf.d/nss.confinclut, selon la version du paquet mod_nss, l'une des directives de configuration suivantes qui n'active que SSLv3 ou version supérieure, ou TLSv1.0 ou version supérieure :

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

NOTE : En raison de problèmes connus avec le protocole SSLv3, nous continuons de recommander que cette version soit également désactivée. Veuillez consulter l'article connexe POODLE: SSLv3 vulnerability (CVE-2014-3566) pour obtenir des détails et des instructions sur la manière de désactiver le protocole SSLv3 sur divers composants des produits Red Hat.

SSLv2 est-il activé dans les serveurs SMTP de courrier fournis avec Red Hat Enterprise Linux ?

Les configurations par défaut des serveurs de courrier Postfix et Sendmail sur Red Hat Enterprise Linux 5, 6, et 7 n'activent pas le chiffrement SSL/TLS.

Si un administrateur système active SSL/TLS dans Postfix, SSLv2 sera activé avec chiffrement opportun et le chiffrement obligatoire par défaut sera désactivé. Sur Red Hat Enterprise Linux 6 et 7, il est possible de désactiver SSLv2 avec chiffrement opportun en utilisant l'option de configuration « smtpd_tls_protocols ».

Si un administrateur système active SSL/TLS dans Sendmail, SSLv2 sera activé par défaut. Sur Red Hat Enterprise Linux 5, 6, et 7, il est possible de désactiver SSLv2 en utilisant l'option de configuration « ServerSSLOptions ».

Veuillez consulter la question ci-dessus « Comment désactiver SSLv2 dans l'application X ? » pour obtenir des liens vers des ressources supplémentaires sur la manière de configurer SSL/TLS dans Postfix et Sendmail.

Dois-je mettre à jour mon installation EAP 6.4 ?
EAP peut être configuré pour utiliser le fournisseur de chiffrement Java (JSSE) ou le fournisseur natif (APR/OpenSSL). Si vous utilisez le fournisseur Apr/OpenSSL, alors veuillez effectuer les étapes suivantes :

• Red Hat Enterprise Linux
  Mettre OpenSSL à niveau pour votre version.
• Windows ou Solaris
  Une mise à jour des bibliothèques openssl sera disponible sur la plateforme du service client. Cette mise à jour remplacera les bibliothèques libssl et libeay, ainsi que l'application openssl.

EAP 6.4 a été testé sur Windows en utilisant APR/OpenSSL et même si techniquement, la bibliothèque OpenSSL requiert une mise à jour, EAP 6.4 utilise TLSv1 par défaut et rejette les requêtes cipher pour SSLv2 et SSLv3. Actuellement, EAP ne devrait pas être vulnérable à cette défaillance.

Dois-je mettre à jour mon installation EAP 5.2 ?
EAP peut être configuré pour utiliser le fournisseur de chiffrement Java (JSSE) ou le fournisseur natif (APR/OpenSSL). Si vous utilisez le fournisseur Apr/OpenSSL, alors veuillez effectuer les étapes suivantes :

• Red Hat Enterprise Linux
  Mettre OpenSSL à niveau pour votre version.
• Windows ou Solaris
  Une mise à jour des bibliothèques openssl sera disponible sur la plateforme du service client. Cette mise à jour remplacera les bibliothèques libssl et libeay, ainsi que l'application openssl.

EAP 5.2 est actuellement testé sur Windows pour évaluer son niveau de vulnérabilité face à cette défaillance.

Dois-je mettre à jour mon installation EWS 2.1 ?
Cette défaillance affecte uniquement les installations Windows et Solaris où APR/OpenSSL a été configuré en tant que fournisseur de sécurité. Actuellement, EWS 2.1 prend en charge SSLv2 et SSLv3.
Si vous utilisez le fournisseur Apr/OpenSSL, vous devriez effectuer les étapes suivantes :

• Red Hat Enterprise Linux
  Mettre OpenSSL à niveau pour votre version.
• Windows ou Solaris
  Une mise à jour des bibliothèques openssl sera disponible sur la plateforme du service client. Cette mise à jour remplacera les bibliothèques libssl et libeay, ainsi que l'application openssl.

A : Oui, EWS 2.1 est affecté, des mises à jour seront mises à disponibilité sur le Portail du service client. Cette défaillance affecte uniquement les installations Windows et où APR/OpenSSL a été configuré comme fournisseur de sécurité. La configuration JSSE par défaut n'a pas été affectée. Des mises à jour seront mises à disponibilité sur le Portail du service client.

Dois-je mettre à jour mon installation EWS 3.0.2 ?
Cette défaillance affecte uniquement les installations Windows et Solaris où APR/OpenSSL a été configuré en tant que fournisseur de sécurité. Actuellement, EWS 3.0.2 prend en charge SSLv2 et SSLv3. Lorsqu'EWS 3.0.3 sortira, SSLv2 ou SSLv3 ne seront plus offerts.

Si vous utilisez le fournisseur Apr/OpenSSL, vous devriez effectuer les étapes suivantes :

• Red Hat Enterprise Linux
  Mettre OpenSSL à niveau pour votre version.
• Windows ou Solaris
  Une mise à jour des bibliothèques openssl sera disponible sur la plateforme du service client. Cette mise à jour remplacera les bibliothèques libssl et libeay, ainsi que l'application openssl.

Quel est le statut du paquet tomcat-native ?

Le paquet tomcat natif n'est pas affecté par cette défailllance. Le paquet tomcat-native repose sur les bibliothèques OpenSSL fournies par le système.