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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2008-43

Gestion du document

Référence CERTA-2008-ACT-043
Titre Bulletin d’actualité 2008-43
Date de la première version 24 octobre 2008
Date de la dernière version 24 octobre 2008
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 Bulletin Microsoft MS08-067

Cette semaine, Microsoft a publié une mise à jour hors cycle mensuel, détaillée dans le bulletin MS08-067 et l’avis CERTA-2008-AVI-523. Cette mise à jour corrige une vulnérabilité dans toutes les versions de Windows. Elle est jugée critique par Microsoft sur les systèmes Windows 2000, Windows XP et Windows 2003. L’éditeur a préféré une mise à jour hors cycle car la vulnérabilité peut être trivialement exploitée et utilisée dans le développement de vers. Des attaques sont déjà observées. Il est rappelé la nécessité d’appliquer les mises à jour.

1.1 Retour sur la vulnérabilité

La vulnérabilité concerne un débordement de mémoire dans le traitement de chemins UNC (Universal Naming Convention) par la méthode NetPathCanonicalize de l’interface RPC srvsvc (service Serveur). En exploitant cette faille, une personne malintentionnée peut exécuter du code arbitraire sur un poste vulnérable en envoyant un paquet spécialement construit lors d’une session SMB/RPC. Nous avons observé que cette vulnérabilité rappelle fortement celle du bulletin MS06-040 qui concernait le même appel RPC.

1.2 Mesures de protection et facteurs atténuants

Hormis le correctif proposé par Microsoft, il existe des facteurs atténuants pour cette vulnérabilité.

Pour pouvoir joindre l’interface concernée, un attaquant doit passer par les ports 139/TCP ou 445/TCP. Ces ports sont filtrés par défaut par le pare-feu de Windows XP SP2, Windows Vista et Windows Server 2008, sauf si le partage de fichiers et d’imprimantes est activé. Ces ports doivent évidemment toujours être filtrés par tout pare-feu de bordure de réseau.

Dans Windows Vista et Windows Server 2008, l’UAC (User Account Control) requiert par défaut une authentification pour accéder à l’interface vulnérable. En effet, un utilisateur non authentifié qui se connecte aura un niveau de droit Untrusted, inférieur au niveau « Faible » qui est requis pour l’accès. Toutefois, les personnes ayant désactivé l’option « Partage protégé par mot de passe » dans le Centre Réseau et Partage se privent de cette protection car les connexions anonymes se font alors avec le niveau « Moyen ».

L’éditeur affirme également que les systèmes Windows Vista et Windows Server 2008 sont davantage protégés de l’exécution de code grâce au mécanisme d’ASLR (Address Space Layout Randomization) couplé au DEP (Data Execution Prevention).

Un outil non garanti est également disponible sur le site de Microsoft pour retirer les autorisations d’accès aux utilisateurs anonymes dans les ACL (Access Control List) des canaux nommés (cf. documentation).

1.3 Filtrage possible

Les outils de filtrage réseau permettent d’isoler certaines trames particulières. Par exemple, sous Wireshark/Ethereal, il existe le filtre d’affichage srvsvc.srvsvc_NetPathCanonicalize.path pour visualiser des chaînes de caractères anormales de la forme :

\<cha�ne de caract�re>\..\..\<autre cha�ne>
..\..\

1.4 Documentation

2 Le protocole LLMNR

2.1 Présentation

Le protocole LLMNR (Link-Local Multicast Name Resolution), défini par la RFC 4795, a pour vocation de permettre à des machines de répondre à des requêtes DNS émanant du voisinage réseau, que ce soit en IPv4 ou en IPv6. Il permet ainsi de résoudre des noms de machine sur des petits réseaux dépourvus de serveur DNS.

Techniquement, le fonctionnement du protocole repose sur l’envoi de paquets à destination du port 5355/udp vers l’adresse IPv4 224.0.0.252 ou l’adresse IPv6 FF02:0:0:0:0:0:1:3 (adresses de multicast).

Le protocole LLMNR est activé par défaut sous Windows Vista. Il est important de comprendre qu’un poste fonctionnant sous Windows Vista va utiliser le protocole LLMNR, et donc engendrer du trafic réseau en conséquence, même si un serveur DNS a été correctement configuré. Ceci se traduit donc par une pollution du réseau.

Le protocole LLMNR peut être désactivé sous Vista :

  • soit par une stratégie de groupe : 
    Computer Configuration\Administrative Templates\Network\DNS Client\
                        Turn off Multicast Name Resolution = Enabled
  • soit par le registre : 
    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\
                                        EnableMulticast = 0x0

2.2 Documentation

3 Migration de version et sécurité

3.1 Présentation

