1 Alerte CERTA-2009-ALE-002

Le CERTA a publié cette semaine l’alerte CERTA-2009-ALE-002 concernant l’application de bureautique Excel. Cette vulnérabilité est actuellement exploitée dans certains cas d’attaques dont le scénario consiste à envoyer un courrier électronique contenant une pièce jointe malveillante.

Des codes circulent actuellement sur l’Internet et sont signalés sous le nom Exploit:Win32:Evenex.gen par Microsoft et Trojan.Mdropper.AC par Symantec. Ils fonctionnent sur certaines versions de langue d’Office 2007 mais Microsoft précise dans son avis de sécurité 968272 que l’ensemble des versions Excel seraient impactées.

Le dysfonctionnement d’Excel à l’ouverture de tels fichiers peut créer une entrée dans les journaux d’événements Windows.

Des contournements provisoires sont recommandés par le CERTA dans son alerte CERTA-2009-ALE-001.

2 Retour sur l’alerte CERTA-2009-ALE-001 concernant Adobe

2.1 La vulnérabilité

Le CERTA a publié la semaine dernière l’alerte CERTA-2009-ALE-001 concernant les fichiers PDF interprétés par les lecteurs Adobe. La vulnérabilité identifiée concerne plus précisément la gestion des flux de type JBIG2.

JBIG2 est une méthode de compression d’images binaires apparue dans les standards internationaux en 2000 et 2001 sous les noms d’ITU T.88 et ISO/IEC 14492. Cette méthode distingue dans une image les zones de texte (les symboles), les zones dites en « demi-teintes » ou même d’autres zones dites génériques qu’elle traite différemment dans le processus d’encodage. Une donnée JBIG2 est ainsi constituée de plusieurs blocs fonctionnels, ou segments. La compression obtenue peut être avec ou sans perte.

Les fichiers PDF se présentent sous la forme d’un ensemble d’objets pouvant être encodés suivant plusieurs méthodes. L’une de celles définies est donc JBIG2. Le filtre JBIG2Decode s’applique aux images monochromes (un bit par pixel) de type XObject en manipulant dans le fichier PDF le flux de l’objet. Chaque page ou image encodée en JBIG2 est alors représentée par une image PDF.

Une vulnérabilité a été identifiée dans la manière dont est géré un segment JBIG2 avec une page ou image, et en particulier l’association qui existe entre les deux : les pages sont identifiées par leur numéro et le segment JBIG2 précise normalement à quelle page il est associé.

Cette vulnérabilité peut être assez simplement exploitée pour perturber l’application (déni de service) ou exécuter du code arbitraire à distance. L’une des techniques d’exploitation consiste à exploiter la vulnérabilité par du JavaScript (remplissage de tas ou heap spray). C’est cette méthode qui est actuellement utilisée par les différents codes diffusés sur l’Internet dont le CERTA a connaissance.

Le CERTA préconise dans son alerte CERTA-2009-ALE-002, comme contournement provisoire, de désactiver l’interprétation du JavaScript dans les lecteurs PDF Adobe. Il y a deux raisons principales à cela :

  • cette opération empêche les codes actuellement connus d’exécuter du code à leur ouverture par une application vulnérable ;
  • il s’agit d’une bonne pratique générale, compte-tenu des risques associés au format PDF rencontrés depuis plusieurs mois.

Il faut noter que d’autres lecteurs semblent perturbés par un fichier ayant un flux JBIG2 particulier. A titre d’exemple, Aperçu sous Mac0S X se ferme inopinément, de même que xpdf ou kpdf sous certaines conditions. La possibilité d’exécuter du code arbitraire n’est pas encore vérifiée.

Foxit Reader n’est pas fourni par défaut avec le composant pour JPEG2000 et JBIG2, et de fait n’est pas vulnérable.

2.2 Les méthodes de détection

Les méthodes de détection ne sont pas triviales du fait de la complexité du format PDF. Plusieurs propriétés permettent à une personne malveillante de construire un fichier trompant la vigilance des outils de sécurité, ceux-ci n’ayant pas toutes les capacités d’interprétation d’un véritable lecteur (ou bien alors ils pourraient souffrir des mêmes vulnérabilités).

Un objet suspect peut apparaître dans le code source du fichier PDF en appelant le filtre JBIG2Decode comme :

