S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 20 mai 2011
N° CERTA-2011-ACT-020
Affaire suivie par: CERT-FR
le 20 mai 2011

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2011-20

Gestion du document

Référence CERTA-2011-ACT-020
Titre Bulletin d’actualité 2011-20
Date de la première version 20 mai 2011
Date de la dernière version 20 mai 2011
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Vulnérabilité dans OpenSSL

Cette semaine, deux chercheurs ont publié une attaque contre l’implémentation par OpenSSL de la signature DSA basée sur les courbes elliptiques (ECDSA), dans le cas de courbes sur un corps fini de caractéristique 2. Cette attaque repose sur la mesure du temps écoulé pour le calcul des signatures. L’analyse du temps d’exécution permet de déduire des informations sur les entrées, notamment la clef secrète. Cette classe d’attaque (timing attacks) a plusieurs fois conduit OpenSSL à évoluer (CVE-2003-0078, CVE-2003-0147).

En pratique, l’attaque décrite ne permet de retrouver la clef secrète que si les variations entre les mesures de temps effectuées lors de la création de différentes signatures reflètent avec une grande précision les variations entre les temps d’exécution de la multiplication d’un point de base de la courbe par un entier, opération réalisée à la production de chaque signature. Les conditions optimales sont réunies quand l’attaquant est sur l’ordinateur qui signe (serveur) et si celui-ci n’est pas trop chargé. Cette cohabitation peut résulter de l’injection d’un code malveillant aux ordres de l’attaquant sur le serveur ou de la virtualisation : l’attaquant est sur une machine virtuelle et le serveur victime sur une autre. La finesse de la mesure et l’efficacité de l’attaque décroissent rapidement si le serveur est chargé ou si l’attaquant est distant.

En attendant un correctif dans la bibliothèque OpenSSL, mais également de manière générale, il convient de s’assurer de la salubrité des serveurs utilisés pour les signatures, c’est-à-dire de l’absence de codes malveillants, et de l’hygiène informatique des machines virtuelles cohébergées.

1.1 Documentation

2 Cycle de vie des versions de Firefox

La fondation Mozilla à l’origine du navigateur Firefox a récemment communiqué sur la poursuite de la maintenance de la branche 3.5 de Firefox. En effet, elle indique dans un article (cf. Documentation) qu’avec l’arrivée de la version 4 et bientôt de la version 5 du navigateur, l’équipe ne continuerait plus à maintenir la version 3.5 mais forcerait bientôt un passage obligatoire au moins en version 3.6.x.

Il semble, pour les développeurs, que cette migration forcée en 3.6 constitue un meilleur compromis que de passer directement en version 4. En effet, selon eux, l’interface change très peu entre 3.5 et 3.6, la compatibilité avec d’anciens systèmes ou d’anciennes architectures est garantie contrairement à la version 4 qui ne fonctionne plus, par exemple, avec les systèmes MacOS X 10.4 ou sur les architectures PowerPC. Enfin la plupart des extensions prévues pour la 3.5 resteraient compatibles avec la 3.6.

Il n’en reste pas moins que cette mise à jour « forcée » pourra engendrer des effets de bord indésirables dans certains cas. Le CERTA recommande donc de devancer cette mise à jour obligatoire et de procéder à des tests d’intégration et des vérifications de compatibilité au préalable afin d’éviter tout désagrément lorsque la mise à niveau se produira.

2.1 Documentation :

3 Gestion des jetons d’authentification dans le protocole ClientLogin de Google

Afin d’accéder à un service Google nécessitant une authentification, une application peut utiliser le protocole ClientLogin de Google.

Le principe de ce protocole est de récupérer un jeton d’authentification auprès de Google en lui fournissant un identifiant et un mot de passe. Celui-ci est ensuite envoyé à l’application concernée.

Une vulnérabilité a été identifiée et concerne plusieurs applications installées sur des téléphones fonctionnant sous Android, comme l’application de synchronisation des contacts ou du calendrier. En effet, celles-ci envoient le jeton d’authentification en clair sur le réseau. Il peut alors être récupéré par un attaquant si celui-ci dispose de moyens d’écoute ; ce qui peut être le cas si le téléphone est connecté à un réseau Wi-Fi non sécurisé. Dès lors, en utilisant un mécanisme de rejeu, l’utilisateur malintentionné peut récupérer et modifier les données stockées sur le serveur comme s’il était authentifié.

Le principe de cette attaque n’est pas nouveau et est similaire à la récupération de sessions « HTTP ». Cependant, dans le protocole ClientLogin, le jeton engendré est considéré comme valide pendant une durée de deux semaines et n’associe pas un client unique pour chaque jeton.

Google a sorti une mise à jour de son système Android en corrigeant les applications vulnérables avec la version 2.3.4. Comme toutes ces mises à jour, l’utilisateur devra patienter jusqu’à ce que le fabricant et l’opérateur les mettent à disposition. Il semblerait cependant que pour corriger la vulnérabilité, Google forcerait l’utilisation du protocole HTTPS dans les communications entre l’application et le service. L’avantage est que l’utilisateur n’aura pas à attendre une éventuelle mise à jour et que cette solution protègera des attaques contre des applications vulnérables n’ayant pas été identifiées . L’inconvénient est que si l’application ne supporte pas la communication HTTPS, celle-ci ne pourra plus accéder aux services concernés.

Documentation

4 Le processus GoogleCrashHandler.exe

Certains utilisateurs s’étonnent parfois de voir, dans le gestionnaire de processus, une entrée nommée GoogleCrashHandler.exe. Ils s’interrogent sur la légitimité du processus, susceptible d’être détecté comme code malveillant par certains antivirus. Il est même possible de voir plusieurs instances de ce programme tourner simultanément, ce qui est parfois caractéristique des codes malveillants.

Il existe bel et bien un programme nommé GoogleCrashHandler.exe développé par la société Google. Celui-ci a, a priori, deux fonctions principales :

  • envoyer de façon « anonyme » des statistiques de l’utilisateur ;
  • en cas d’arrêt inopiné d’une application développée par Google, envoyer un rapport à l’éditeur, vraisemblablement afin d’identifier un éventuel bogue.

Ce logiciel est installé automatiquement avec toute application Google récente. Chacune d’entre elles peut déclencher le lancement d’une instance de GoogleCrashHandler.exe. L’exécution de ce programme est liée à l’activation d’une option d’envoi automatique des statistiques d’usage et de rapport de crash. Par exemple, sous Google Chrome, cette option peut être désactivée via le panneau des options avancées (cela se fait en décochant une case). Pour rester dans l’exemple de Google Chrome, au moment de l’installation du navigateur, l’activation automatique est proposée par défaut.

Pour empêcher le lancement du processus GoogleCrashHandler.exe, il faut donc penser à le désactiver pour chaque application Google qui l’utilise. Le principal risque associé à ce programme est la fuite d’informations, notamment en cas d’arrêt inopiné d’un logiciel.

Rappel des avis émis

Dans la période du 09 au 15 mai 2011, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 20 mai 2011
    version initiale.