ou INSCRIVEZ-VOUS Mot de passe oublié ?
Publicité

Gestion des DLL Windows : nombreuses applications vulnérables

Déferlante de mises à jour en perspective

microsoft windows securiteUn problème important de sécurité a été soulevé dans un bulletin de Microsoft. Il concerne une méthode d’infection qui s’appuie sur une exploitation de fichiers DLL malveillants, à travers des applications qui n’utilisent pas d’appels suffisamment sécurisés pour lesdits fichiers. Il faut donc se préparer à une cascade de mises à jour pour de nombreux logiciels.

Les fichiers DLL (pour Dynamic Link Library) sont des bibliothèques communes que les applications appellent pour puiser, globalement, dans les fonctionnalités du système. Microsoft recommande depuis des années d’appeler les fichiers DLL par leur chemin complet. Or, une grande partie des applications ne les appellent pas ainsi : elles utilisent le nom du fichier.

Mais ce n’est pas tout. Quand une application est lancée et qu’elle appelle une DLL sans avoir spécifié un chemin absolu, Windows cherche alors ladite DLL dans un ensemble précis de répertoires. Parmi ces derniers, on trouve le répertoire courant de l’application. Or, si une DLL malveillante est chargée depuis ce répertoire courant, la porte devient grande ouverte pour le pirate.

Mais il faut distinguer deux cas : l’avant et l’après Windows XP Service Pack 2. Jusqu’à la version Service Pack 1 incluse, l’ordre de priorité des dossiers pour la recherche d’une DLL appelée était le suivant :
  1. Dossier de l'application
  2. Cwd (Curent working directory)
  3. Répertoires systèmes (System32 par exemple)
  4. %PATH%
En clair : avant même d’aller regarder dans son répertoire System32, Windows examinait le répertoire d’où était lancée l’application. L’installation du Service Pack 2 changeait la donne et affichait un ordre nettement plus logique :
  1. Dossier de l'application
  2. Répertoires systèmes
  3. %PATH%
  4. Cwd
Le dossier en cours est vérifié en dernier, et il s'agit de celui depuis lequel on lance un document, une musique, une vidéo, etc. Il faut savoir qu’un grand nombre de DLL appelées sont celles de Windows pour les fonctionnalités de bases. Exemple simple : accéder à l’imprimante. Auquel cas il fallait nécessairement vérifier dans le dossier qui contient la plupart de ces DLL : System32. La logique était renforcée par la protection de ce dossier contre les modifications et un mécanisme de restauration des DLL si elles étaient supprimées ou modifiées. Seulement voilà, il existe le cas de toutes les DLL tierces qui sont créées pour des besoins plus spécifiques.

Citons l’exemple d’une application développée avec l’environnement Qt. Ce dernier cherche la bibliothèque Wintab32.dll, qui est développée par Wacom pour ses tablettes. Elle n’est donc pas dans System32, ni dans Path, si l'utilisateur ne possède pas une de ces tablettes. Windows vient donc logiquement chercher la DLL dans le répertoire de l’application qui est lancée. Si cette DLL n’est pas la « vraie », le mal sera fait. L’application elle-même n’a pas besoin d’être malveillante, seul compte l’appel à la DLL. La technique porte le nom de DLL preloading ou encore binary planting.

Ce qui rend la situation plus dangereuse est que le lancement de l’application peut se faire à distance. Un partage sur un réseau local, un intranet ou même ayant simplement une connectivité avec Internet. Les navigateurs sont d’ailleurs concernés. Si l’on en croit les chercheurs californiens qui ont pour la première fois révélé le danger à la mi-août, environ 1 700 DLL sont concernées chez le seul Microsoft, dans 28 applications. D'ailleurs, ce serait cette technique qui aurait été utilisée pour le piratage récent des comptes iTunes.

Le problème est vaste car toutes les applications utilisant des DLL tierces doivent modifier leur code pour appeler les DLL par leur chemin absolu et non par leur simple nom, pour éviter à Windows d’avoir à chercher ces fichiers. En attendant, éviter tout danger ne sera pas simple, car il faudrait couper les services WebDAV et WebClient, bloquer les ports TCP 139 et 445 et utiliser une modification de registre proposée par Microsoft et qui bloque le chargement des DLL sur des dossiers distants, quand un appel est fait depuis une clé USB ou un site web.
Source : Microsoft
le 26 août 2010 à 15:45 (25 281 lectures)