Bulletin de sécurité Microsoft MS12-074 - Critique

Une atténuation fait référence à un paramètre, une configuration générale ou à des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Tout attaquant parvenant à exploiter cette vulnérabilité pourrait obtenir les mêmes droits que l'utilisateur. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.
• Par défaut, Internet Explorer 9 et Internet Explorer 10 empêchent XAML, utilisé par les XBAP, de s'exécuter dans la zone Internet.
• Par défaut, Internet Explorer 6, Internet Explorer 7 et Internet Explorer 8 sont configurés pour demander confirmation à l'utilisateur avant d'exécuter XAML, utilisé par les XBAP, dans la zone Internet.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Désactiver les applications du navigateur XAML dans Internet Explorer

  Pour vous protéger contre cette vulnérabilité, modifiez vos paramètres de manière à ce qu'ils vous avertissent avant d'exécuter les applications du navigateur XAML (XBAP) ou qu'ils désactivent les XBAP dans les zones de sécurité Internet et Intranet local comme suit :

  1. Dans Internet Explorer, cliquez sur le menu Outils, puis sélectionnez Options Internet.
  2. Cliquez sur l'onglet Sécurité, sur Internet, puis sur Personnaliser le niveau. Sous Paramètres, pour XAML isolé, cliquez sur Demander ou Désactivé, puis cliquez sur OK.
  3. Cliquez sur l'onglet Sécurité, sur Internet, puis sur Personnaliser le niveau. Sous Paramètres, pour Applications du navigateur XAML, cliquez sur Demander ou Désactivé, puis cliquez sur OK.
  4. Cliquez sur l'onglet Sécurité, sur Internet, puis sur Personnaliser le niveau. Sous Paramètres, pour Documents XPS, cliquez sur Demander ou Désactivé, puis cliquez sur OK.
  5. Dans l'onglet Sécurité, cliquez sur Personnaliser le niveau. Sous composants dépendants du .NET Framework, définissez Exécuter des composants non signés avec Authenticode sur Demander ou Désactiver, puis cliquez sur OK. Répétez ces étapes pour Exécuter des composants signés avec Authenticode, puis cliquez sur OK.
  6. Cliquez sur Intranet local, puis sur Personnaliser le niveau. Répétez les étapes 3 et 4. Si vous êtes invité à confirmer la modification de ces paramètres, cliquez sur Oui. Cliquez sur OK pour retourner dans Internet Explorer.

  Impact de cette solution de contournement. Le code Microsoft .NET ne s'exécutera pas dans Internet Explorer ou ne s'exécutera pas sans invite. La désactivation des applications et des composants Microsoft .NET dans les zones de sécurité Intranet local et Internet risque de perturber le fonctionnement de certains sites Web. Si vous rencontrez des difficultés lors de la visite d'un site Web après avoir modifié ce paramètre et que vous êtes certain de la fiabilité de ce site, vous pouvez ajouter ce dernier à votre liste de sites de confiance. Il pourra ainsi s'afficher correctement.

  Ajouter des sites de confiance à la zone Sites de confiance d'Internet Explorer.

  Après avoir configuré Internet Explorer pour que les applications de navigateur XAML soient désactivées ou que des messages de confirmation s'affichent avant l'exécution de XAML isolé, des applications du navigateur XAML ou des documents XPS dans les zones Internet et Intranet local, vous pouvez ajouter des sites de confiance dans la zone Sites de confiance d'Internet Explorer. Cette opération vous permettra de continuer à utiliser vos sites de confiance exactement comme vous le faites aujourd'hui, tout en vous protégeant contre cette attaque sur les autres sites. Nous vous recommandons d'ajouter uniquement des sites de confiance à la zone Sites de confiance.

  Pour ce faire, procédez ainsi :

  1. Dans Internet Explorer, cliquez sur Outils, sur Options Internet, puis sur l'onglet Sécurité.
  2. Dans la zone Sélectionnez une zone de contenu Web pour spécifier ses paramètres de sécurité, cliquez sur Sites de confiance, puis sur Sites.
  3. Si vous souhaitez ajouter des sites qui ne requièrent pas un canal chiffré, désactivez la case à cocher Nécessite un serveur sécurisé (https:) pour tous les sites dans cette zone.
  4. Dans la zone Ajouter ce site Web à la zone, saisissez l'URL d'un site de confiance, puis cliquez sur Ajouter.
  5. Répétez ces étapes pour chaque site que vous souhaitez ajouter à cette zone.
  6. Cliquez sur OK à deux reprises pour accepter les modifications et retourner dans Internet Explorer.

  Remarque : Ajoutez les sites dont vous savez qu'ils n'effectueront pas d'action malveillante sur votre système. Vous pouvez notamment ajouter les sites « *.windowsupdate.microsoft.com » et « *.update.microsoft.com ». Il s'agit des sites qui hébergent la mise à jour et ils requièrent un contrôle ActiveX pour leur installation.

  Comment annuler cette solution de contournement. Exécutez les étapes suivantes :

  1. Dans Internet Explorer, cliquez sur le menu Outils, puis sélectionnez Options Internet.
  2. Cliquez sur l'onglet Sécurité, sur Rétablir toutes les zones au niveau par défaut, puis sur OK.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité d'élévation de privilèges.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité est due au fait que .NET Framework valide de façon incorrecte les autorisations d'objets exécutant la réflexion.

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait prendre le contrôle intégral du système affecté. Il pourrait alors installer des programmes, afficher, modifier ou supprimer des données ou créer de nouveaux comptes dotés de tous les privilèges.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Il existe deux scénarios d'attaque possibles permettant d'exploiter cette vulnérabilité : un scénario de navigation Web et un contournement des restrictions de sécurité d'accès du code (CAS) par l'application Windows .NET. Ces scénarios sont décrits comme suit :

