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

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité 2009-33

Gestion du document

Référence CERTA-2009-ACT-033
Titre Bulletin d’actualité 2009-33
Date de la première version 14 août 2009
Date de la dernière version 14 août 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 Élevation de privilège dans le noyau Linux

Une vulnérabilité a été récemment rendue publique. Elle concerne un déréférencement de pointeur NULL à la création de sockets pour quelques protocoles (PF_BLUETOOTH, PF_ISDN, PF_APPLETALK, PF_IRDA, PF_INET6 avec IPPROTO_SCTP, PF_PPOX, PF_IUCV, …). Les opérations non disponibles ne sont pas correctement gérées, en particulier par la fonction sock_sendpage.

La plupart des noyaux Linux actuels sont concernés par cette vulnérabilité (branche 2.4 y compris 2.4.37.4 et branche 2.6 y compris 2.6.30.4).

Le CERTA a publié à ce sujet l’avis CERTA-2009-AVI-337. Des correctifs pour chaque distribution devraient apparaître dans les prochains jours.

4.5 Documentation

2 Les bulletins mensuels de Microsoft

Cette semaine, Microsoft a publié ses bulletins mensuels de sécurité. Le CERTA revient sur ces différents bulletins :

  • MS09-036 : ce bulletin fait état d’une vulnérabilité dans l’environnement d’exécution Microsoft .NET Framework dans leurs versions 2.0 avec sans le service pack 1 ou 2 et 3.5 avec sans le service pack 1. Une gestion incorrecte des files de requêtes, lorsque Internet Information Services (IIS) 7.0 est installé, permet d’effectuer un déni de service lorsque ASP.NET est configuré pour utiliser le mode « intégré » et non le mode « classique » ;
  • MS09-037 : plusieurs vulnérabilités dans la bibliothèque ATL (Active Template Library), de Microsoft Windows permettent d’exécuter du code arbitraire à distance ;
  • MS09-038 : deux vulnérabilités dans le traitement de fichiers Windows Media permettent à une personne malintentionnée via un fichier AVI spécialement conçu d’exécuter du code arbitraire à distance ;
  • MS09-039 : deux erreurs dans Microsoft Windows Internet Name Service permettent à une personne malintentionnée d’exécuter du code arbitraire à distance via un paquet de réplication spécialement conçu envoyé au service WINS vulnérable ;
  • MS09-040 : un problème a été identifié dans le service, non activé par défaut, de mise en file d’attente MSMQ de Microsoft Windows. Le service vérifie de façon incorrecte les données en entrée avant de les transmettre au tampon et permet à un utilisateur d’élever ses privilèges ;
  • MS09-041 : une vulnérabilité a été identifiée dans le Service Station de Travail de Microsoft Windows. Celui-ci alloue et libère la mémoire de manière incorrecte lors de la réception de messages RPC spécialement conçus. L’exploitation de cette vulnérabilité permet d’exécuter du code arbitraire avec des privilèges élevés ;
  • MS09-042 : le service Telnet ne souscrit pas correctement aux protections contre la réflexion des informations d’identification NTLM. Une exécution de code arbitraire est possible via cette vulnérabilité ;
  • MS09-043 : un ensemble de contrôles COM (Component Object Model) utilisés pour la publication de feuilles de calcul, de graphiques et de bases de données sur le Web ainsi que pour l’affichage de composants publiés sur le Web sont vulnérables et permettent une exécution de code arbitraire à distance. Ce correctif clôt l’alerte CERTA-2009-ALE-011 ;
  • MS09-044 : deux vulnérabilités ont été identifiées dans la Connexion Bureau à distance de Microsoft Windows. La première est due aux paramètres renvoyés par le serveur RDP qui ne sont pas correctement traités. La seconde concerne le contrôle ActiveX du client. Dans les deux cas, seuls les clients RDP sont donc affectés et une exécution de code arbitraire à distance est possible.

Le CERTA rappelle l’impérative nécessité d’appliquer au plus vite ces correctifs afin de protéger son système d’information.

Documentation

3 Administrer Adobe Flash sur un poste Windows

3.1 Introduction

Le CERTA a publié dans le courant du mois de juillet l’alerte CERTA-2009-ALE-013 concernant Adobe Shockwave Flash. D’autres vulnérabilités avaient fait l’objet en mars 2009 de l’avis CERTA-2009-AVI-076.