Des tâches essentielles lorsque l’on administre des serveurs sont de les maintenir à jour (applications et système d’exploitation) et de consulter régulièrement les journaux d’événements. Récemment, à la suite d’une récente mise à jour de sécurité d’un serveur, le CERTA a pu constater un effet de bord assez inattendu en examinant les journaux d’un des services installés. Les journaux, ayant auparavant une taille respectable sur le disque, étaient vides depuis le dernier changement de version du logiciel. La première hypothèse orienta l’analyse vers un changement dans le fichier de configuration suite à la mise à jour. Après quelques tests, le CERTA a constaté qu’une des directives qui, d’ordinaire, indiquait au service de filtrer les données envoyées vers les fichiers d’événements, n’avait plus aucun effet. La conséquence est que tous les événements se trouvaient non plus journalisé suite à ce dysfonctionnement mais bien l’inverse : plus aucun événement dans les journaux !

La mise-à-jour de l’application avait donc entraîné l’ajout d’une coquille dans la fonction de filtrage la rendant inopérante. Un contournement au problème fut rapidement trouvé mais les effets n’étaient en aucun cas bénins (perte de traces).

3.2 Recommandations

Lors de l’application de correctifs impliquant un changement de version d’un produit, il convient toujours de passer en revue les nouvelles directives ou les variations de comportement par défaut induites par ce changement. Il faudra également s’assurer, comme c’est le cas ici, qu’aucune fonctionnalité n’a été altérée ou tout simplement supprimée. Enfin, seule l’analyse des journaux a permis de mettre rapidement en évidence le problème, il est donc indipensable de consacrer du temps à cette tâche lorsque l’on a à mettre en œuvre un SI quel qu’il soit.

4 Ouverture spontanée de documents par Microsoft Office

En règle générale, le système d’exploitation Windows s’appuie sur l’extension d’un fichier pour y associer une application à l’ouverture. Ces correspondances sont précisées dans la base de registre Windows. Il est également possible de les vérifier en tapant dans un terminal les commandes assoc ou ftype. Par exemple :

C:\Documents and Settings\USER>assoc .doc
.doc=Word.Document.8

C:\Documents and Settings\USER>ftype Word.Document.8
Word.Document.8= »C:\Program Files\Microsoft Office\Office10\WINWORD.EXE » /n /dde »


C:\Documents and Settings\USER>

DDE est le protocole d’échange dynamique de données. L’objet de cet article n’est cependant pas de discuter cette option, mais de considérer les extensions qui n’apparaissent pas via les commandes ci-dessus ou dans les clés de registre. Un fichier nommé test.aabbcc ne sera pas pris en compte, et en cliquant dessus, Windows fait apparaître une fenêtre demandant quelle application choisir pour l’ouvrir.

Est-ce toujours le cas ?

Démonstration par l’exemple. Prenons un document Office nommé test.doc, changeons l’extension par test.aabbcc et cliquons dessus. La fenêtre précédente n’apparaît pas et l’application Word s’ouvre avec le contenu du document.

Cette propriété fonctionne pour les applications Word, Excel ou PowerPoint. Access ne semble pas en disposer. Un module propre à l’explorateur Windows examine ainsi le contenu du fichier lorsque l’extension n’est pas connue.

Il apparaît clairement de cette courte démonstration que vérifier l’extension n’est pas une opération suffisante pour identifier un document Office. En l’occurence, il est tout à fait envisageable d’imaginer des courriers malveillants qui exploitent cette astuce en renommant le fichier de façon à tromper ce contrôle. Par exemple, un fichier nommé « test.txt ; » peut entraîner en cliquant dessus l’ouverture d’Office.

Il est donc important de ne pas avoir un excès de confiance dans les extensions. Le cas présenté ici n’est qu’une illustration des manipulations et des exceptions aux règles classiques. Les solutions de sécurité proposent également différents filtres et signatures adaptées aux formats de fichiers. Il faut se renseigner sur leurs méthodes d’identification d’un format. Toute solution de sécurité doit être maîtrisée : cela commence par connaître son fonctionnement et ses limites.

5 Des bibliothèques discrètes mais bien présentes

Le CERTA a publié l’avis de sécurité CERTA-2008-AVI-526 concernant la bibliothèque libspf2. Une vulnérabilité de type débordement de mémoire affecte cette bibliothèque et permet à un utilisateur distant malintentionné de provoquer un déni de service et/ou d’exécuter du code arbitraire.

Cette bibliothèque de fonctions est largement répandue dans la mise en oeuvre des passerelles de messagerie pour permettre le filtrage des messages.

Cette vulnérabilité peut être exploitée à distance au moyen d’une réponse DNS (Domain Name System) spécialement contruite (enregistrement TXT de longueur excessive). A l’heure actuelle, seul l’éditeur Debian a publié un correctif pour cette vulnérabilité et il n’est pas exclu que d’autre éditeurs soient également affectés.

Le CERTA recommande de conduire les actions suivantes :

  • maintenir à jour les serveurs en interaction avec Internet ;
  • vérifier si cette bibliothèque en particulier est déployée sur les serveurs ;
  • contrôler le trafic DNS et ne pas directement exposer les serveurs. Un serveur de nom local peut filtrer ce genre de réponses.

Rappel des avis émis

Dans la période du 13 au 19 octobre 2008, le CERT-FR a émis les publications suivantes :


Durant la même période, les publications suivantes ont été mises à jour :

Gestion détaillée du document

    le 24 octobre 2008
    version initiale.