• Scénario d'attaque de navigation Web
  Un attaquant pourrait héberger un site Web spécialement conçu contenant une XBAP (application du navigateur XAML) spécialement conçue et pouvant exploiter cette vulnérabilité, puis convaincre un utilisateur d'afficher le site Web. L'attaquant pourrait également exploiter des sites Web compromis et des sites Web qui acceptent ou hébergent du contenu ou des annonces fournis par les utilisateurs. Ces sites Web pourraient contenir du code spécialement conçu pour exploiter cette vulnérabilité. Cependant, l'attaquant n'aurait aucun moyen de forcer l'utilisateur à visiter ces sites Web. Il devrait y attirer l'utilisateur, généralement en l'incitant à cliquer sur un lien dans un message électronique ou un message instantané qui mène à son site. Il pourrait également afficher du contenu Web spécialement conçu en imitant des bannières publicitaires ou d'autres moyens afin d'envoyer du contenu Web aux systèmes affectés.
• Scénario d'attaque d'applications Windows .NET
  Cette vulnérabilité pourrait également être utilisée par des applications Windows .NET Framework pour contourner les restrictions de sécurité d'accès du code (CAS).

Qu'est-ce que le CLR ? 
Microsoft .NET Framework fournit un environnement d'exécution appelé Common Language Runtime (CLR), qui exécute le code et fournit des services qui facilitent le processus de développement. Pour plus d'informations sur le CLR, consultez la Présentation du service CLR (en anglais).

Qu'est-ce qu'une application du navigateur XAML (XBAP) ? 
Une application du navigateur XAML (XBAP) combine des fonctionnalités d'une application Web et d'une application cliente riche. Comme les applications Web, les XBAP peuvent être publiées sur un serveur Web et lancées à partir d'Internet Explorer. Comme les applications clientes riches, les XBAP peuvent tirer parti des capacités de Windows Presentation Foundation (WPF). Pour plus d'informations à propos des XBAP, consultez l'article MSDN « Vue d'ensemble des applications du navigateur XAML Windows Presentation Foundation ».

Que sont les restrictions de sécurité d'accès du code (CAS) .NET Framework ? 
.NET Framework fournit un mécanisme de sécurité appelé sécurité d'accès du code pour protéger vos ordinateurs du code mobile malveillant, permettre à un code d'origine inconnue d'être exécuté avec une certaine protection et empêcher le code de confiance de compromettre accidentellement ou intentionnellement la sécurité. La sécurité d'accès du code (CAS) permet différents degrés de confiance du code, en fonction de son origine et des autres aspects de l'identité du code. La sécurité d'accès du code applique également les divers niveaux de confiance au code, ce qui réduit la quantité de code nécessitant une confiance totale pour être exécuté. L'utilisation de la sécurité d'accès du code peut diminuer le risque d'utilisation détournée de votre code par un code malveillant ou rempli d'erreur. Pour plus d'informations sur la sécurité d'accès du code, consultez l'article MSDN « Sécurité d'accès du code ».

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Il existe deux types de systèmes exposés à cette vulnérabilité, décrits comme suit : les systèmes qui utilisent le scénario de navigation Web et ceux qui utilisent le scénario d'applications Windows .NET Framework.

• Scénario de navigation Web
  Le succès de l'exploitation de cette vulnérabilité nécessite qu'un utilisateur ait ouvert une session et visite des sites Web à l'aide d'un navigateur Web capable d'instancier les XBAP. C'est pourquoi les systèmes sur lesquels un navigateur Web est fréquemment utilisé (tels que les postes de travail ou les serveurs Terminal Server) sont les plus exposés à cette vulnérabilité. Les serveurs pourraient être plus exposés si les administrateurs autorisent les utilisateurs à naviguer sur Internet et à consulter leur messagerie électronique depuis ceux-ci. Néanmoins, les meilleures pratiques recommandent fortement de ne pas autoriser cela.
• Applications Windows .NET
  Les postes de travail et les serveurs qui exécutent des applications Windows .NET Framework non fiables sont également exposés à cette vulnérabilité.

Que fait cette mise à jour ? 
Cette mise à jour corrige la vulnérabilité en modifiant la façon dont .NET Framework valide les autorisations d'objets exécutant la réflexion.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Microsoft n'a identifié aucun facteur atténuant pour cette vulnérabilité.

Microsoft n'a identifié aucune solution de contournement pour cette vulnérabilité.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité de divulgation d'informations.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité est générée lorsque .NET Framework ne parvient pas à nettoyer correctement la sortie d'une fonction lorsque celle-ci est appelée à partir d'un code partiellement fiable.

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Dans un scénario de navigation Web, un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait utiliser du code partiellement fiable pour obtenir des informations confidentielles contenues sur le système cible qui seraient en temps normal uniquement accessibles par du code complètement fiable.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Il existe deux scénarios d'attaque possibles permettant d'exploiter cette vulnérabilité : un scénario de navigation Web et un contournement des restrictions de sécurité d'accès du code (CAS) par l'application Windows .NET. Ces scénarios sont décrits comme suit :

