Exporter (0) Imprimer
Développer tout

Présentation des shims

Fonctionnement des shims

L’expérience et la compatibilité applicatives des systèmes d’exploitation Microsoft® Windows® constituent l’un des piliers fondamentaux de leur développement avec la performance, la fiabilité et la facilité d’administration. Pour réduire les coûts de déploiement et accélérer l’adoption des utilisateurs, Microsoft investit dans de nouvelles solutions technologiques. Ce faisant, Microsoft assure une plus large compatibilité des logiciels existants et tient compte de la compatibilité dans les phases de conception et de validation.

Microsoft Windows Application Compatibility Infrastructure (infrastructure de compatibilité des applications ou infrastructure shim) est une solution extrêmement puissante. Dans la mesure où le système d’exploitation Windows évolue d’une version à une autre (prise en charge d’une nouvelle technologie, correction de bogues, mise en œuvre d’une nouvelle stratégie), les modifications apportées à certaines fonctions peuvent affecter les applications qui en découlent. Compte tenu de la nature même d’un logiciel, la résolution d’une incompatibilité pourrait nuire à d’autres applications ou imposer à Windows de rester identique en dépit des améliorations que la nouvelle implémentation pourrait offrir. Nous pouvons contourner cette difficulté en plaçant des branchements directement dans le code source de Windows, mais à plus long terme la facilité d’administration et la fiabilité du système d’exploitation risquent d’en souffrir. Grâce à l’infrastructure shim, en revanche, vous pouvez viser un correctif applicatif spécifique, mais uniquement pour une application particulière (et plus précisément, pour des versions particulières de cette application). Ces correctifs sont hébergés en dehors des fonctionnalités de base de Windows et mis à jour séparément.

L’infrastructure shim permet en quelque sorte d’intercepter une interface de programmation d’applications (API). En fait, elle se sert de l’interception pour rediriger les appels API de Windows vers le code alternatif (le shim proprement dit). La spécification Fichier portable exécutable Windows (PE) et Format COFF (Common Object File Format) inclut plusieurs en-têtes, et les répertoires de données de cet en-tête proposent une couche d’indirection entre l’application et le fichier associé. Les appels vers les fichiers binaires externes ont lieu via la table IAT (Import Address Table). Par conséquent, un appel vers Windows ressemble à la figure 1.

643f2bee-8329-4018-9d90-2ffcc7c76a6c

Figure 1   Application appelant Windows via la table IAT

Vous pouvez modifier l’adresse de la fonction Windows résolue dans la table d’importation, puis la remplacer par un pointeur visant une fonction du code shim (voir Figure 2).

Image ART

Figure 2   Application redirigée vers le shim avant l’appel de Windows

Pour les fichiers .dll associés de manière statique, cette indirection a lieu lors du chargement de l’application. Les fichiers .dll associés dynamiquement peuvent également faire l’objet d’un shim via une interception de l’API GetProcAddress.

Impact de l’infrastructure shim sur la conception

Lors du choix de la stratégie à adopter, il convient d’étudier les impacts de l’infrastructure shim en termes de conception.

Tout d’abord, comme le montre la figure 2, le code qui s’exécute à l’intérieur d’un correctif réside en dehors de Windows. Par conséquent, Windows applique les mêmes restrictions de sécurité au code du correctif qu’à celui de l’application proprement dite. En fait, pour Windows, le code shim n’est plus ni moins un code d’application. Pas question, par conséquent, d’utiliser les shims pour outrepasser des mécanismes de sécurité présents dans Windows. Par exemple, aucun shim ne permet d’ignorer les invites du Contrôle de compte utilisateur (UAC) de Windows 7 lors de l’exécution de l’application avec des privilèges élevés. Un shim permet à l’application de n’exiger aucun droit d’administration ni d’en demander mais, pour bénéficier de droits d’administrateur une fois UAC activé, l’utilisateur devra approuver l’élévation. Il en est de même pour le code que vous écrivez vous-même.

En termes de sécurité, par conséquent, les shims n’entraînent aucune vulnérabilité supplémentaire. En fait, mieux vaut utiliser des shims que d’assouplir les descripteurs de sécurité ou d’adopter une stratégie plus laxiste. Sans shims, par exemple, vous pourrez atténuer un problème de compatibilité en assouplissant les ACL sur un répertoire particulier, mais cette décision influe sur l’intégralité du système. Avec les shims, vous pourrez rediriger l’accès du fichier vers un emplacement par utilisateur pour cette application. Autre exemple : une application peut rechercher explicitement des droits d’administrateur. Sans shims, vous devrez probablement accorder des droits d’administrateur d’application pour passer ce contrôle. Si le contrôle est inutile, en revanche, un shim peut simplement faire croire que l’utilisateur actuel dispose de droits d’administrateur. Ainsi, le contrôle réussit sans exposer pour autant une nouvelle surface d’attaque.

Deuxièmement, puisque l’infrastructure shim injecte en fait un code supplémentaire dans l’application avant d’appeler Windows, toutes les mises à jour pour lesquelles un shim suffit peuvent se faire en modifiant le code de l’application proprement dit. L’application pourrait inclure dans le shim un code similaire à ce que Windows met en œuvre, immédiatement avant l’appel des API Windows.

Pour finir, puisque les shims exécutent un code en mode utilisateur à l’intérieur d’un processus applicatif en mode utilisateur, il est impossible de faire appel à un shim pour corriger du code en mode noyau. Il est, par exemple, impossible d’utiliser de shims pour résoudre des incompatibilités au niveau des pilotes de périphérique ou de tout autre code en mode noyau (antivirus, pare-feu et logiciels anti-espions, par exemple).

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Afficher:
© 2014 Microsoft