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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2010-36

Gestion du document

Référence CERTA-2010-ACT-036
Titre Bulletin d’actualité 2010-36
Date de la première version 10 septembre 2010
Date de la dernière version 10 septembre 2010
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é non corrigée dans Adobe Acrobat et Adobe Reader

Cette semaine, le CERTA a publié un bulletin d’alerte, CERTA-2010-ALE-014, portant sur une vulnérabilité dans Adobe Reader et Adobe Acrobat.

Cette vulnérabilité présente dans le module de traitement des polices de caractère d’Adobe Reader et Adobe Acrobat (CoolType.dll) permet l’exécution de code arbitraire à distance au moyen d’un document PDF spécialement construit.

Un code d’exploitation est déjà diffusé sur l’Internet et semble fonctionner sur de nombreuses plateformes, incluant Microsoft Windows 7 et Vista. De plus, il a la capacité de contourner les mécanismes de protection de type ASLR (Address Space Layout Randomization) et DEP (Data Execution Prevention).

Dans l’attente d’un correctif de sécurité de la part de l’éditeur le CERTA préconise certaines recommandations dans le bulletin d’alerte CERTA-2010-ALE-014, afin de limiter l’impact et l’exploitation de cette vulnérabilité.

Documentation

2 Nouveau ver « Here you have »

Depuis ces dernières 24 heures, un nouveau ver se propage par les courriels. Ce type de ver n’est pas nouveau, le virus « I love you » avait utilisé la même technique de propagation il y a plus de dix ans.

Ce ver se propage donc principalement via la messagerie en parcourant le carnet d’adresses du client de messagerie et envoyant un courriel à tous les contacts. Le message envoyé peut notamment avoir comme titre « Here you have » mais d’autres variantes sont déjà apparues. Le contenu du message utilise l’ingénierie sociale pour inciter l’utilisateur à cliquer sur un lien qui semble pointer sur un document de type PDF (principalement mais d’autres versions existent avec d’autres types de documents). Le document en question n’est pas un PDF mais un fichier exécutable avec l’extension « .SCR ».

Le ver se répand aussi en utilisant le mécanisme des fichiers Autorun.inf via des supports amovibles ou des disques réseau.

Une fois installé le virus peut notamment (liste non exhaustive) :

  • désactiver le Centre de Sécurité Windows et Windows Update ;
  • modifier des paramètres de sécurité de Windows ;
  • désactiver le pare-feu ou en changer la configuration ;
  • bloquer l’exécution de nombreux antivirus et utilitaires de nettoyage ;
  • télécharger des fichiers arbitraires depuis l’Internet ;
  • désactiver certains utilitaires de gestion des périphériques USB ;
  • supprimer le fichier HOSTS.

De par son activité de « mass mailing » le ver peut provoquer des dysfonctionnements des serveurs de messagerie à cause de la charge induite. Pour les serveurs Exchange, Microsoft a publié une entrée de blog décrivant les procédures à suivre pour purger les messages malveillants, créer des règles de filtrage et identifier les stations de travail à l’origine de l’envoi massif de messages (Cf. la section « Documentation »).

Plusieurs mesures peuvent limiter l’impact de ce type de vers (liste non exhaustive) :

  • informer les utilisateurs du type de message qu’ils pourraient recevoir ;
  • mettre à jour les antivirus ;
  • contacter votre éditeur si vous utilisez des solutions de sécurité sur vos serveurs de messagerie (mise à jour de signatures, de règles, etc) ;
  • filtrer les liens ou fichiers « .SCR » sur les proxies/pare-feux/filtres de messagerie ;
  • désactiver l’Autorun ;
  • utiliser un compte avec des droits limités.

Documentation

3 RIPE et perturbation de BGP

Malgré plusieurs précautions (audit de code et routeur BGP en coupure du routeur expérimental), une expérience visant à valider une version sécurisée du protocole BGP (Border Gateway Protocol) a engendré une petite perturbation de l’Internet le jeudi 27 août 2010 pour une durée estimée de 30 minutes à 1 heure.

Dans le cadre de cette expérience, le RIPE NCC (Réseaux IP Européens Network Coordination Centre : organisme en charge de la gestion et de la coordination technique de l’infrastructure de l’Internet pour l’Europe) a effectué des annonces BGP expérimentales depuis Amsterdam en utilisant un attribut non défini dans les RFC de BGP. Il est important de souligner que d’après ces RFC, ces annonces expérimentales devaient être sans conséquence sur les implémentations existantes de BGP.

Un bug dans les routeurs Cisco a été l’origine de la panne. Face à cet attribut inconnu, certaines versions d’implémentation du protocole BGP embarquées dans des routeurs Cisco modifiaient les annonces BGP expérimentales en les rendant incompatibles avec les RFC, donc avec les implantations des autres constructeurs. Par voie de conséquence, ces annonces invalides étaient rejetées par les voisins des routeurs Cisco incriminés. Le rejet de ces annonces invalides a eu pour conséquence de couper les sessions BGP entre les routeurs de certains opérateurs.

Plusieurs impacts sur l’Internet ont rapidement été identifiés :

  • la disparition de certains préfixes (0.04% à 0.13%) donc l’inaccessibilité des IP correspondantes ;
  • l’instabilité de certaines annonces BGP (1.4% – 4500 préfixes).

En France, cette inaccessibilité a touché deux serveurs DNS gérant la zone « FR », cinq d’entre eux n’ont pas été touchés du tout. L’AFNIC a par ailleurs indiqué que cela n’a absolument pas perturbé le service global de résolution sur la zone « FR ».

Ce bogue et ses conséquences ont rapidement été identifiés grâce à la grande réactivité du RIPE NCC et des différents acteurs de l’Internet. Le bogue a par ailleurs été corrigé par Cisco via un patch pour ses routeurs (Cf. l’avis CERTA-2010-AVI-410). Ce bogue d’implémentation aurait pu être déclenché par n’importe quel opérateur utilisant BGP et demeure similaire au bogue Cisco de février 2009 (http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml).

Documentation

4 Problème avec SPIP 2.1

Selon les développeurs de SPIP, un bogue a été introduit il y a environ 10 mois dans la version 2.1 de leur produit. Cela a eu pour conséquence, le 3 septembre 2010, de donner le sentiment que les articles des sites sous SPIP avaient disparu. Alors qu’en fait, il ne s’agissait que d’un problème d’affichage.

Les développeurs proposent deux façons de corriger ce problème :

  • en remplaçant, dans le fichier ecrire/public/quete.php, ligne 82, la valeur 10000 par 365*2 ;
  • ou bien en installant la version 2.1.2 de SPIP.

Le problème n’existe que sur les architectures 32 bits, pour lesquelles la date excède la valeur maximale.

Le CERTA n’a pas publié d’avis de sécurité concernant cette nouvelle version de SPIP, le problème n’étant pas une atteinte à l’intégrité des données.

Documentation :

Rappel des avis émis

Dans la période du 30 août au 05 septembre 2010, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 10 septembre 2010
    version initiale.