S . G . D . S . N Agence nationale de la sécurité des systèmes d'information

Paris, le 04 mai 2009 No CERTA-2009-ACT-018

Affaire suivie par :

CERTA

Objet : Bulletin d'actualité 2009-18

Gestion du document

Le bulletin d'actualité est disponible dans son intégralité et au format PDF à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-018.pdf

Un extrait du bulletin, ne reprenant que les articles de la semaine, se trouve en HTML à l'adresse suivante :

http://www.certa.ssi.gouv.fr/site/CERTA-2009-ACT-018/

1 Un outil de développement mis en ligne

Cette semaine, le CERTA a participé au traitement d'un incident relatif à la compromission d'un serveur Web. La mise en évidence de la compromission a débuté par la découverte d'un kit de filoutage (ou phishing). La vulnérabilité exploitée était en fait assez simple : il n'y avait aucun mot de passe pour le compte d'administration de la base de données. Le responsable du serveur avait, en effet, installé une boite à outils pour le développement Web que l'on trouve sur l'Internet. Ce kit permet d'installer, en une fois, les services Apache, MySQL, PHP et Perl. Bien que ce kit semble régulièrement mis à jour, ses auteurs indiquent qu'il n'est pas destiné à la production et qu'il n'y a aucune sécurité par défaut :

• aucun mot de passe pour le compte d'administration de la base de données ;
• le serveur de base de données accessible depuis le réseau ;
• le logiciel phpMyadmin accessible depuis le réseau ;
• des identifiants par défaut de certaines applications connues.

Cet incident révèle plusieurs types de problèmes :

• la mise à disposition sur l'Internet d'un applicatif qui n'est pas destiné à la production ;
• l'utilisation d'une installation par défaut malgré les avertissements des auteurs de l'outils ;
• l'absence de sécurité de ce kit d'installation.

2 Actualités Microsoft

2.1 Office 2007 Service Pack 2

La semaine dernière, Microsoft a publié le service pack 2 pour sa suite bureautique Office 2007. Cette mise à jour comprend l'ensemble des correctifs publics publiés jusqu'en février 2009 et de nouveaux correctifs spécifiques au service pack. Ceci inclut, en plus des mises à jour de sécurité, des mises à jour de stabilité et de performance ainsi que quelques nouvelles fonctionnalités.

Pour plus d'informations, se référer à l'article KB953195 de la base de connaissances de Microsoft (cf. Documentation).

2.2 Autres nouveautés

Pour les abonnés Technet et MSDN, Microsoft a également publié les logiciels suivants :

• service pack 2 pour Windows Vista et Windows Server 2008 ;
• Windows 7 release candidate.

Pour rappel, le service pack 2 est en fait le premier service pack de Windows Server 2008 (ce dernier correspondant à Windows Vista service pack 1). Ces mises à jour seront disponibles pour le grand public très prochainement.

En ce qui concerne Windows 7, il s'agit encore d'une version de test et il n'est donc pas recommandé d'installer ce système sur une machine de production.

2.3 Documentation

• Description de Office 2007 Service Pack 2 :

  http://support.microsoft.com/kb/953195
  

• Description du service pack 2 pour Windows Vista et Windows Server 2008 :

  http://technet.microsoft.com/en-us/library/dd335036.aspx
  

• Bloc-notes de P. Saulière, Microsoft France :

  http://blogs.technet.com/pascals/archive/2009/05/04/windows-vista-sp2-et-windows-server-2008-sp2-sur-technet-et-msdn.aspx
  

3 Les antivirus et les fichiers d'archivage

3.1 Présentation

Les fichiers d'archivage (.zip, .gz, .rar, .cab, etc.) ont toujours constitué un problème pour les antivirus. En effet, un code malveillant peut être contenu dans l'archive ou dans un des fichiers qu'elle contient. Pour analyser les fichiers contenus dans une archive, il est nécessaire que l'antivirus décompresse celle-ci à l'aide de préprocesseurs spécifiques à chaque mode d'archivage.

