Attaques en DLL preloading : Microsoft sort un outil (presque) automatisé de protection

**Gordon Fowler** · 24/08/2010, 16h13

Gestion des DLL : Microsoft sort un nouvel outil de protection
En attendant une mise à jour et les correctifs des éditeurs

Mise à jour du 01/09/10

Il ne suffit pas de s'appeler Microsoft pour que les éditeurs corrigent leurs applications d'un coup de baguette magique. Malheureusement.

Résultats, Windows est toujours exposé au « DLL Preloading », une vulnérabilité présente dans de très nombreuses – et très populaires – applications comme Firefox, LiveMail, Office 2007, etc. (lire ci-avant pour plus de détails sur la liste et cette faille liée au pré-chargement des librairies).

Le problème tient au fait que la responsabilité de ces vulnérabilités n'est pas imputable à Microsoft.

Qu'à cela ne tienne, ses équipes de sécurité planchent durement sur le dossier.

La première solution proposée était particulièrement peu « user friendly », une dimension importante à prendre en compte si l'on veut que les utilisateurs appliquent les correctifs.

Microsoft proposait - et propose toujours - une nouvelle entrée de Registre, baptisée CWDIllegalInDllSearch, pour contrôler l'algorithme de recherche de chemin d'accès aux fichiers DLL (lire ci-avant).

« Une fois installé, cet outil a encore besoin d'être configuré pour bloquer les comportements malicieux et nos clients nous ont demandé quels étaient les paramètres recommandés », explique Jerry Bryant, porte parole de Microsoft dans cette affaire. « En conséquence de quoi, [nos équipes] ont travaillé pour développer un "Fix-It" qui active par défaut les paramètres que nous recommandons et qui bloquerons la plupart des vecteurs d'attaque distante ».

Mais cette solution, qui consiste à appliquer le premier outil puis le Fix-It, n'est toujours pas simple. En tout cas pas assez pour les non-experts en sécurité.

Microsoft en a bien conscience : « beaucoup d'entreprises nous ont demandé de rendre plus facile l'application de cet outil », admet Bryant.

Redmond réfléchit donc à présent à la manière d'intégrer ces défenses directement dans une prochaine mise à jour de ses OS.