Le CERTA a traité cette semaine un incident relatif à une compromission associée à l’exploitation de l’une de ces vulnérabilités. Des codes circulent actuellement, insérés dans des pages Web de sites Internet ou dans des documents au format PDF.

Le CERTA revient donc dans les sections suivantes sur quelques pratiques associées avec cette application.

3.2 Quelques précisions utiles

Adobe Flash Player se présente sous la forme d’un module (ou plugin) pour navigateur Internet. Il permet d’interpréter des contenus de type vidéo ou animation aux formats SWF (Shockwave Flash) ou FLV (Flash Video).

L’installation n’est cependant pas unique sur chaque machine. Elle peut être effectuée sous une forme ActiveX par exemple pour Internet Explorer et comme module additionnel dans un autre navigateur (Mozilla Firefox, Safari, etc.). Une machine peut donc avoir plusieurs installations distinctes d’Adobe Flash, avec des configurations et des niveaux de mises à jour propres.

Pour connaître les versions actuellement utilisées, il existe deux méthodes :

  • en ligne, en visitant pour un navigateur donné une page comme : 
    http://www.adobe.com/software/Flash/about/
    S’il y a plusieurs navigateurs installés, il faut doncréitérer l’opération (par exemple Internet Explorer puis Firefox).
  • hors ligne, en cherchant l’information dans la configuration même du navigateur :
    • Sous Internet Explorer : clic droit sur l’icône d’IE et sélection de « Propriétés », puis ouverture de l’onglet « Programmes » et de l’option « Gérer les modules complémentaires » ;
    • Sous Firefox : l’adresse « about:plugins » dans la barre d’adressage retourne la liste des modules installés ;
    • Sous Safari : sélection de l’onglet « Modules installés » dans le menu « Aide » ;
    • Sous Opera : le navigateur ne retourne pas la version précise, mais seulement sa présence en interrogeant « opera:plugins » dans la barre de navigation.

Pour conclure cette section, le CERTA tient également à rappeler que les lecteurs Adobe Flash installés sur une machine ne sont pas configurables de manière simple. La seule méthode proposée par Adobe se fait en mode connecté, en se rendant avec un navigateur sur une page donnée du site Internet d’Adobe. C’est à partir de celle-ci qu’une interface de configuration est possible.

La page d’accueil se trouve à l’adresse :

http://www.macromedia.com/support/documentation/fr/flashplayer/help/settings_manager.html

Le CERTA avait longuement abordé la problématique des fichiers de session propres à Adobe, aussi appelés Local Shared Objects ou LSO dans le bulletin d’actualité CERTA-2008-ACT-034. Les paramètres de configuration se trouvent dans un fichier au même format, settings.sol et peuvent être modifiés localement avec un éditeur adapté.

Enfin, toutes les mesures citées ci-dessous s’appliquent au lecteur Adobe Flash mais restent valables pour le lecteur Adobe Shockwave.

3.3 Procédures de mises à jour

3.3.1 En ligne

Il faut utiliser l’une des pages de l’interface de configuration en ligne Adobe :

http://www.macromedia.com/support/documentation/fr/flashplayer/help/settings_manager05.html

Il est possible de préciser dans cette interface :

  • un avertissement doit être émis si une nouvelle mise à jour est disponible ;
  • la fréquence de vérification des mises à jour. La valeur par défaut, de 14 ou 30 jours, est excessive. La valeur la plus petite proposée est de 7 jours. L’interface permet de l’augmenter au maximum à 7 jours. Cela reste trop important dans les faits, étant donné que des codes d’exploitation apparaissent très rapidement après des mises à jour, voire avant dans les cas les plus récents.

Le CERTA recommande vivement de ne pas se reposer sur le fonctionnement de mise à jour automatique du lecteur Adobe Flash Player. En cas de vulnérabilité critique, une mise à jour manuelle s’impose.

3.3.2 Hors-ligne

Il faut pour cela télécharger préalablement la nouvelle version du lecteur Adobe Flash sur le site officiel. L’installation peut se faire sur un poste déconnecté. La nouvelle version se charge de désinstaller l’ancienne. Il est néanmoins conseillé de vérifier après cette opération par les procédures précédentes que le changement est effectif.

3.4 Procédures de désinstallation

Les accès hors-ligne présentés dans la section précédente pour déterminer la version du module Adobe Flash installé permettent, au mieux, selon les navigateurs, de désactiver le module. Il n’est pas possible, via la configuration du navigateur, de désinstaller complètement l’application.