Ces préprocesseurs de décompression font malheureusement l'objet de vulnérabilités. En particulier, un chercheur en sécurité informatique a trouvé des vulnérabilités dans quasiment toutes les passerelles d'antivirus permettant de contourner le mécanisme de vérification des archives. Concrètement, l'exploitation de la vulnérabilité permet à un code malveillant inclus dans une archive de traverser une passerelle d'antivirus. Les conséquences sont variables : si cette archive est ensuite manipulée par un utilisateur, il est possible qu'un antivirus sur le poste client réagisse lors de l'exécution du code malveillant. Par contre, si la protection antivirale ne repose que sur la passerelle, alors l'archive pourra être perçue comme sûre par les utilisateurs.

Les éditeurs d'antivirus réagissent différemment à ces problèmes : certains sortent un correctif ainsi qu'un avis de sécurité (voir par exemple avis CERTA-2009-AVI-033), d'autres font des corrections « silencieuses » (le moteur de l'antivirus est mis à jour automatiquement) ou encore choisissent de ne pas traiter cette vulnérabilité.

Le CERTA n'a pas connaissance de cas d'exploitation de ces vulnérabilités. Le chercheur ayant fait ces découvertes tient un bloc-notes (blog) dans lequel il cite les différents produits d'antivirus ainsi que les réactions des éditeurs. Il ne donne pas de détails quant aux vulnérabilités.

3.2 Documentation

• Article sur le blog de Thierry Zoller :

  http://blog.zoller.lu/2009/04/case-for-av-bypassesevasions.html
  

4 Les procédures de mises à jour de Mozilla Firefox

4.1 Introduction

Le CERTA recommande régulièrement de maîtriser les connexions sortantes de son réseau, et en particulier les procédures de mises à jour. Celles-ci sont indispensables mais doivent être faites avec précaution. Il faut donc au minimum :

• s'assurer de bien communiquer avec le ou les sites de mises à jour légitimes ;
• pouvoir vérifier l'intégrité des données récupérées ;
• contrôler les informations échangées avec les sites distants pour éviter des fuites d'information ;
• avoir la possibilité d'effectuer les mises à jour hors connexion ;
• pouvoir éventuellement garantir la discrétion des mises à jour (ne pas annoncer à tous les applications et les versions utilisées, etc.).

Qu'en est-il par exemple des procédures de mises à jour pour le navigateur Mozilla Firefox ?

4.2 Concernant le navigateur Mozilla Firefox

Le navigateur Mozilla Firefox est relativement déployé. Or il semble que la procédure de mise à jour de ce dernier n'est pas vraiment maîtrisée par les utilisateurs. L'objet de cette section est donc de reprendre les points essentiels de mises à jour.

La procédure de mise à jour automatique sous Mozilla Firefox se fait en plusieurs étapes distinctes :

1. le navigateur vérifie régulièrement sur les serveurs de Mozilla si des mises à jour sont disponibles. Cette vérification a lieu à chaque démarrage du navigateur ainsi qu'à certains intervalles de temps précisés dans la configuration (about:config) par la variable app.update.interval. Il s'agit en secondes de la durée avant un nouveau test. La valeur par défaut est fixée à 86400, soit 1 jour. Cette valeur est prise en compte si la variable app.update.enabled est à true.
2. le navigateur émet à chaque vérification une requête en HTTPS (GET) précisée dans la variable app.update.url. Elle est généralement de la forme :

   https://aus2.mozilla.org/update/3/Firefox/3.0.9/2009XXXXXX/...fr/.../default/default/update.xml?force=1
   

   La version indiquée dans l'adresse réticulaire (3.0.9) est la dernière version installée sur la machine. L'adresse précise aussi le type de plate-forme et la langue installée. Cette vérification a pour objectif de récupérer un fichier nommé update.xml. Il se présente sous la forme suivante :

   Si aucune mise à jour n'est annoncée :
   
   <updates></updates>
   
   Si une mise à jour est disponible :
   
   
   <updates>
   <update type="minor" version="3.0.10" extensionVersion="3.0.10"
       buildID="200904XXXX" 
       detailsURL="http://www.mozilla.com/fr/firefox/3.0.10/releasenotes/">
   
   <patch type="complete" 
       URL="http://download.mozilla.org/?product=firefox-3.0.10-complete&os=xx&lang=fr"
       hashFunction="SHA1" hashValue="xxxxxxxxxxxxxxxxxx" sizeValue="xxx">
   
   <patch type="partial" 
       URL="http://download.mozilla.org/?product=firefox-3.0.10-partial&os=xx&lang=fr"
       hashFunction="SHA1" hashValue="xxxxxxxxxxxxxxxxxx" sizeValue="xxx">
   </updates>
   

   Le lecteur voit donc ici que le fichier indique ensuite deux possibilités de téléchargement (partiel ou complet) vers un nouveau site. La communication se fait ici en clair. Une mise à jour partielle applique un patch de différence binaire tandis qu'une complète procède aux remplacements de tous les fichiers impliqués dans la mise à jour.