Ces deux outils devraient faire leur apparition en priorité dans le prochain Windows Update de Windows Server (« dans les deux semaines », estime aujourd'hui Bryant), puis pour le grand public (Windows XP, Vista, 7). Sans autre précision sur la date de sortie de cette mise à jour pour cette catégorie d'utilisateurs.

La nouvelle entrée de Registre CWDIllegalInDllSearch est disponible ici
Le Fix-It est disponible là

Pour mémoire, Microsoft propose aussi la solution de désactiver le service WebClient et de bloquer les ports TCP 139 et 445

Source : Billet sur le Microsoft Securtity Response Center

Et vous ?

Avez-vous appliqué ces protections ou attendez-vous la mise à jour intégrée à Windows Update ?

MAJ de Gordon Fowler

Mise à jour du 25.08.2010 par Katleen
Plus de 100 logiciels seraient vulnérables aux attaques en DLL preloading, dont Live Mail, iTunes, Firefox, etc...

Suite aux révélations de Microsoft de la vulnérabilité de certaines applications tournant sous Windows à des attaques par "DLL preloading", la liste des programmes concernés n'avait pas été communiquée. C'est désormais chose faite, grâce à la base de données Exploit-db.

Les experts de ce site spécialisé n'ont pas attendu que les chercheurs de Microsoft aient achevé d'examiner tous les logiciels de la firme pour identifier et publier une liste de ceux y étant vulnérables.

On apprends ainsi que Windows Live Mail, Windows Movie Maker, Microsoft PowerPoint 2010, Office 2007 et Windows Address Book (sur XP uniquement pour ce cas précis) seraient sensibles aux attaques par DLL preloading. Microsoft ne s'est pas encore exprimé sur ces révélations.

La communauté Exploit-db ne s'est d'ailleurs pas arretée aux produits de l'éditeur de Redmond, mais en a scanné bien d'autres. Firefox 3.6.8, Foxit Reader, Wireshark, uTorrent, iTunes 9.0, ... sont également vulnérables.

D'après Acros Security, plus de 100 logiciels seraient concernés par le problème. Et, au fur et à mesure des tests, la liste pourrait s'allonger...

Comme le problème ne vient pas de la plateforme de Microsoft, il n'y aura pas un correctif de Windows mais bien un correctif par application pour règler le problème.

En attendant, la plus grande vigilance est recommandée envers les DLL distantes. Microsoft conseille à ses utilisateurs de désactiver l'appel de librairies depuis WebDAV, ainsi que de désactiver le service WebClient tout en bloquant les ports TCP 139 et 445.

La suite au prochain numéro...

Source : exploit-db.com

Microsoft sort un outil pour bloquer des attaques qui exploiteraient les DLL
Rapid7 propose un Kit pour auditer les applications touchées par cette nouvelle menace

Pour une réaction rapide, c'est une réaction rapide.

Dans un bulletin de sécurité publié hier soir, Microsoft mettait en garde les utilisateurs de Windows contre l'utilisation des fichiers DLL (ou plus exactement leur preloading – ou pré-chargement) dans de possibles attaques contre le système.

La menace est assez sérieuse puisque d'après Rapid7, une société spécialisée dans la sécurité informatique, une quarantaine d'applications pourraient servir de vecteur à ces assauts.

Concrètement, l'attaque consiste à leurrer les applications en leur faisant pré-charger une librairie (une DLL) malicieuse à la place d'une DLL habituelle. Ce type d'attaque existait déjà mais la nouveauté de la vulnérabilité dévoilée par Microsoft tient au fait que cette librairie viciée peut être stockée sur un support USB, un serveur distant ou un réseau partagé (« un emplacement non certfié », dit Microsoft).

Résultat, il devient possible de faire exécuter à distance un code contenu dans une DLL par le biais des applications touchées, et que Rapid7 se refuse à nommer.

Microsoft souligne qu'il ne s'agit pas d'une faille de ses OS mais bien d'une vulnérabilité liée aux applications et donc d'erreurs potentielles de conception de la part des éditeurs. Certaines applications ne prennent en effet pas la peine d'indiquer le chemin complet de l'emplacement d'une DLL pour la charger. D'où la possibilité, en utilisant le même nom de fichier, de leurrer ces logiciels tiers.

Microsoft ne fait néanmoins pas preuve de triomphalisme. Redmond affirme en effet être en train de passer au crible ses propres produits pour s'assurer qu'aucun d'entre eux n'est exposé.

Face à cette menace, Microsoft a décidé de proposer le plus rapidement possible « une nouvelle clé de Registre CWDIllegalInDllSearch qui permet aux utilisateurs de contrôler l'algorithme de recherche de chemin d'accès de fichier DLL. L'algorithme de recherche de chemin d'accès de fichier DLL est utilisé […] lorsque les fichiers DLL sont chargés sans qu'un chemin complet soit spécifié ».

Les responsable sécurité pourront se rendre sur la page de CWDIllegalInDllSearch pour prendre connaissance du détail de la manipulation.

De son coté, Rapid7 propose un « Kit » gratuit et une méthode destinée aux développeurs qui souhaitent tester leurs applications. Il est disponible, ainsi que les explications, sur cette page.

A priori Apple devrait être une des premières sociétés à réagir puisque son très célèbre gestionnaires de contenus multimédia iTunes ferait partie de la liste des applications concernées.

Une bibliothèque avec un problème de librairie en quelque sorte.

Source : Bulletin d'alerte de Microsoft, Billet de Rapid7, iTunes concerné d'après Acros Security

Lire aussi :

Windows : bilan sur le nouvel exploit zero-day : pour les experts, il s'agit d'une première tant l'attaque est ciblée, étudiée et complexe

La moitié des attaques informatiques bénéficient de complicités internes, selon les Services Secrets américains et Verizon

Un groupe anonyme veut se venger de Microsoft après "sa campagne anti-Ormandy" et dévoile une nouvelle vulnérabilité de Windows

Windows : nouvelle faille mineure dans le noyau, Travis Ormandy de Google l'utilise tout de même pour critiquer Microsoft

Les rubriques (actu, forums, tutos) de Développez :

Sécurité

Windows

**sphynxounet** · 24/08/2010, 16h37

Dans Windev, l'utilisation du chargement d'une dll avec un chemin relatif ne va chercher que dans certains répertoires, ceux de windows, du répertoire de l'appli, ... et des répertoires contenu dans PATH.

Pour qu'une dll soit chargée à partir d'une clé usb ou d'un serveur distant, encore faudrait-il que ces "répertoires" soient pris en compte. Existe-t-il un moyen simple (et non légal) de modifier le PATH ou d'introduire des répertoires supplémentaires à rechercher ?

La recherche dans les répertoires diffère-t-elle en fonction du logiciel de développement utilisé ? (surement avec un peu de chance ...)

Si oui en effet cela risque de poser quelques problèmes.

**Caly4D** · 24/08/2010, 16h54

Envoyé par sphynxounet

Pour qu'une dll soit chargée à partir d'une clé usb ou d'un serveur distant, encore faudrait-il que ces "répertoires" soient pris en compte. Existe-t-il un moyen simple (et non légal) de modifier le PATH ou d'introduire des répertoires supplémentaires à rechercher ?
.

sur win7 lorsqu'un logiciel n'a pas les droit pour modifier c:\windows (par exemple modifier un fichier .ini)
il crée un répertoire (temporaire ?) imitant c:\windows
on a vu ça il y a pas longtemps avec une apli qui une fois le .ini modifié ne prenait pas en compte la modif, en fait l'appli allait chercher le .ini dans un répertoire chelou (chelou c'est le mot juste) invisible à l'utilisateur et perdu dans les méandre du dossier utilisateur.
Il y a peut-être la possibilité que cette fonctionnalité ne soit pas limité qu'avec les .ini