• Scénario d'attaque de navigation Web
  Un attaquant pourrait héberger un site Web spécialement conçu contenant une XBAP (application du navigateur XAML) spécialement conçue et pouvant exploiter cette vulnérabilité, puis convaincre un utilisateur d'afficher le site Web. L'attaquant pourrait également exploiter des sites Web compromis et des sites Web qui acceptent ou hébergent du contenu ou des annonces fournis par les utilisateurs. Ces sites Web pourraient contenir du code spécialement conçu pour exploiter cette vulnérabilité. Cependant, l'attaquant n'aurait aucun moyen de forcer l'utilisateur à visiter ces sites Web. Il devrait y attirer l'utilisateur, généralement en l'incitant à cliquer sur un lien dans un message électronique ou un message instantané qui mène à son site. Il pourrait également afficher du contenu Web spécialement conçu en imitant des bannières publicitaires ou d'autres moyens afin d'envoyer du contenu Web aux systèmes affectés.
• Scénario d'attaque d'applications Windows .NET
  Cette vulnérabilité pourrait également être utilisée par des applications Windows .NET Framework pour contourner les restrictions de sécurité d'accès du code (CAS).

Qu'est-ce que le CLR ? 
Microsoft .NET Framework fournit un environnement d'exécution appelé Common Language Runtime (CLR), qui exécute le code et fournit des services qui facilitent le processus de développement. Pour plus d'informations sur le CLR, consultez la Présentation du service CLR (en anglais).

Qu'est-ce qu'une application du navigateur XAML (XBAP) ? 
Une application du navigateur XAML (XBAP) combine des fonctionnalités d'une application Web et d'une application cliente riche. Comme les applications Web, les XBAP peuvent être publiées sur un serveur Web et lancées à partir d'Internet Explorer. Comme les applications clientes riches, les XBAP peuvent tirer parti des capacités de Windows Presentation Foundation (WPF). Pour plus d'informations à propos des XBAP, consultez l'article MSDN « Vue d'ensemble des applications du navigateur XAML Windows Presentation Foundation ».

Que sont les restrictions de sécurité d'accès du code (CAS) .NET Framework ? 
.NET Framework fournit un mécanisme de sécurité appelé sécurité d'accès du code pour protéger vos ordinateurs du code mobile malveillant, permettre à un code d'origine inconnue d'être exécuté avec une certaine protection et empêcher le code de confiance de compromettre accidentellement ou intentionnellement la sécurité. La sécurité d'accès du code (CAS) permet différents degrés de confiance du code, en fonction de son origine et des autres aspects de l'identité du code. La sécurité d'accès du code applique également les divers niveaux de confiance au code, ce qui réduit la quantité de code nécessitant une confiance totale pour être exécuté. L'utilisation de la sécurité d'accès du code peut diminuer le risque d'utilisation détournée de votre code par un code malveillant ou rempli d'erreur. Pour plus d'informations sur la sécurité d'accès du code, consultez l'article MSDN « Sécurité d'accès du code ».

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Il existe deux types de systèmes exposés à cette vulnérabilité, décrits comme suit : les systèmes qui utilisent le scénario de navigation Web et ceux qui utilisent le scénario d'applications Windows .NET Framework.

• Scénario de navigation Web
  Le succès de l'exploitation de cette vulnérabilité nécessite qu'un utilisateur ait ouvert une session et visite des sites Web à l'aide d'un navigateur Web capable d'instancier les XBAP. C'est pourquoi les systèmes sur lesquels un navigateur Web est fréquemment utilisé (tels que les postes de travail ou les serveurs Terminal Server) sont les plus exposés à cette vulnérabilité. Les serveurs pourraient être plus exposés si les administrateurs autorisent les utilisateurs à naviguer sur Internet et à consulter leur messagerie électronique depuis ceux-ci. Néanmoins, les meilleures pratiques recommandent fortement de ne pas autoriser cela.
• Applications Windows .NET
  Les postes de travail et les serveurs qui exécutent des applications Windows .NET Framework non fiables sont également exposés à cette vulnérabilité.

Que fait cette mise à jour ? 
Cette mise à jour corrige la vulnérabilité en nettoyant correctement la sortie en fonction du niveau de confiance du code appelant.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Une atténuation fait référence à un paramètre, une configuration générale ou à des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Le protocole de partage de fichiers, SMB (Server Message Block), est souvent désactivé sur le pare-feu de périmètre. Cela permet de limiter les vecteurs d'attaque potentiels pour cette vulnérabilité.
• Un attaquant parvenant à exploiter cette vulnérabilité pourrait obtenir les mêmes droits que l'utilisateur connecté. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Désactiver le chargement de bibliothèques à partir de partages réseau WebDAV et distants

  Remarque : Consultez l'Article 2264107 de la Base de connaissances Microsoft pour déployer un outil de contournement qui permet aux clients de désactiver le chargement de bibliothèques à partir de partages réseau et WebDAV distants. Cet outil peut être configuré pour rejeter le chargement non sécurisé de manière globale ou par application.

  Les clients informés par leur fournisseur d'une application vulnérable peuvent utiliser cet outil pour se protéger contre les tentatives d'exploitation de ce problème.

  Remarque : Consultez l'Article 2264107 de la Base de connaissances Microsoft pour utiliser la solution automatisée Fix it de Microsoft pour déployer la clé de Registre permettant de bloquer le chargement de bibliothèques pour les partages SMB et WebDAV. Notez que cette solution Fix it nécessite l'installation préalable de l'outil de contournement également décrit dans l'Article 2264107 de la Base de connaissances Microsoft. Cette solution Fix it déploie uniquement la clé de Registre et nécessite l'outil de contournement pour être efficace. Nous recommandons aux administrateurs de consulter l'article de la Base de connaissances de près avant de déployer cette solution Fix it.

