Sécurité de la bibliothèque Dynamic-Link
Lorsqu’une application charge dynamiquement une bibliothèque de liens dynamiques sans spécifier de nom de chemin complet, Windows tente de localiser la DLL en recherchant un ensemble bien défini de répertoires dans un ordre particulier, comme décrit dans Dynamic-Link ordre de recherche de bibliothèque. Si un attaquant obtient le contrôle de l’un des répertoires sur le chemin de recherche DLL, il peut placer une copie malveillante de la DLL dans ce répertoire. Il s’agit parfois d’une attaque de préchargement DLL ou d’une attaque de plantation binaire . Si le système ne trouve pas de copie légitime de la DLL avant de rechercher dans le répertoire compromis, il charge la DLL malveillante. Si l’application s’exécute avec des privilèges d’administrateur, l’attaquant peut réussir dans l’élévation de privilèges locaux.
Par exemple, supposons qu’une application soit conçue pour charger une DLL à partir du répertoire actif de l’utilisateur et échouer correctement si la DLL est introuvable. L’application appelle LoadLibrary avec uniquement le nom de la DLL, ce qui entraîne la recherche du système pour la DLL. En supposant que le mode de recherche DLL sans échec est activé et que l’application n’utilise pas d’autre ordre de recherche, le système recherche les répertoires dans l’ordre suivant :
- Répertoire à partir duquel l’application a chargé.
- Répertoire système.
- Répertoire système 16 bits.
- Répertoire Windows.
- Répertoire actif.
- Répertoires répertoriés dans la variable d’environnement PATH.
En continuant l’exemple, un attaquant ayant connaissance de l’application prend le contrôle du répertoire actif et place une copie malveillante de la DLL dans ce répertoire. Lorsque l’application émet l’appel LoadLibrary, le système recherche la DLL, recherche la copie malveillante de la DLL dans le répertoire actif et le charge. La copie malveillante de la DLL s’exécute ensuite dans l’application et obtient les privilèges de l’utilisateur.
Les développeurs peuvent aider à protéger leurs applications contre les attaques de préchargement dll en suivant les instructions suivantes :
Dans la mesure du possible, spécifiez un chemin complet lors de l’utilisation duLoadLibrary, LoadLibraryEx, CreateProcessou fonctions ShellExecute.
Utilisez les indicateurs LOAD_LIBRARY_SEARCH avec la fonction LoadLibraryEx, ou utilisez ces indicateurs avec la fonction SetDefaultDllDirectories pour établir un ordre de recherche DLL pour un processus, puis utilisez l'AddDllDirectory ou Fonctions SetDllDirectory pour modifier la liste. Pour plus d’informations, consultez Dynamic-Link ordre de recherche de bibliothèque.
Windows 7, Windows Server 2008 R2, Windows Vista et Windows Server 2008 : ces indicateurs et fonctions sont disponibles sur les systèmes avec KB2533623 installé.
Sur les systèmes équipés de KB2533623 installés, utilisez les indicateurs LOAD_LIBRARY_SEARCH avec la fonctionLoadLibraryEx, ou utilisez ces indicateurs avec la fonction SetDefaultDllDirectories pour établir un ordre de recherche DLL pour un processus, puis utilisez les fonctions AddDllDirectory ou SetDllDirectory pour modifier la liste. Pour plus d’informations, consultez Dynamic-Link ordre de recherche de bibliothèque.
Envisagez d’utiliser redirection DLL ou un manifeste pour vous assurer que votre application utilise la DLL correcte.
Lorsque vous utilisez l’ordre de recherche standard, assurez-vous que le mode de recherche DLL sans échec est activé. Cela place l’annuaire actuel de l’utilisateur plus loin dans l’ordre de recherche, ce qui augmente les chances que Windows trouve une copie légitime de la DLL avant une copie malveillante. Le mode de recherche DLL sans échec est activé par défaut à partir de Windows XP avec Service Pack 2 (SP2) et est contrôlé par la valeur de Registre HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode. Pour plus d’informations, consultez Dynamic-Link ordre de recherche de bibliothèque.
Envisagez de supprimer le répertoire actif du chemin de recherche standard en appelant SetDllDirectory avec une chaîne vide ( » « ). Cette opération doit être effectuée une fois au début de l’initialisation du processus, et non avant et après les appels à LoadLibrary. N’oubliez pas que SetDllDirectory affecte l’ensemble du processus et que plusieurs threads appelant SetDllDirectory avec différentes valeurs peuvent entraîner un comportement non défini. Si votre application charge des DLL tierces, testez soigneusement pour identifier les incompatibilités.
N’utilisez pas la fonction SearchPath pour récupérer un chemin d’accès à une DLL pour un appel LoadLibrary ultérieur, sauf si le mode de recherche de processus sans échec est activé. Lorsque le mode de recherche sans échec n’est pas activé, la fonction SearchPath utilise un ordre de recherche différent de LoadLibrary et est susceptible de rechercher d’abord le répertoire actif de l’utilisateur pour la DLL spécifiée. Pour activer le mode de recherche de processus sans échec pour la fonction SearchPath, utilisez la fonction SetSearchPathMode avec BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Cela déplace le répertoire actif à la fin du SearchPath liste de recherche pour la durée de vie du processus. Notez que le répertoire actif n’est pas supprimé du chemin de recherche. Par conséquent, si le système ne trouve pas une copie légitime de la DLL avant qu’il atteigne le répertoire actif, l’application est toujours vulnérable. Comme avec SetDllDirectory, l’appel SetSearchPathMode doit être effectué au début de l’initialisation du processus et affecte l’ensemble du processus. Si votre application charge des DLL tierces, testez soigneusement pour identifier les incompatibilités.
N’effectuez pas d’hypothèses sur la version du système d’exploitation en fonction d’un appel LoadLibrary qui recherche une DLL. Si l’application s’exécute dans un environnement où la DLL n’est légitimement pas présente, mais qu’une copie malveillante de la DLL se trouve dans le chemin de recherche, la copie malveillante de la DLL peut être chargée. Utilisez plutôt les techniques recommandées décrites dans Obtention de la version système.
L’outil Process Monitor peut être utilisé pour identifier les opérations de chargement dll susceptibles d’être vulnérables. L’outil Process Monitor peut être téléchargé à partir de https://technet.microsoft.com/sysinternals/bb896645.aspx.
La procédure suivante explique comment utiliser Process Monitor pour examiner les opérations de chargement dll dans votre application.
Pour utiliser Process Monitor pour examiner les opérations de chargement dll dans votre application
- Démarrez le moniteur de processus.
- Dans Process Monitor, incluez les filtres suivants :
- L’opération est CreateFile
- L’opération est LoadImage
- Le chemin d’accès contient .cpl
- Le chemin d’accès contient .dll
- Le chemin d’accès contient .drv
- Le chemin d’accès contient .exe
- Le chemin d’accès contient .ocx
- Chemin d’accès contient .scr
- Le chemin d’accès contient .sys
- Excluez les filtres suivants :
- Le nom du processus est procmon.exe
- Le nom du processus est Procmon64.exe
- Nom du processus est Système
- L’opération commence par IRP_MJ_
- L’opération commence par FASTIO_
- Résultat : SUCCESS
- Le chemin se termine par pagefile.sys
- Essayez de démarrer votre application avec le répertoire actif défini sur un répertoire spécifique. Par exemple, double-cliquez sur un fichier avec une extension dont le gestionnaire de fichiers est affecté à votre application.
- Vérifiez la sortie du Moniteur de processus pour connaître les chemins d’accès suspects, tels qu’un appel au répertoire actif pour charger une DLL. Ce type d’appel peut indiquer une vulnérabilité dans votre application.