**sevyc64** · 24/08/2010, 17h27

Dans Windev, l'utilisation du chargement d'une dll avec un chemin relatif ne va chercher que dans certains répertoires, ceux de windows, du répertoire de l'appli, ... et des répertoires contenu dans PATH.

Comme pour tous les logiciels et pas uniquement Windev, puisque c'est géré par le système d'exploitation, la recherche d'un fichier (et pas uniquement les dll) dont le chemin n'est pas indiqué se fait dans l'ordre
- dossier courant
- dossier de l'exécutable
- dossier système "%Windows%", généralement C:\Windows
- dossier système "%SYSTEM%", généralement C:\Windows\System32
- et enfin dans les dossiers indiqués par la variable %PATH% dans leur ordre d'apparition dans cette variable.

**Aurelien.Regat-Barrel** · 25/08/2010, 11h56

Perdu

L'ordre est donné dans un des liens fournis dans cette news:
http://support.microsoft.com/kb/2264107

Mais je note qu'aucune mention n'est faite du mécanisme side by side (manifest xml, WinSxS, ...).

Par ailleurs, le détails des attaques possible est aussi donné dans le lien vers le post du blog:

1) If the application is trying to load a DLL that is normally found within the PATH, but not the Windows system directories, and the PATH contains environment variables that have not been set, then the literal value of the environment variable will be treated as sub-directory of the working directory (the share). For example, if %unknownvariable%\bin is in the system PATH, the share will be searched for a directory called “%unknownvariable%\bin” and the target DLL will be loaded from within this sub-directory.

2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL". This is exploitable in most cases and affects at least one Microsoft product.

3. Some applications will actually load and run executables from the working directory. The audit kit generates test cases for these as well using a binary that launches the calculator.

4. Applications using certain windowing and plugin libraries will validate that the DLL in question has a certain exported symbol before loading it. This will become obvious when you see the "missing symbol" error message after opening the generated test case. These are almost always exploitable.

5. If the application loads a configuration file (INI or otherwise) from the working directory, this can also be exploitable. A few instances of this have already been uncovered, in one case where the DLL that loads the INI file is injected into unrelated applications, making them vulnerable as well.

6. Some applications will require the DLL to be signed. These applications only validate that the signature was authorized by a trusted code signing root and a $200 code signing key is all you need to exploit these.

7. In at least one instance, a .NET DLL is loaded with full privileges. A normal native DLL will be rejected, but a crafted .NET DLL can be used to exploit these types of applications.

Cela dit, j'ai pas pigé pourquoi iTunes charge une dll quand on clique sur un fichier auquel l'appli est associé?

Il est aussi dit qu'au moins 4 applis de MS sont concernées, et apparement MS est déjà sur le coup pour 2 d'entre elles.

**sevyc64** · 25/08/2010, 12h07

Cet ordre donné par ce lien me semble étrange, car ce n'est pas ce que j'ai pu constater depuis plusieurs années pour tout type de fichiers.
A moins qu'une mise à jour quelque part soit modifié cela pour les dll....

L'ordre que j'avais donné, moi, correspond à celui que j'ai pu constaté depuis plusieurs années dans la recherche générale d'un fichier (pas uniquement des dlls).

**rt15** · 25/08/2010, 13h48

Pour l'ordre, il dépend d'une option (SafeDllSearchMode) et est dispo ici.

Pour ce qui est du chargement de dll, peu importe le langage de développement ou autre bibliothèque, c'est LoadLibrary/LoadLibraryEx qui sera appelé au final, et c'est lui qui détermine où chercher.

Certaines applications ne prennent en effet pas la peine d'indiquer le chemin complet de l'emplacement d'une DLL pour la charger. D'où la possibilité, en utilisant le même nom de fichier, de leurrer ces logiciels tiers.