• Désactiver le service WebClient

  La désactivation du service WebClient permet de protéger les systèmes affectés des tentatives d'exploitation de cette vulnérabilité en bloquant le vecteur d'attaque à distance le plus courant via le service client WebDAV (Web Distributed Authoring and Versioning). Après avoir appliqué cette solution de contournement, il est toujours possible pour les attaquants distants qui parviennent à exploiter cette vulnérabilité de forcer le système à exécuter des programmes situés sur l'ordinateur de l'utilisateur ciblé ou sur le réseau local (LAN), mais les utilisateurs seront invités à confirmer avant l'ouverture de programmes arbitraires à partir d'Internet.

  Pour désactiver le service WebClient, procédez comme suit :

  1. Cliquez sur Démarrer, puis sur Exécuter, tapez « Services.msc » puis cliquez sur OK.
  2. Cliquez avec le bouton droit sur Service WebClient et sélectionnez Propriétés.
  3. Définissez le type de démarrage sur Désactivé. Si le service s'exécute, cliquez sur Arrêter.
  4. Cliquez sur OK et quittez la console de gestion.

  Impact de cette solution de contournement. La désactivation du service WebClient empêche la transmission des requêtes WebDAV (Web Distributed Authoring and Versioning). Par ailleurs, les services qui en dépendent explicitement ne démarreront pas et un message d'erreur sera consigné dans le journal des événements système. Par exemple, les partages WebDAV seront inaccessibles à partir de l'ordinateur client.

  Comment annuler cette solution de contournement.

  Pour réactiver le service WebClient, procédez comme suit :

  1. Cliquez sur Démarrer, puis sur Exécuter, tapez « Services.msc » puis cliquez sur OK.
  2. Cliquez avec le bouton droit sur Service WebClient et sélectionnez Propriétés.
  3. Définissez le type de démarrage sur Automatique. Si le service ne s'exécute pas, cliquez sur Démarrer.
  4. Cliquez sur OK et quittez la console de gestion.