<</Subtype/Image/Width xx/Height yy/ColorSpace/DeviceGray/BitsPerComponent 1
/Decode[1 0]/Interpolate true/Length zz/Filter/JBIG2Decode>>
stream

2.3 Documentation

3 Complément d’information sur l’autorun

A la date du 11 février 2009, le CERTA avait complété sa note d’information CERTA-2006-INF-006 liée au « Risques associés aux clés USB » et publié un avis sur une vulnérabilité affectant le mécanisme d’autorun de Microsoft Windows (cf. CERTA-2009-AVI-064).

La mise à jour de sécurité proposée par l’éditeur est depuis sa parution uniquement disponible en mise à jour automatique pour les systèmes d’exploitation Windows Vista et Windows Server 2008, comme le précise la section 3 du bulletin CERTA-2009-ACT-007.

Pour les autres systèmes d’exploitation, cette mise à jour devait être appliquée à l’initiative de l’utilisateur.

Depuis le 24 février 2009, ce correctif de sécurité, associé au numéro de la base de connaissances Microsoft KB967715, est disponible en mise à jour automatique pour les autres versions maintenues du système d’exploitation Windows.

Documentation

4 Vulnérabilité Mozilla Firefox

Cette semaine, un code d’exploitation permettant d’effectuer un déni de service à distance sur le navigateur Mozilla Firefox a été publié sur l’Internet. Cette vulnérabilité non corrigée n’a pas fait l’objet d’une alerte CERTA en raison du risque limité de cette faille. La fondation Mozilla est également restée muette à ce sujet pour l’instant. L’exploitation est très simple et rendue possible via le paramètre OnLoad de la balise BODY d’une page HTML. Le déni de service nécessite cependant que l’interprétation du JavaScript soit activée.

Il est important de garder à l’esprit que les navigateurs internet restent des applications critiques pour les machines des utilisateurs. Le CERTA rappelle donc quelques bonnes pratiques afin de limiter les risques de compromission d’une machine via le navigateur Internet :

  • naviguer avec un compte utilisateur aux droits limités ;
  • ne pas activer par défaut l’exécution de codes dynamiques (Flash, JavaScript, …) sur les sites qui ne sont pas de confiance ;
  • limiter et même bannir l’installation de modules complémentaires ou extensions ;
  • maintenir constamment à jour l’application et ses modules complémentaires.

5 Les TinyURL, de quoi s’agit il ?

Ce terme couramment utilisé est dérivé du premier site ayant offert le service en 2002, tinyurl.org. Il désigne maintenant un principe de redirection d’une adresse longue et complexe via une plus petite (Tiny). Cette technique est utilisée pour faciliter l’utilisation des URLs ou les rendre plus explicites. Par exemple :

www.monsite.tld/page.php?section=zdilksndifjz&page=13983&titre=MaPAGE
pourrait devenir :
www.siteDeRenommage.tld/IdMaPAGE

Ces petites adresses fonctionnent sur un principe d’association d’un identifiant unique (IdMaPage dans l’exemple) à une adresse. Lorsqu’un visiteur demande un identifiant, il est automatiquement redirigé vers la page associée. Si l’utilisation d’un tel procédé peut se justifier, il convient de se montrer prudent s’il repose sur un tiers pour gérer les associations.

En effet, plusieurs sites offrant ce service ont fermé, invalidant ainsi tous les liens reposant dessus. De plus, l’action, par l’internaute, d’interroger le site de redirection introduit un intermédiaire. Il est important de bien le connaître pour définir le niveau global de confiance de la connexion.

Comme il est possible d’associer plusieurs TinyURL à une même page, il est courant de voir ce service détourné par des attaquants susceptibles de l’utiliser pour multiplier les liens pointant sur un site malveillant (phishing ou autre). Cette solution leur permet d’éviter trop rapidement le blacklistage.

Si ce procédé doit être utilisé, le CERTA recommande de se reposer sur un tiers de confiance ou d’utiliser une solution locale. L’utilisateur ne pourra pas apporté la même confiance, dans tous les cas, à un lien réticulaire qui ne correspond pas à celui de forme prévisible et attendue.

Rappel des avis émis

Dans la période du 16 au 22 février 2009, le CERT-FR a émis les publications suivantes :