Nan mais sérieusement, il y en a qui le précise ??? La plupart du temps, on ne passe que le nom. La plupart des dlls sont le plus souvent soit dans le même répertoire que l'exe, soit dans dans system32. Pas grand monde doit prendre le temps de construire un chemin.

Par contre, il me semble que "tout le monde" se méfie du dossier courant, qui peut valoir tout et n'importe quoi (Sauf dans le cas ou c'est une information intéressante, dans le cas d'une appli console par exemple). On utilise le chemin du .exe à la place.

Quant à cette "faille", elle me paraît quand même particulièrement foireuse... "Allez s'il te plait, exécute cette application depuis ce répertoire courant (Partagé)", "Allez, s'il te plait, exécute ce raccourci", "Allez, s'il te plait ajoute ça dans ton PATH"... A ce compte là, autant demander l'exécution d'un .exe vérolé.

[edit]Ah j'avais pas vu la version "Ouvre ce document et ne prend pas garde à la dll juste à côté". Elle est effectivement un peu plus discrète.

**sevyc64** · 25/08/2010, 13h58

Nan mais sérieusement, il y en a qui le précise ??? La plupart du temps, on ne passe que le nom. La plupart des dlls sont le plus souvent soit dans le même répertoire que l'exe, soit dans dans system32. Pas grand monde doit prendre le temps de construire un chemin.

C'est effectivement une des bases de la programmation, toujours spécifier un chemin complet pour l'ouverture d'un fichier, même s'il faut le construire dynamiquement à partir du chemin de l'exe.

C'est effectivement une des bases probablement la moins respectée.
Moi-même, il a dû m'arriver de ne pas la respecter, notamment dans du code vite fait que l'on reviendra corrigé plus tard, plus tard signifiant bien souvent jamais.

**Michaël** · 25/08/2010, 14h24

Envoyé par Caly4D

sur win7 lorsqu'un logiciel n'a pas les droits pour modifier c:\windows (par exemple modifier un fichier .ini)
il crée un répertoire (temporaire ?) imitant c:\windows
on a vu ça il y a pas longtemps avec une apli qui une fois le .ini modifié ne prenait pas en compte la modif, en fait l'appli allait chercher le .ini dan un répertoire chelou (chelou c'est le mot juste) invisible à l'utilisateur et perdu dans les méandres du dossier utilisateur.
Il y a peut-être la possibilité que cette fonctionnalité ne soit pas limité qu'avec les .ini

C'est le principe de fonctionnement de l'uac qui veut ça

**Katleen Erna** · 26/08/2010, 00h03

Mise à jour du 25.08.2010 par Katleen
Plus de 100 logiciels seraient vulnérables aux attaques en DLL preloading, dont Live Mail, iTunes, Firefox, etc...

Suite aux révélations de Microsoft de la vulnérabilité de certaines applications tournant sous Windows à des attaques par "DLL preloading", la liste des programmes concernés n'avait pas été communiquée. C'est désormais chose faite, grâce à la base de données Exploit-db.

Les experts de ce site spécialisé n'ont pas attendu que les chercheurs de Microsoft aient achevé d'examiner tous les logiciels de la firme pour identifier et publier une liste de ceux y étant vulnérables.

On apprend ainsi que Windows Live Mail, Windows Movie Maker, Microsoft PowerPoint 2010, Office 2007 et Windows Address Book (sur XP uniquement pour ce cas précis) seraient sensibles aux attaques par DLL preloading. Microsoft ne s'est pas encore exprimé sur ces révélations.

La communauté Exploit-db ne s'est d'ailleurs pas arretée aux produits de l'éditeur de Redmond, mais en a scanné bien d'autres. Firefox 3.6.8, Foxit Reader, Wireshark, uTorrent, iTunes 9.0, ... sont également vulnérables.

D'après Acros Security, plus de 100 logiciels seraient concernés par le problème. Et, au fur et à mesure des tests, la liste pourrait s'allonger...

Comme le problème ne vient pas de la plateforme de Microsoft, il n'y aura pas un correctif de Windows mais bien un correctif par application pour règler le problème.

En attendant, la plus grande vigilance est recommandée envers les DLL distantes. Microsoft conseille à ses utilisateurs de désactiver l'appel de librairies depuis WebDAV, ainsi que de désactiver le service WebClient tout en bloquant les ports TCP 139 et 445.

La suite au prochain numéro...

Source : exploit-db.com

**ILP** · 26/08/2010, 09h30

Plus de 100 logiciels ? Des milliers je pense ! Quand je regarde les API Windows de Borland par exemple je vois ça :

