Sécuriser le chargement des bibliothèques pour empêcher le préchargement d’attaques par DLL

Attaques basées sur LoadLibrary

Lorsqu’une application charge dynamiquement une DLL sans spécifier de chemin d’accès complet, Windows tente de localiser cette DLL en recherchant linéairement un ensemble bien défini d’annuaires, appelés ordre de recherche DLL. Si Windows recherche la DLL dans l’ordre de recherche de la DLL, elle la charge. Toutefois, si Windows ne trouve pas la DLL dans l’un des répertoires de l’ordre de recherche DLL, cela retournera un échec à l’opération de chargement de DLL. Voici ce qui suit est l’ordre de recherche DLL pour les fonctions LoadLibraryet LoadLibraryEx,qui sont utilisées pour charger dynamiquement des DLL :

1. Répertoire à partir duquel l’application a été chargée

2. Répertoire système

3. Répertoire système 16 bits

4. The Windows directory

5. CWD (Current working directory)

6. Répertoires répertoriés dans la variable d’environnement PATH

Prenons le scénario suivant :

• Une application charge une DLL sans spécifier le chemin d’accès complet qu’elle attend de trouver dans le cdf de l’application.

• L’application est entièrement prête à traiter le cas lorsqu’elle ne trouve pas la DLL.

• L’pirate malveillant connaît ces informations sur l’application et contrôle le CWD.

• L’pirate malveillant copie sa propre version spécialement conçue de la DLL dans le cdwd. Cela suppose que l’pirate malveillant est autorisé à le faire.

• Windows dans les répertoires de l’ordre de recherche DLL et trouve la DLL dans le cd-DW de l’application.

Dans ce scénario, la DLL spécialement conçue s’exécute dans l’application et obtient les privilèges de l’utilisateur actuel.

Recommandation Pour éviter cette attaque, les applications peuvent supprimer le répertoire de travail actuel du chemin d’accès de recherche DLL en appelant
l’API SetDllDirectory en utilisant une chaîne vide
(«  »). Si une application dépend du chargement d’une DLL à partir du répertoire actuel, obtenez le répertoire de travail actuel et utilisez-le pour passer dans un chemin complet de LoadLibrary.



Nous sommes également conscients que certains développeurs utilisent LoadLibrary pour vérifier si une DLL spécifique est présente afin de déterminer quelle version de Windows est en cours d’exécuter par l’utilisateur. Sachez que cela peut rendre l’application vulnérable. Si la bibliothèque concernée n’existe pas dans la version Windows sur qui l’application est exécutée, un pirate malveillant peut introduire une bibliothèque du même nom dans CWD. Nous vous recommandons vivement de ne pas utiliser cette technique. À la place, utilisez les techniques recommandées décrites dans l’article MSDN, « Obtention de la version du système ».

Une application qui charge les plug-ins tiers et qui ne peut pas forcer les plug-ins à utiliser un chemin qualifié pour ses appels LoadLibrary doit appeler SetDllDirectory(«  ») pour supprimer CWD, puis appeler SetDllDirectory(« emplacement d’installation du plug-in ») pour ajouter le répertoire d’installation du plug-in au chemin de recherche DLL.

Attaques basées sur SearchPath

Il existe une attaque similaire lorsqu’une application utilise l’API SearchPath pour localiser une DLL et charger dynamiquement le chemin d’accès renvoyé par SearchPath. L’ordre de recherche par défaut pour l’API SearchPath est le suivant :

• Répertoire à partir duquel l’application a été chargée

• CWD (Current working directory)

• Répertoire système

• Répertoire système 16 bits

• The Windows directory

• Répertoires répertoriés dans la variable d’environnement PATH

Nous vous déconseillons d’avoir ce modèle, car il n’est pas sécurisé. Nous vous déconseillons d’utiliser la fonction SearchPath comme méthode de localisation d’un fichier .dll si l’utilisation prévue de la sortie est dans un appel à la fonction LoadLibrary. Cela peut entraîner la localisation du mauvais .dll fichier, car l’ordre de recherche de la fonction SearchPath diffère de l’ordre de recherche utilisé par la fonction LoadLibrary. Si vous devez localiser et charger un .dll fichiers, utilisez la fonction LoadLibrary.

