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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-31

Gestion du document

Référence CERTA-2009-ACT-031
Titre Bulletin d’actualité 2009-31
Date de la première version 31 juillet 2009
Date de la dernière version 31 juillet 2009
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 Avis remarquables de la semaine

Cette semaine, le CERTA a publié plusieurs avis de sécurité. Certains revêtent un caractère particulier et nécessitent une attention soutenue malgré la période estivale. Il sont détaillés dans la section suivante.

1.1 Mises à jour Microsoft

Cette semaine, Microsoft a émis deux correctifs hors de son cycle mensuel habituel de mises à jour. Ces deux bulletins sont détaillés dans les avis CERTA-2009-AVI-299 et CERTA-2009-AVI-300.

La sortie exceptionnelle de ces deux bulletins est liée à l’existence de trois vulnérabilités d’une bibliothèque (Active Template Library ou ATL). Celle-ci est utilisée dans la création d’objets COM (Component Object Model) et donc dans de nombreux contrôles ActiveX.

La mise à jour décrite dans le bulletin MS09-035 corrige ces trois vulnérabilités dans les bibliothèques publiques fournies avec les produits Microsoft Visual Studio. Il ne s’agit donc pas d’une faille des produits Visual Studio.

L’exploitation de ces vulnérabilités permet l’exécution de code arbitraire et le contournement du système de liste noire utilisé par Microsoft pour désactiver des contrôles ActiveX dangereux (les « kill-bits »).

Le correctif détaillé dans le bulletin MS09-034 corrige également trois vulnérabilités dans Microsoft Internet Explorer. Celles-ci permettent l’exécution de code arbitraire à distance au moyen de pages web spécialement conçues, et ne sont pas liées aux failles de ATL. Toutefois, cette mise à jour inclut également deux mécanismes de protection dans Internet Explorer permettant de se protéger de contrôles ActiveX vulnérables compilés avec la bibliothèque incriminée. C’est pour cette raison que ce correctif est également émis hors du cycle mensuel.

Le premier mécanisme de protection, activé par défaut, filtre selon l’éditeur des « modèles d’appel spécifiques qui sont problématiques » . Le deuxième mécanisme permet, au moyen de clés dans la base de registre, de désactiver les contrôles potentiellement vulnérables. Il est, en revanche, désactivé par défaut car il peut avoir des effets de bord non négligeables.

Il est important de noter que ces deux mécanismes de protection ne fonctionnent que pour les cas potentiels d’exploitation au travers d’Internet Explorer. Les contrôles ActiveX peuvent être utilisés dans d’autres situations (documents Microsoft Office, par exemple).

Les vulnérabilités se trouvant dans une bibliothèque, il appartient également aux développeurs de mettre à jour leurs produits potentiellement affectés. A cette fin, Microsoft a détaillé une méthodologie permettant de déterminer si une application est vulnérable (cf. section Documentation). Un outil est également disponible pour faciliter cette démarche sur le site http://www.icasi.org. Adobe et Cisco ont, d’ores et déjà, émis des bulletins de sécurité pour certains de leurs produits qui sont concernés.

Davantage de détails sur les deux bulletins sont disponibles sur les sites de Microsoft.

1.1.1 Documentation

1.2 Vulnérabilité de ISC BIND

Cette semaine, tandis que Microsoft publiait ses correctifs en dehors de son cycle traditionnel, l’Internet Systems Consortium (ISC) publiait bien plus discrètement un correctif pour le serveur de nom de domaine BIND.

La vulnérabilité corrigée a fait l’objet de l’avis CERTA-2009-AVI-302. Elle peut être exploitée par le biais d’un paquet UDP pour perturber le service de noms. Il s’agit de l’interprétation de requêtes de mises à jour dynamiques concernant une zone pour laquelle le serveur est autorité (master) et qui contient des données d’enregistrement de type ANY.

Parmi les caractéristiques de l’exploitation :

  • les trames UDP peuvent être émises en usurpant des adresses IP sources ;
  • les traces correspondantes dans les journaux de l’application indiquent la tentative d’exploitation mais ne précisent pas les éventuels émetteurs ;
  • l’attaque fonctionne même si la condition « allow-update { none; }; » est indiquée dans la configuration ;
  • plusieurs configurations incluent des zones maîtres pour localhost.localdomain pouvant ainsi être vulnérables.

Une mesure préventive ou de surveillance consiste à observer les requêtes de type UPDATE (opcode=5).

A cette occasion, le CERTA rappelle qu’il est important de prendre en compte les serveurs de noms dans le cadre d’une politique de surveillance de son réseau.

1.2.1 Documentation associée

1.3 Vulnérabilité Shockwave Flash

Enfin, le CERTA a également publié l’avis CERTA-2009-AVI-305 relatif à la publication par Adobe du correctif pour la faille détaillée dans CERTA-2009-ALE-013. Pour rappel cette vulnérabilité touchait plusieurs produits Adobe dont Acrobat, Reader et Flash Player. Il est vivement recommandé d’appliquer les correctifs associés. Par ailleurs, la faille étant exploitable par le biais des extensions présentes dans Internet Explorer et Firefox, il faudra bien prendre garde à effectuer la mise à jour pour chaque navigateur : un contrôle ActiveX pour le premier et un module complémentaire pour le second.