Code Pascal :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{...}
const
{...}
 
{$IFDEF MSWINDOWS}
  shell32 = 'shell32.dll';
{$ENDIF}
{$IFDEF LINUX}
  shell32 = 'libshell32.borland.so';
{$ENDIF}
 
implementation
 
function CommandLineToArgvW; external shell32 name 'CommandLineToArgvW';
function DoEnvironmentSubst; external shell32 name 'DoEnvironmentSubstA';
function DoEnvironmentSubstA; external shell32 name 'DoEnvironmentSubstA';
function DoEnvironmentSubstW; external shell32 name 'DoEnvironmentSubstW';
procedure DragAcceptFiles; external shell32 name 'DragAcceptFiles';
procedure DragFinish; external shell32 name 'DragFinish';
{...}

C'est bien la preuve que la DLL shell32 n'est pas chargée à partir de son chemin complet. Donc toute les applis qui utilisent ShellAPI dans Delphi sont vulnérables aux attaques

.

**Shemsu-Hor** · 26/08/2010, 09h59

Plus de 100 logiciels ? Des milliers je pense !

Oui et avant que ce soit corrigé pour tous, y'a de quoi faire...

**Gordon Fowler** · 01/09/2010, 15h55

Gestion des DLL : Microsoft sort un outil automatisé de protection
En attendant une mise à jour et les correctifs des éditeurs

Mise à jour du 01/09/10

Il ne suffit pas de s'appeler Microsoft pour que les éditeurs corrigent leurs applications d'un coup de baguette magique. Malheureusement.

Résultats, Windows est toujours exposé au « DLL Preloading », une vulnérabilité présente dans de très nombreuses – et très populaires – applications comme Firefox, LiveMail, Office 2007, etc. (lire ci-avant pour plus de détails sur la liste et cette faille liée au pré-chargement des librairies).

Le problème tient au fait que la responsabilité de ces vulnérabilités n'est pas imputable à Microsoft.

Qu'à cela ne tienne, ses équipes de sécurité planchent durement sur le dossier.

La première solution proposée était particulièrement peu « user friendly », une dimension importante à prendre en compte si l'on veut que les utilisateurs appliquent les correctifs.

Microsoft proposait - et propose toujours - une nouvelle entrée de Registre, baptisée CWDIllegalInDllSearch, pour contrôler l'algorithme de recherche de chemin d'accès aux fichiers DLL (lire ci-avant).

« Une fois installé, cet outil a encore besoin d'être configuré pour bloquer les comportements malicieux et nos clients nous ont demandé quels étaient les paramètres recommandés », explique Jerry Bryant, porte parole de Microsoft dans cette affaire. « En conséquence de quoi, [nos équipes] ont travaillé pour développer un "Fix-It" qui active par défaut les paramètres que nous recommandons et qui bloquerons la plupart des vecteurs d'attaque distante ».

Mais cette solution, qui consiste à appliquer le premier outil puis le Fix-It, n'est toujours pas simple. En tout cas pas assez pour les non-experts en sécurité.

Microsoft en a bien conscience : « beaucoup d'entreprises nous ont demandé de rendre plus facile l'application de cet outil », admet Bryant.

Redmond réfléchit donc à présent à la manière d'intégrer ces défenses directement dans une prochaine mise à jour de ses OS.

Ces deux outils devraient faire leur apparition en priorité dans le prochain Windows Update de Windows Server (« dans les deux semaines », estime aujourd'hui Bryant), puis pour le grand public (Windows XP, Vista, 7). Sans autre précision sur la date de sortie de cette mise à jour pour cette catégorie d'utilisateurs.

La nouvelle entrée de Registre CWDIllegalInDllSearch est disponible ici
Le Fix-It est disponible là

Pour mémoire, Microsoft propose aussi la solution de désactiver le service WebClient et de bloquer les ports TCP 139 et 445

Source : Billet sur le Microsoft Securtity Response Center

Et vous ?

Avez-vous appliqué ces protections ou attendez-vous la mise à jour intégrée à Windows Update ?

**kimz** · 02/09/2010, 10h55

Envoyé par Gordon Fowler

[B][SIZE="4"]Et vous ?

Avez-vous appliqué ces protections ou attendez-vous la mise à jour intégrée à Windows Update ?

Nouvelle entrée de Registre CWDIllegalInDllSearch appliquée pour les serveurs et quelques PCs importants, pour le reste j'attends la mise à jour du second tuesday

Attaques en DLL preloading : Microsoft sort un outil (presque) automatisé de protection

Discussions similaires

Partager

Partager