ShellExecute et CreateProcess

Des variantes de ces problèmes peuvent également exister lorsque des développeurs appellent des fonctions similaires telles que ShellExecuteet CreateProcesspour charger des exécutables externes. Nous recommandons aux développeurs d’être prudents lorsqu’ils chargent des binaires et de spécifier le chemin d’accès complet. Cela devrait présenter moins de complexité lorsque vous chargez un binaire au lieu d’une bibliothèque.

Instructions sur l’identification des chargements de bibliothèques non sous-écures

Dans le code source, les exemples suivants illustrent des chargements de bibliothèque non sous-contrôle :

• Dans l’exemple de code suivant, l’application recherche « schannel.dll » en utilisant le chemin de recherche le moins sécurisé. Si un pirate malveillant peut placer schannel.dll CWD, il se charge avant même que l’application ne recherche dans les Windows de recherche de la bibliothèque appropriée.

  DWORD retval = SearchPath(NULL, "schannel", ".dll", err, result, NULL); 
  HMODULE handle = LoadLibrary(result);

• Dans l’exemple de code suivant, l’application tente de charger la bibliothèque à partir des emplacements des applications et du système d’exploitation décrits au début de ce document pour l’appel LoadLibrary(). S’il existe un risque que le fichier ne soit pas présent, l’application peut essayer de charger le fichier à partir du répertoire de travail actuel. Ce scénario est légèrement moins dangereux que dans l’exemple précédent. Toutefois, il expose toujours l’utilisateur de l’application au risque si l’environnement n’est pas complètement prévisible.

  HMODULE handle = LoadLibrary("schannel.dll");

Voici des exemples de chargements de bibliothèque plus sécurisés et plus précis :

• Dans l’exemple de code suivant, la bibliothèque est chargée directement à l’aide d’un chemin d’accès complet. Il n’y a aucun risque que l’utilisateur malveillant introduise du code malveillant, sauf s’il possède déjà des autorisations d’écriture sur le répertoire cible de l’application.
  
  

  HMODULE handle = LoadLibrary("c:\\windows\\system32\\schannel.dll");

  
  
  Remarque Pour plus d’informations sur la manière de déterminer le répertoire système, voir les ressources suivantes :
  
  GetSystemDirectory

  http://msdn.microsoft.com/en-us/library/ms724373%28VS.85%29.aspxSHGetFoldnFolderPath

  http://msdn.microsoft.com/en-us/library/bb762188%28v=VS.85%29.aspx

• Dans l’exemple de code suivant, le répertoire de travail actuel est supprimé du chemin de recherche avant d’appeler LoadLibrary. Cela réduit le risque de manière significative, car l’utilisateur malveillant doit contrôler soit le répertoire d’application, le répertoire Windows, soit tous les répertoires spécifiés dans le chemin d’accès de l’utilisateur afin d’utiliser une attaque par préchargement DLL.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");

• Sur tous les systèmes qui ont installé la mise à jour de sécurité 963027 (décrite dans MS09-014),le code suivant déplacerait définitivement le code CWD à l’emplacement tout dernier dans l’ordre de recherche. Les appels ultérieurs vers la fonction SetSearchPathMode à partir de ce processus qui tentent de modifier le mode de recherche échoueront.

  SetDllDirectory ("");
  HMODULE handle = LoadLibrary("schannel.dll");
  

• Dans l’exemple de code suivant, le répertoire de travail actuel est supprimé du chemin de recherche avant d’appeler LoadLibrary. Cela réduit le risque de manière significative, car l’utilisateur malveillant doit contrôler soit le répertoire d’application, le répertoire Windows, soit tous les répertoires spécifiés dans le chemin d’accès de l’utilisateur afin d’utiliser une attaque par préchargement DLL.

  SetSearchPathMode (BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE | BASE_SEARCH_PATH_PERMANENT );
  HMODULE handle = LoadLibrary("schannel.dll");