• Bloquer les ports TCP 139 et 445 au niveau du pare-feu

  Ces ports servent à établir une connexion au composant affecté. En bloquant les ports TCP 139 et 445 au niveau du pare-feu, vous protégerez les systèmes situés derrière ce pare-feu des tentatives d'exploitation de cette vulnérabilité. Microsoft vous recommande de bloquer toute communication entrante non sollicitée en provenance d'Internet, afin de renforcer la protection contre des attaques qui pourraient utiliser les autres ports. Pour obtenir plus d'informations sur les ports, consultez l'article TechNet consacré aux affectations de port TCP et UDP (en anglais).

  Impact de cette solution de contournement. Plusieurs services Windows utilisent ces ports. Bloquer ces ports peut entraîner un dysfonctionnement de certaines applications ou services. Certaines applications pouvant être affectées sont répertoriées ci-dessous :

  • Applications qui utilisent SMB (CIFS)
  • Applications utilisant des mailslots ou des canaux nommés (named pipes) (RPC sur SMB)
  • Serveur (Partage de fichier et d'impression)
  • Stratégie de groupe
  • Ouverture de session réseau
  • Système de fichiers distribués (DFS)
  • Gestion de licences Terminal Server
  • Spouleur d'impression
  • Explorateur d'ordinateur
  • Localisateur d'appels de procédure distante (RPC)
  • Service de télécopie
  • Service d'indexation
  • Journaux et alertes de performances
  • Systems Management Server
  • Service d'enregistrement de licence

  Comment annuler cette solution de contournement. Autorisez les ports TCP 139 et 445 au niveau du pare-feu. Pour plus d'informations sur les ports, consultez l'article consacré aux affectations de port TCP et UDP (en anglais).

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité d'exécution de code à distance.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité survient lorsqu'Entity Framework, un composant de .NET Framework, limite de façon incorrecte le chemin utilisé pour le chargement des bibliothèques externes.

Qu'est-ce qu'Entity Framework ?  
Entity Framework est un jeu de technologies dans ADO.NET qui prend en charge le développement d'applications logicielles orientées données. Pour plus d'informations, consultez l'article MSDN « Vue d'ensemble d'Entity Framework ».

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Un attaquant pourrait exécuter du code arbitraire dans le contexte de l'utilisateur connecté. Il pourrait alors installer des programmes, afficher, modifier ou supprimer des données ou créer de nouveaux comptes dotés de tous les privilèges. Si un utilisateur est connecté avec des privilèges d'administrateur, un attaquant pourrait prendre le contrôle intégral du système affecté. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Un attaquant pourrait persuader un utilisateur d'ouvrir une application .NET légitime conçue avec ADO.NET et située dans le même répertoire réseau qu'un fichier de bibliothèque de liens dynamiques (DLL) spécialement conçu. L'application .NET pourrait alors tenter de charger le fichier DLL et d'exécuter le code qu'il contient.

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Les postes de travail et les serveurs Terminal Server sont les plus exposés. Les serveurs pourraient être plus exposés si les administrateurs autorisent les utilisateurs à ouvrir une session sur ces serveurs et à y exécuter des programmes. Néanmoins, les meilleures pratiques recommandent fortement de ne pas autoriser cela.

Que fait cette mise à jour ? 
Cette mise à jour corrige la vulnérabilité en modifiant la façon dont .NET Framework charge les bibliothèques externes.

Cette vulnérabilité est-elle liée à l'Avis de sécurité Microsoft 2269637 ? 
Oui, cette vulnérabilité est liée à la classe de vulnérabilités décrite dans l'Avis de sécurité Microsoft 2269637 qui affecte la façon dont les applications chargent les bibliothèques externes. Cette mise à jour de sécurité corrige une instance particulière de ce type de vulnérabilité.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Une atténuation fait référence à un paramètre, une configuration générale ou à des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Tout attaquant parvenant à exploiter cette vulnérabilité pourrait obtenir les mêmes droits que l'utilisateur. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Configurer Internet Explorer pour ne pas utiliser WPAD
  1. Cliquez sur Démarrer, Panneau de configuration, Réseau et Internet puis Options Internet.
  2. Dans la fenêtre Propriétés Internet, cliquez sur l'onglet Connexions, puis sur Paramètres réseau.
  3. Dans la fenêtre Paramètres du réseau local, décochez la case Détecter automatiquement les paramètres de connexion, puis cliquez sur OK.

  Impact de cette solution de contournement. La découverte automatique de proxy Web sera désactivée dans Internet Explorer.

  Comment annuler cette solution de contournement. Suivez les étapes ci-dessus dans l'ordre inverse, en veillant à ce que la case Détecter automatiquement les paramètres de connexion soit cochée dans la fenêtre Paramètres du réseau local.

   

• Enregistrer WPAD

  Suivez les étapes fournies dans l'Article 934864 de la Base de connaissances Microsoft pour enregistrer WPAD.

  Impact de cette solution de contournement. WPAD sera enregistré par un administrateur avant qu'un attaquant n'ait une opportunité de le faire.

  Comment annuler cette solution de contournement. Pour plus d'informations, consultez l'Article 934864 de la Base de connaissances Microsoft.

   

• Ne pas compter sur les paramètres de proxy Web par défaut dans votre application .NET

  Ne comptez pas sur les paramètres de proxy .NET par défaut, que ce soit explicitement, via la propriété WebRequest.DefaultWebProxy, ou implicitement, en ne définissant pas le proxy (comme indiqué ci-dessous) dans votre application .NET. Par défaut, cette propriété est définie par le proxy ou les paramètres WPAD dans Internet Explorer. Les développeurs doivent configurer explicitement le proxy Web dans l'application, en procédant comme suit :

  IWebProxy proxy = new WebProxy("<ADRESSE_IP>", <NUMÉRO_PORT>);

  Si votre application .NET utilise déjà la propriété DefaultWebProxy, veillez à ce que le nom du proxy souhaité soit codé en dur dans le fichier app.config.

  Pour consulter la documentation relative à la propriété WebRequest.DefaultWebProxy, reportez-vous à l'article consacré à la propriété WebRequest.DefaultWebProxy (en anglais).

  Remarque : Cela nécessite la recompilation et le redéploiement des applications affectées.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité d'exécution de code à distance.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité est causée par l'absence de validation lorsque .NET Framework obtient les paramètres de proxy Web par défaut et exécute le code JavaScript contenu dans le fichier de configuration automatique de proxy.

J'exécute Microsoft .NET Framework 4.5 sur Windows 8, Windows Server 2012 ou Windows RT, suis-je concerné par ce problème ?  
Non, les clients qui exécutent Microsoft .NET Framework 4.5 sur Windows 8, Windows Server 2012 ou Windows RT ne sont pas concernés par ce problème. La mise à jour cumulative à disponibilité générale pour Windows 8 Client et Windows Server 2012 (KB2756872), publiée le 10 octobre 2012, contient des modifications de défense en profondeur supplémentaires. Les clients qui n'ont pas encore installé cette mise à jour y sont encouragés, en tant que mesure de défense en profondeur. Pour plus d'informations, consultez la section « Plus d'informations » de l'Article 2745030 de la Base de connaissances Microsoft. Pour obtenir des liens de téléchargement et pour plus d'informations à ce sujet, consultez l'Article 2756872 de la Base de connaissances Microsoft. Notez que cette mise à jour contient du contenu non relatif à la sécurité.

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Un attaquant parvenant à exploiter cette vulnérabilité pourrait obtenir les mêmes autorisations que l'utilisateur actuellement connecté. Si un utilisateur est connecté avec des privilèges d'administrateur, un attaquant pourrait prendre le contrôle intégral du système affecté. Il pourrait alors installer des programmes, afficher, modifier ou supprimer des données ou créer de nouveaux comptes dotés de tous les privilèges. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Dans le cas d'une attaque d'interception, un attaquant peut usurper le contenu ou l'emplacement d'un fichier de configuration automatique de proxy (PAC), puis injecter du code dans l'application en cours d'exécution, contournant ainsi les restrictions de sécurité d'accès du code (CAS).

Si l'attaquant a accès au réseau local, il peut usurper l'emplacement du fichier PAC en exécutant un empoisonnement du cache du protocole ARP (Address Resolution Protocol), en redirigeant des requêtes destinées au fichier WPAD vers une adresse IP qu'il contrôle ou en exécutant une usurpation du service NBNS (NetBIOS Name Service), dans laquelle l'attaquant usurpe les réponses aux requêtes WPAD, redirigeant l'application cible vers un fichier PAC malveillant hébergé sur un serveur dont l'attaquant est propriétaire.

Une exploitation serait possible si l'attaquant parvenait à convaincre un utilisateur de se connecter à un serveur hors des limites de l'entreprise. Les scénarios spécifiques pouvant permettre de telles circonstances sont les suivants :

• La dévolution DNS, fonctionnalité de client DNS Windows qui permet aux clients DNS Windows de résoudre les requêtes DNS pour les noms d'hôte non complets en une partie. Un utilisateur malveillant pourrait enregistrer un nom d'hôte spécifique extérieur à une entreprise qui, si les clients ne sont pas configurés correctement, peut être contacté involontairement par un client lorsqu'il passe à l'extérieur de l'entreprise lors de la tentative d'accès à ce nom d'hôte.
• L'usurpation DNS, où un attaquant pourrait exploiter des vulnérabilités dans le DNS (Domain Name System) de Windows, permettant ainsi une usurpation de contenu. Ces vulnérabilités pourraient permettre à un attaquant distant de rediriger le trafic réseau à destination de systèmes Internet vers son système.

Que sont les restrictions de sécurité d'accès du code (CAS) .NET Framework ? 
.NET Framework fournit un mécanisme de sécurité appelé sécurité d'accès du code pour protéger vos ordinateurs de tout code mobile malveillant, permettre à du code d'origine inconnue d'être exécuté avec une certaine protection et empêcher du code de confiance de compromettre accidentellement ou intentionnellement la sécurité. La sécurité d'accès du code (CAS) permet différents degrés de confiance du code, en fonction de son origine et d'autres aspects de l'identité du code. La sécurité d'accès du code applique également les divers niveaux de confiance au code, ce qui réduit la quantité de code nécessitant une confiance totale pour être exécuté. L'utilisation de la sécurité d'accès du code peut diminuer le risque d'utilisation détournée de votre code par un code malveillant ou rempli d'erreurs. Pour plus d'informations sur la sécurité d'accès du code, consultez l'article MSDN « Sécurité d'accès du code ».

Qu'est-ce que la découverte automatique du proxy Web (WPAD - Web Proxy Auto-Discovery) ?  
La fonctionnalité découverte automatique du proxy Web (WPAD - Web Proxy Auto-Discovery) permet aux clients Web de détecter automatiquement les paramètres de proxy sans intervention de l'utilisateur. La fonctionnalité WPAD ajoute comme préfixe le nom d'hôte « wpad » au nom de domaine complet et supprime progressivement les sous-domaines jusqu'à ce qu'elle trouve un serveur WPAD répondant. Pour plus d'informations, consultez l'article consacré à la prise en charge de l'AutoProxy WinHTTP.

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Il existe deux types de systèmes exposés à cette vulnérabilité, décrits comme suit : les systèmes qui utilisent le scénario de navigation Web et ceux qui utilisent le scénario d'applications Windows .NET Framework.

• Scénario de navigation Web
  Le succès de l'exploitation de cette vulnérabilité nécessite qu'un utilisateur ait ouvert une session et visite des sites Web à l'aide d'un navigateur Web capable d'instancier les XBAP. C'est pourquoi les systèmes sur lesquels un navigateur Web est fréquemment utilisé (tels que les postes de travail ou les serveurs Terminal Server) sont les plus exposés à cette vulnérabilité. Les serveurs pourraient être plus exposés si les administrateurs autorisent les utilisateurs à naviguer sur Internet et à consulter leur messagerie électronique depuis ceux-ci. Néanmoins, les meilleures pratiques recommandent fortement de ne pas autoriser cela.
• Scénario d'applications Windows .NET
  Les postes de travail et les serveurs qui exécutent des applications Windows .NET Framework non fiables sont également exposés à cette vulnérabilité.

Que fait cette mise à jour ? 
Cette mise à jour corrige également la vulnérabilité en mettant à jour Microsoft.JScript dans System.Net et en limitant l'exécution par .NET Framework de code JavaScript contenu dans un fichier de configuration WPAD. La mise à jour modifie également la façon dont les données WPAD sont traitées en utilisant WinHTTP au lieu de Microsoft.JScript. Cette modification, même si cela est peu probable, peut générer certains problèmes de compatibilité pour les environnements disposant d'environnement de configuration automatique de proxy non standard. Pour plus d'informations sur cette modification, consultez la section « Plus d'informations » de l'Article 2745030 de la Base de connaissances Microsoft.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Une atténuation fait référence à un paramètre, une configuration générale ou des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Tout attaquant parvenant à exploiter cette vulnérabilité pourrait obtenir les mêmes droits que l'utilisateur. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.
• Par défaut, Internet Explorer 9 et Internet Explorer 10 empêchent XAML, utilisé par les XBAP, de s'exécuter dans la zone Internet.
• Par défaut, Internet Explorer 6, Internet Explorer 7 et Internet Explorer 8 sont configurés pour demander confirmation à l'utilisateur avant d'exécuter XAML, utilisé par les XBAP, dans la zone Internet.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Désactiver les applications du navigateur XAML dans Internet Explorer

  Pour vous protéger contre cette vulnérabilité, modifiez vos paramètres de manière à ce qu'ils vous avertissent avant d'exécuter les applications du navigateur XAML (XBAP) ou qu'ils désactivent les XBAP dans les zones de sécurité Internet et Intranet local comme suit :

  1. Dans Internet Explorer, cliquez sur le menu Outils, puis sélectionnez Options Internet.
  2. Cliquez sur l'onglet Sécurité, sur Internet, puis sur Personnaliser le niveau. Sous Paramètres, pour XAML isolé, cliquez sur Demander ou Désactivé, puis cliquez sur OK.
  3. Cliquez sur l'onglet Sécurité, sur Internet, puis sur Personnaliser le niveau. Sous Paramètres, pour Applications du navigateur XAML, cliquez sur Demander ou Désactivé, puis cliquez sur OK.
  4. Cliquez sur l'onglet Sécurité, sur Internet, puis sur Personnaliser le niveau. Sous Paramètres, pour Documents XPS, cliquez sur Demander ou Désactivé, puis cliquez sur OK.
  5. Dans l'onglet Sécurité, cliquez sur Personnaliser le niveau. Sous composants dépendants du .NET Framework, définissez Exécuter des composants non signés avec Authenticode sur Demander ou Désactiver, puis cliquez sur OK. Répétez ces étapes pour Exécuter des composants signés avec Authenticode, puis cliquez sur OK.
  6. Cliquez sur Intranet local, puis sur Personnaliser le niveau. Répétez les étapes 3 et 4. Si vous êtes invité à confirmer la modification de ces paramètres, cliquez sur Oui. Cliquez sur OK pour retourner dans Internet Explorer.

  Impact de cette solution de contournement. Le code Microsoft .NET ne s'exécutera pas dans Internet Explorer ou ne s'exécutera pas sans invite. La désactivation des applications et des composants Microsoft .NET dans les zones de sécurité Intranet local et Internet risque de perturber le fonctionnement de certains sites Web. Si vous rencontrez des difficultés lors de la visite d'un site Web après avoir modifié ce paramètre et que vous êtes certain de la fiabilité de ce site, vous pouvez ajouter ce dernier à votre liste de sites de confiance. Il pourra ainsi s'afficher correctement.

  Ajouter des sites de confiance à la zone Sites de confiance d'Internet Explorer.

  Après avoir configuré Internet Explorer pour que les applications de navigateur XAML soient désactivées ou que des messages de confirmation s'affichent avant l'exécution de XAML isolé, des applications du navigateur XAML ou des documents XPS dans les zones Internet et Intranet local, vous pouvez ajouter des sites de confiance dans la zone Sites de confiance d'Internet Explorer. Cette opération vous permettra de continuer à utiliser vos sites de confiance exactement comme vous le faites aujourd'hui, tout en vous protégeant contre cette attaque sur les autres sites. Nous vous recommandons d'ajouter uniquement des sites de confiance à la zone Sites de confiance.

  Pour ce faire, procédez ainsi :

  1. Dans Internet Explorer, cliquez sur Outils, sur Options Internet, puis sur l'onglet Sécurité.
  2. Dans la zone Sélectionnez une zone de contenu Web pour spécifier ses paramètres de sécurité, cliquez sur Sites de confiance, puis sur Sites.
  3. Si vous souhaitez ajouter des sites qui ne requièrent pas un canal chiffré, désactivez la case à cocher Nécessite un serveur sécurisé (https:) pour tous les sites dans cette zone.
  4. Dans la zone Ajouter ce site Web à la zone, saisissez l'URL d'un site de confiance, puis cliquez sur Ajouter.
  5. Répétez ces étapes pour chaque site que vous souhaitez ajouter à cette zone.
  6. Cliquez sur OK à deux reprises pour accepter les modifications et retourner dans Internet Explorer.

  Remarque : Ajoutez les sites dont vous savez qu'ils n'effectueront pas d'action malveillante sur votre système. Vous pouvez notamment ajouter les sites « *.windowsupdate.microsoft.com » et « *.update.microsoft.com ». Il s'agit des sites qui hébergent la mise à jour et ils requièrent un contrôle ActiveX pour leur installation.

  Comment annuler cette solution de contournement. Exécutez les étapes suivantes :

  1. Dans Internet Explorer, cliquez sur le menu Outils, puis sélectionnez Options Internet.
  2. Cliquez sur l'onglet Sécurité, sur Rétablir toutes les zones au niveau par défaut, puis sur OK.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité d'élévation de privilèges.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité est due au fait que .NET Framework valide de façon incorrecte les autorisations d'objets impliqués dans la réflexion.

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Dans un scénario de navigation Web, un attaquant qui serait parvenu à exploiter cette vulnérabilité pourrait obtenir les mêmes autorisations que l'utilisateur actuellement connecté. Si un utilisateur est connecté avec des privilèges d'administrateur, un attaquant pourrait prendre le contrôle intégral du système affecté. Il pourrait alors installer des programmes, afficher, modifier ou supprimer des données ou créer de nouveaux comptes dotés de tous les privilèges. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Il existe deux scénarios d'attaque possibles permettant d'exploiter cette vulnérabilité : un scénario de navigation Web et un contournement des restrictions de sécurité d'accès du code (CAS) par l'application Windows .NET. Ces scénarios sont décrits comme suit :

• Scénario d'attaque de navigation Web
  Un attaquant pourrait héberger un site Web spécialement conçu contenant une XBAP (application du navigateur XAML) spécialement conçue et pouvant exploiter cette vulnérabilité, puis convaincre un utilisateur d'afficher le site Web. L'attaquant pourrait également exploiter des sites Web compromis et des sites Web qui acceptent ou hébergent du contenu ou des annonces fournis par les utilisateurs. Ces sites Web pourraient contenir du code spécialement conçu pour exploiter cette vulnérabilité. Cependant, l'attaquant n'aurait aucun moyen de forcer l'utilisateur à visiter ces sites Web. Il devrait y attirer l'utilisateur, généralement en l'incitant à cliquer sur un lien dans un message électronique ou un message instantané qui mène à son site. Il pourrait également afficher du contenu Web spécialement conçu en imitant des bannières publicitaires ou d'autres moyens afin d'envoyer du contenu Web aux systèmes affectés.
• Scénario d'attaque d'applications Windows .NET
  Cette vulnérabilité pourrait également être utilisée par des applications Windows .NET Framework pour contourner les restrictions de sécurité d'accès du code (CAS).

Qu'est-ce que WPF ? 
Microsoft .NET Framework fournit un environnement d'exécution appelé Windows Presentation Foundation (WPF), qui est un système de présentation qui permet de créer des applications clientes Windows. Pour plus d'informations sur WPF, consultez l'article « Présentation de WPF ».

Qu'est-ce qu'une application du navigateur XAML (XBAP) ? 
Une application du navigateur XAML (XBAP) combine des fonctionnalités d'une application Web et d'une application cliente riche. Comme les applications Web, les XBAP peuvent être publiées sur un serveur Web et lancées à partir d'Internet Explorer. Comme les applications clientes riches, les XBAP peuvent tirer parti des capacités de Windows Presentation Foundation (WPF). Pour plus d'informations à propos des XBAP, consultez l'article MSDN « Vue d'ensemble des applications du navigateur XAML Windows Presentation Foundation ».

Que sont les restrictions de sécurité d'accès du code (CAS) .NET Framework ? 
.NET Framework fournit un mécanisme de sécurité appelé sécurité d'accès du code pour protéger vos ordinateurs du code mobile malveillant, permettre à un code d'origine inconnue d'être exécuté avec une certaine protection et empêcher le code de confiance de compromettre accidentellement ou intentionnellement la sécurité. La sécurité d'accès du code (CAS) permet différents degrés de confiance du code, en fonction de son origine et des autres aspects de l'identité du code. La sécurité d'accès du code applique également les divers niveaux de confiance au code, ce qui réduit la quantité de code nécessitant une confiance totale pour être exécuté. L'utilisation de la sécurité d'accès du code peut diminuer le risque d'utilisation détournée de votre code par un code malveillant ou rempli d'erreur. Pour plus d'informations sur la sécurité d'accès du code, consultez l'article MSDN « Sécurité d'accès du code ».

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Il existe deux types de systèmes exposés à cette vulnérabilité, décrits comme suit : les systèmes qui utilisent le scénario de navigation Web et ceux qui utilisent le scénario d'applications Windows .NET Framework.

• Scénario de navigation Web
  Le succès de l'exploitation de cette vulnérabilité nécessite qu'un utilisateur ait ouvert une session et visite des sites Web à l'aide d'un navigateur Web capable d'instancier les XBAP. C'est pourquoi les systèmes sur lesquels un navigateur Web est fréquemment utilisé (tels que les postes de travail ou les serveurs Terminal Server) sont les plus exposés à cette vulnérabilité. Les serveurs pourraient être plus exposés si les administrateurs autorisent les utilisateurs à naviguer sur Internet et à consulter leur messagerie électronique depuis ceux-ci. Néanmoins, les meilleures pratiques recommandent fortement de ne pas autoriser cela.
• Applications Windows .NET
  Les postes de travail et les serveurs qui exécutent des applications Windows .NET Framework non fiables sont également exposés à cette vulnérabilité.

Que fait cette mise à jour ? 
Cette mise à jour corrige la vulnérabilité en modifiant la façon dont .NET Framework optimise le code en mémoire.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Remarque : La mise à jour pour les versions en cours de support de Windows XP Professionnel Édition x64 s'applique également aux versions en cours de support de Windows Server 2003 Édition x64.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Remarque : La mise à jour pour les versions en cours de support de Windows Server 2003 Édition x64 s'applique également aux versions en cours de support de Windows XP Professionnel Édition x64.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.