3. le téléchargement aux adresses indiquées ci-dessus d'un fichier au format .MAR (pour Mozilla ARchive). Son intégrité est vérifiée par le navigateur en comparant l'empreinte annoncée dans le fichier update.xml avec celle obtenue après calcul sur le fichier reçu. Le fichier est une archive contenant les fichiers de mise à jour ainsi qu'un index. Cet index précise simplement les endroits (offsets) où aller chercher les fichiers insérés dans le .MAR, ainsi que leurs noms et les droits associés.

4.3 Mises à jour hors connexion

Le lecteur aura compris à la lecture du précédent paragraphe qu'il est donc bien possible de faire une mise à jour hors connexion des navigateurs Mozilla Firefox. Deux méthodes sont possibles :

• créer un serveur avec un fichier update.xml adéquat vers lequel les navigateurs vont chercher les mises à jour à installer. Il faut donc également changer l'adresse de la variable app.update.url dans la configuration des navigateurs. Une documentation existe à l'adresse suivante (néanmoins le lien n'est pas fonctionnel à la date de rédaction de cet article) :

  http://developer.mozilla.org/en/docs/Setting_up_an_update_server
  

• copier localement les fichiers de mises à jour .MAR dans des répertoires dédiés sur les machines et lancer l'applicatif fourni avec Firefox pour forcer les mises à jour. Le résultat de la mise à jour est consultable dans le fichier update.status. L'ensemble de la manipulation est documenté à l'adresse :

  https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file
  

4.4 Références

• Documentation Mozilla concernant les procédures de mises à jour Firefox :

  https://wiki.mozilla.org/Software_Update
  

• Code source de la bibliothèque libmar :

  https://bugzilla.mozilla.org/show_bug.cgi?id=296303
  

• Description de la variable App.update.interval sur MozillaZine :

  http://kb.mozillazine.org/App.update.interval
  

5 Rappel des avis émis

Dans la période du 24 avril au 01 mai 2009, le CERTA a émis l'alerte et les avis suivants :

• CERTA-2009-ALE-006 : Multiples vulnérabilités dans Adobe Reader et Adobe Acrobat
• CERTA-2009-AVI-161 : Vulnérabilités dans Symantec Brightmail Gateway
• CERTA-2009-AVI-162 : Vulnérabilité dans Google Chrome
• CERTA-2009-AVI-163 : Multiples vulnérabilités dans HP StorageWorks
• CERTA-2009-AVI-164 : Vulnérabilités dans apt
• CERTA-2009-AVI-165 : Vulnérabilité dans FreeBSD
• CERTA-2009-AVI-166 : Vulnérabilité dans Mozilla Firefox
• CERTA-2009-AVI-167 : Vulnérabilités dans des produits Symantec
• CERTA-2009-AVI-168 : Multiples vulnérabilités dans des produits Symantec
• CERTA-2009-AVI-169 : Vulnérabilité dans Citrix Web Interface
• CERTA-2009-AVI-170 : Vulnérabilité dans HP-UX

Gestion détaillée du document

04 mai 2009

version initiale.