Cette semaine a donc vu la publication d’avis touchant des produits très répandus ou d’usagetrès courant. Malgré un contexte estival peu propice à la chose, il est tout de même très fortement recommandé de porter une attention particulière à toutes ces publications et d’appliquer les correctifs associés dans les plus brefs délais.

2 SSL et les caractères spéciaux

Au cours d’une conférence de sécurité, un chercheur a trouvé un moyen plutôt original de mettre à mal la chaîne de sécurité induite par l’utilisation de SSL. Pour rappel, l’initiation d’une connexion SSL se fait après échange et vérification d’un certificat. Pour que ce certificat soit reconnu par défaut par les navigateurs classiques, il est nécessaire de l’avoir fait vérifier et signer par une autorité de certification « de confiance » (CA).

Pour simplifier, lorsqu’une autorité de certification vérifie un certificat, elle contacte le propriétaire du domaine contenu dans le Nom Commun (ou Common Name). La vérification faite, l’autorité de certification signe le certificat qui peut alors être utilisé.

Au cours de la conférence, le chercheur a démontré des failles dans la gestion des caractères spéciaux permettant de faire signer des certificats par une autorité de certification, puis d’utiliser ces certificats pour tromper un internaute peu attentif.

Les toutes dernières versions des navigateurs corrigent ce problème. Quoiqu’il en soit, le CERTA tient à rappeler qu’il convient de toujours vérifier scrupuleusement le contenu d’un certificat (et en particulier la concordance du Nom Commun avec le site visité) avant d’accepter une connexion SSL et a fortiori avant d’accepter définitivement d’ajouter le certificat dans son magasin. Des caractères spéciaux dans le Nom Commun (en particulier un « . » à la fin de celui-ci) sont certainement suspects.

3 Cycle de vie du système d’exploitation Debian

Le projet Debian fournissant la distribution homonyme basée sur le système GNU/Linux a annoncé cette semaine une modification dans sa politique de publication de nouvelle version stable.

Historiquement et jusqu’à la version 5.0 (Lenny), le projet considérait que la sortie d’une nouvelle version stable ne devait avoir lieu que lorsque la distribution en phase de test (testing) avait atteint un degré de maturité suffisant. Peu importait la durée du cycle de développement.

Ainsi, la durée entre deux versions a parfois excédé les deux ans. Or, depuis peu, il a été décidé par ce projet communautaire d’initier un processus de stabilisation (freeze) à date fixe. Dorénavant, la version de test entrera en version freeze au mois de novembre des années impaires pour que la sortie finale de la nouvelle version stable se fasse au début de l’année paire suivante. La phase comprise entre l’état freezed et cette publication est réservée à la correction des bogues résiduels.

En terme de sécurité et de maintenance, ceci peut avoir un effet bénéfique, puisqu’il devient possible d’anticiper et planifier une migration. La phase postérieure au freeze peut être d’ailleurs l’occasion de tester la nouvelle version puisque dans cet état, les versions des logiciels ne changent plus. Il devient alors possible, et sans trop de surprise, de tester la migration et l’intégration de ses logiciels métier.

4 Windows 7 et la fonctionnalité HomeGroup

4.1 De quoi s’agit il ?

Il s’agit de faciliter le partage de fichiers entre plusieurs ordinateurs d’un réseau privé, par exemple des photos entre plusieurs ordinateurs d’un domicile. Jusque là, pour accéder aux ressources d’une autre machine, il fallait que celle-ci les partage et que l’utilisateur distant ait les droits de s’y connecter et de lire les fichiers, cela pouvant, bien sûr, poser de nombreux problèmes de configuration. La fonctionnalité HomeGroup offre la possibilité aux utilisateurs de partager simplement des ressources (fichiers, repertoires …) au sein d’un groupe. Il n’est plus question de « droits d’accès » ou « droits en lecture » mais d’appartenance au groupe. Pour en faire partie, chaque utilisateur devra saisir le mot de passe unique et partagé, généré au moment de la création du HomeGroup et indiquer ce qu’il désire partager. L’accès aux ressources mises en commun se fait ensuite simplement dans l’explorateur de fichiers qui contient un nouvel élément dans le bandeau de gauche, le HomeGroup.

4.2 Comment cela fonctionne-t-il ?

Chaque machine qui fait partie d’un HomeGroup dispose d’un compte utilisateur HomeGroupeUser$ qui fait partie du groupe HomeUsers, ce dernier ayant les droits sur les données partagées. L’authentification pour accéder aux ressources distantes est ensuite faite par l’utilisateur HomeGroupeUser$ et à l’aide du nouveau protocole Public Key-based User to User (PKU2U).

4.3 Conclusion

Attention, l’accès aux ressources n’est protégé que par un mot de passe partagé que chacun possède et peut donner ; on ne sait donc pas a priori qui accédera aux données. Le CERTA recommande donc la plus grande prudence lors de l’utilisation de cette fonctionnalité.

4.4 Documentation

Rappel des avis émis

Dans la période du 20 au 26 juillet 2009, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 31 juillet 2009
    version initiale.