Anomalie #8246
Surchage CPU de serveur Twisted suite à test Heartbleed
Description
Patrick Ciurleo a écrit :> Bonjour,
Nous avons rencontré le même type de problème, mais sur la machine
EoleSSO. Le service python eolesso se retrouve avec un CPU à 100% voir
120% sans explication.Il s'avère en finalité que suite à la faille HeartBleed, certaine
personnes ont installé des modules dans leur navigateur qui test le
site SSL sur lequel vous vous connecté ( Le plus répendu :
https://filippo.io/Heartbleed/).Lorsque l'on se connecte à un produit Eolesso utilisant python et SSL
, avec ce type de module le CPU de la machine monte à 100% et c'est la
panique !Dans la mesure où ce test HeartBleed s’exécute depuis une machine
venant du domaine elb.amazonaws.com ( cf : Adresse trouvé dans le
Source du module Firefox -
http://bleed-1161785939.us-east-1.elb.amazonaws.com/bleed/ ) nous
avons bloqué l'ensemble du domaine concerné sur nos firewall.Par contre pourquoi notre EoleSSO plante lorsque l'on test la faille
HeartBleed ?
Related issues
History
#1 Updated by Bruno Boiget almost 9 years ago
Après des tests effectués avec différents scripts et plugins de détection de vulnérabilité à heartbleed, nous avons constaté le problème suivant:
La librairie M2Crypto utilisée pour gérer les connexions SSL dans EoleSSO rend le service instable lorsque certains appels sont effectués dans ces scripts.
La librairie python-openssl utilisée en standard avec le framework TwistedMatrix ne rencontre pas ce problème, mais elle ne répond pas à certains besoins d'EoleSSO (vérification des noms alternatifs dans les certificats).
Diverses solutions envisageables:
- demander une correction au niveau de la librairie M2Crypto, ou traiter le problème nous même le cas échéant
- vérifier si les versions plus récentes de python-openssl permettent de ne plus utiliser cette librairie
- tester avec une version plus récente du framework TwistedMatrix
Pour contourner temporairement le problème, on peut envisager un blocage des adresses de certains domaines pour l'accès au port 8443. en particulier:
- amazonaws.com (web services amazon)
- 55.86.210.127 nstld.verisign-grs.com. 2014052701 1800 900 604800 86400
#2 Updated by Philippe Caseiro almost 9 years ago
Demande ouverte auprès du projet M2Crypto : https://github.com/martinpaljak/M2Crypto/issues/39
#3 Updated by Philippe Caseiro almost 9 years ago
- Project changed from Zéphir to EoleSSO
#4 Updated by Philippe Caseiro almost 9 years ago
J'ai trouvé l'origine du problème dans le code de M2Crypto, j'ai ajouter 2 lignes qui semble corriger le problème.
Dans le fichier M2Crypto/SSL/TwistedProtocolWrapper.py :
414 if pending: 416 d = m2bio_read(sslBioPtr, pending) 418 if d is not None : # This is strange, but d can be None 419 decryptedData += d 420 if decryptedData == "": 421 break 422 else: 423 assert(m2bio_should_retry(sslBioPtr)) 424 else: 426 break
J'ai envoyé le "patch" au projet M2Crypto, j'attend des informations des dev.
J'ai également appliqué la "correction" sur le serveur SSO de "Cadoles" pour l'instant je ne constate aucun dysfonctionnement.
#5 Updated by Bruno Boiget almost 9 years ago
- Target version set to Mises à jour 2.3.13
- % Done changed from 0 to 80
- Distribution changed from Toutes to EOLE 2.3
Les modifications ont été testées sur plusieurs machines :
- serveur PIA de Dijon.
- serveur SSO de Cadoles.
- seveurs de test lab13-eole.ac-dijon.fr
La correction semble fonctionner. Un patch 'eole' correctif sera publié en attendant d'avoir une réponse concernant la demande 'upstream'.
Après vérification, il devrait être possible de repasser sur la librairie python-openssl sur Eole 2.4 (pas sur Eole 2.3, la version présente ne permet pas de vérifier les noms alternatifs dans les certificats).
#6 Updated by Fabrice Barconnière almost 9 years ago
- Status changed from Nouveau to Résolu
- % Done changed from 80 to 100
Paquet testé par plusieurs personnes/académies.
À diffuser en SECURITY.
#7 Updated by Joël Cuissinat almost 9 years ago
- Status changed from Résolu to Fermé
- Estimated time set to 0.08 h