Pour le système d’exploitation Microsoft Windows, il est possible :

  • de désinstaller l’application via l’option « Ajout/Suppression de programmes » du système d’exploitation ;
  • de lancer manuellement les programmes de désinstallation fournis par Adobe qui se trouvent sous une des formes suivantes :
    • %WINDIR%\

      3.5 Mesures préventives

      Les mesures citées dans cette section ne sont pas absolues mais permettent de limiter certains risques liés aux contenus de format Flash sur les postes. Il ne s’agit donc ici que de quelques pistes envisageables.

      Une mesure consiste à utiliser des navigateurs avec des configurations distinctes : l’une d’elles restrictive, n’interprète par défaut aucun code particulier dynamique suite à la visite d’une page. La seconde, plus laxiste, permet d’activer cette interprétation, de manière ponctuelle, pour des sites de confiance. Cette procédure peut être aussi appliquée en créant pour un même utilisateur plusieurs profils (Mozilla Firefox).

      Une autre mesure consiste à utiliser des lecteurs Flash alternatifs en fonction du système d’exploitation et des navigateurs :

      • Projet Gnash (http://www.gnashdev.org)
      • Swfdec (http://swdec.freedesktop.org/)
      • Gameswf Library (http://tulrich.com/textweb.pl?path=geekstuff/gameswf.txt)
      • Flirt (non mis à jour depuis 2006 – http://flirt.sourceforge.net/)

      Ils n’interprètent cependant pas toutes les particularités du format Flash, mal documenté à l’heure actuelle.

      Des modules pour certains navigateurs (ex : Firefox – flashblock, noscript, prefbar, etc.), permettent enfin de bloquer par défaut des contenus Flash sauf autorisation explicite de l’utilisateur. Cette approche repose sur ce nouveau module qui devient de fait une nouvelle surface d’attaque. Il faut donc avoir confiance dans ce dernier (mises à jour fréquentes, code audité, etc.) avant de le déployer.

      Enfin, les développeurs de sites Web comprendront ici qu’il n’est pas conseillé de développer un site Web intégralement en Flash sous peine de pénaliser nombre de visiteurs qui ne souhaitent pas installer ou activer un tel module. Un site Web doit être par défaut lisible et accessible par tout navigateur, sans forcer l’utilisateur à installer contre son gré des modules tiers.

      3.6 Documentation associée

      4 Serveurs mandataires malveillants et HTTPS

      L’objectif de cet article est d’aborder la problématique des serveurs mandataires pour les connexions en HTTPS. En effet, s’agissant d’un protocole cryptographique de bout en bout, la présence d’intermédiaires non de confiance ne devrait pas poser de problème. Voyons ici comment ces Pretty-Bad-Proxy (PBP) peuvent être utilisés pour mener des attaques.

      4.1 Définition du Pretty-Bad-Proxy

      Il s’agit d’un serveur mandataire web (proxy) utilisé pour mener des attaques de type « man in the middle ». Il a accès au trafic brut, mais ne pouvant décrypter le flux HTTPS, il utilise le canal clair associé (HTTP) pour injecter du contenu malveillant et tenter d’accéder à des données sensibles.

      4.2 Quelques principes

      4.2.1 Same Origin Policy (SOP)

      Il s’agit d’une sécurité consistant à cloisonner les contenus (pages, scripts, …) afin d’éviter les interactions. Par exemple, la page d’un site A n’a pas à accéder aux identifiants saisis sur la page d’un site B. L’origine est déterminée par trois critères, le protocole, le nom du serveur et le port. Ainsi, http://unserveur.tld n’a pas la même origine que https://unserveur.tld. Il est intéressant de remarquer que les scripts n’ont pas d’origine propre, mais celle du cadre ou de la page qui les contient.

      4.2.2 HTTPS et proxy

      HTTPS est un protocole bout-en-bout, ce qui est contraire au principe du serveur mandataire qui s’intercale dans le flux. Pour réussir à établir une connexion sécurisée au travers d’un proxy il faut utiliser le mécanisme de tunnel. Pour cela, le client envoie une première requête HTTP au proxy annonçant le serveur final, et le port, avec lequel il désire établir la session. Le proxy va alors ouvrir et maintenir deux connexions, l’une vers le client, l’autre vers le serveur et servira de relais passif pour le trafic HTTPS.

      4.3 Les problèmes

      4.3.1 Les réponses d’erreur

      Lorsque l’utilisateur demande la page (https://unepage.tld), le navigateur émet de façon transparente une requête HTTP à destination du proxy. Si ce dernier ne trouve pas la page en question, il retourne une erreur HTTP (ex: 404) qui est interprétée dans le contexte de https://unepage.tld. Un proxy malveillant peut donc volontairement répondre une page d’erreur contenant un script malveillant qui aura accès aux données du site sécurisé initialement demandé.

      4.3.2 Les redirections et l’absence d’origine des scripts

      Les pages importent souvent des scripts depuis plusieurs sources. Chacun des scripts externes nécessite une requête à destination du proxy suivant le même schéma, à savoir, une première requête en HTTP afin de définir le tunnel désiré, puis l’établissement de la connexion sécurisée. À la première requête, le proxy peut répondre que le site a été déplacé (message 3xx), et faire établir le tunnel avec un autre serveur. Comme les scripts n’ont pas d’origine propre, ils seront exécutés dans le contexte du cadre qui a fait l’import et qui est bien celui du site sécurisé.

      4.3.3 Les pages accessibles en HTTPS

      Alors que le HTTPS est utilisé pour des transactions sécurisées et le HTTP pour tout le reste, il arrive souvent que les pages non sensibles soient aussi accessibles via HTTPS, elles portent le nom de « HPIHSL » (HTTP-intended-but-HTTPS-loadable). Donc, lorsqu’une page en clair est demandée (ex: http://unsite.tld), le PBP peut insérer une IFRAME qui a comme source une page non sensible du même site (iframe src=https://unsite.tld/pagenonsensible.html). Mais demandée via HTTPS et elle-même important un script en HTTP, ce dernier est demandé en clair. Le proxy peut alors le remplacer par un autre, et n’ayant pas d’origine propre, il aura celle de l’IFRAME. Comme le cadre principal a comme origine HTTP, le fait d’accéder à du HTTP dans une IFRAME, elle-même en HTTPS, n’engendre pas d’alerte.

      4.3.4 La mise en cache des certificats

      Afin d’optimiser les performances, les navigateurs mettent en cache les certificats. Un PBP peut utiliser ce fonctionnement pour servir ses propres pages et apparaître comme sûr (affichage du cadenas). Lorsqu’une page sécurisée est demandée (via HTTP dans un premier temps), le PBP répond par une page d’erreur (4xx ou 5xx) qui contient un élément pointant vers le site sécurisé (par exemple une image) et un méta élément qui forcera le rechargement de la page quelques instants plus tard. L’élément pointant vers le site sécurisé va provoquer l’établissement de la connexion sécurisée, et donc la mise en cache du certificat. Lorsque la page se recharge, le PBP répond par une page imitant le site sécurisé demandé (toujours au moyen d’une erreur). Le contexte étant celui du site visé et le certificat étant en cache, la page apparait comme certifiée. Cela ne fonctionne cependant pas avec tous les navigateurs mais cette technique a l’avantage de ne pas utiliser de script.

      4.3.5 Same Origin Policy pour les cookies

      Les cookies sont des chaînes de caractères utilisés, entre autres, pour maintenir des sessions ouvertes. Le problème est que l’origine des cookies ne tient pas compte du protocole. Une page de http://unsite.tld pourra accéder aux cookies de https://unsite.tld. Pour empêcher cela le serveur doit utiliser l’attribut SECURE du cookie. Dans les faits, une grande proportion de sites dit « sécurisés » ne le font pas. Lorsqu’un utilisateur est connecté à un site « sécurisé » de la sorte, le PBP n’a qu’à attendre que la victime demande n’importe quelle page en HTTP de n’importe quel serveur pour y injecter une IFRAME malveillante. Cette dernière ayant comme source l’adresse du site sécurisé en HTTP, les cookies d’authentification circuleront en clair et seront interceptables par le PBP.

      4.4 Conclusion

      Le CERTA recommande de désactiver l’utilisation automatique des serveurs mandataires non maîtrisés. En particulier, il convient de rester prudent lors de la navigation depuis un lieu public (réseau d’hôtel, accès WiFi public, cybercafé, …).

      4.5 Documentation

Rappel des avis émis

Dans la période du 03 au 09 août 2009, 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 14 août 2009
    version initiale.