Project

General

Profile

Anomalie #8246

Surchage CPU de serveur Twisted suite à test Heartbleed

Added by Luc Bourdot almost 7 years ago. Updated almost 7 years ago.

Status:
Fermé
Priority:
Haut
Assigned To:
Category:
-
Start date:
Due date:
% Done:

100%

Estimated time:
0.08 h
Spent time:
Distribution:
EOLE 2.3

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

Related to m2crypto - Evolution #8339: Recompilation de m2crypto pour EOLE 2.4 Fermé 06/20/2014
Related to Distribution EOLE - Tâche #15803: M2Crypto : Ajout d'informations à la demande déposée upstream Fermé 03/29/2016

History

#1 Updated by Bruno Boiget almost 7 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 7 years ago

Demande ouverte auprès du projet M2Crypto : https://github.com/martinpaljak/M2Crypto/issues/39

#3 Updated by Philippe Caseiro almost 7 years ago

  • Project changed from Zéphir to EoleSSO

#4 Updated by Philippe Caseiro almost 7 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 7 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 7 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 7 years ago

  • Status changed from Résolu to Fermé
  • Estimated time set to 0.08 h

Also available in: Atom PDF