Partager via

Problèmes de sécurité pour les objets de section et les vues

  • Article

Les pilotes qui créent des sections et des vues qui ne doivent pas être partagées avec le mode utilisateur doivent utiliser le protocole suivant lorsqu’ils utilisent des sections et des vues :

  • Le pilote doit utiliser un handle de noyau lorsqu’il ouvre un handle à l’objet section. Les pilotes peuvent s’assurer qu’un handle est un handle de noyau en le créant dans le processus système ou en spécifiant l’attribut OBJ_KERNEL_HANDLE pour le handle. Pour plus d’informations, consultez Handles d’objet.

  • La vue doit être mappée uniquement à partir d’un thread système. (Sinon, la vue est accessible à partir du processus dans lequel elle est créée.) Un pilote peut s’assurer que la vue est mappée à partir du processus système à l’aide d’un thread de travail système pour effectuer l’opération de mappage. Pour plus d’informations, consultez Threads de travail système et Contexte de thread de pilote.

Les pilotes qui partagent une vue avec un processus en mode utilisateur doivent utiliser le protocole suivant lorsqu’ils travaillent avec des sections et des vues :

  • Le pilote, et non le processus en mode utilisateur, doit créer l’objet de section et mapper les vues.

  • Comme mentionné précédemment, le pilote doit utiliser un handle de noyau lorsqu’il ouvre un handle à l’objet section. Les pilotes peuvent s’assurer qu’un handle est un handle de noyau en le créant dans le processus système ou en spécifiant l’attribut OBJ_KERNEL_HANDLE pour le handle. Pour plus d’informations, consultez Handles d’objet.

  • La vue est mappée dans le contexte de thread du processus qui partage la vue. Un pilote de niveau supérieur peut garantir que la vue est mappée dans le contexte de processus actuel en effectuant l’opération de mappage dans une routine de répartition, telle que DispatchDeviceControl. Les routines de répartition des pilotes de niveau inférieur s’exécutent dans un contexte de thread arbitraire et ne peuvent donc pas mapper en toute sécurité une vue dans une routine de répartition. Pour plus d’informations, consultez Contexte du thread de pilote.

  • Tous les accès à la mémoire à la vue dans le pilote doivent être protégés par des blocs try-sauf . Une application malveillante en mode utilisateur peut annuler le mappage de la vue ou modifier l’état de protection de la vue. L’une ou l’autre causerait un blocage du système, sauf si elle est protégée par un bloc try-sauf . Pour plus d’informations, consultez Gestion des exceptions.

Le pilote doit également valider le contenu de la vue si nécessaire. L’enregistreur de pilotes ne peut pas supposer que seul un composant approuvé en mode utilisateur aura accès à la vue.

Un pilote qui doit partager un objet de section avec une application en mode utilisateur (qui doit pouvoir créer ses propres vues) doit utiliser le protocole suivant :

  • Le pilote, et non le processus en mode utilisateur, doit créer l’objet section. Les pilotes ne doivent jamais utiliser un handle passé à partir du mode utilisateur.

  • Avant de passer le handle en mode utilisateur, le pilote doit appeler ObReferenceObjectByHandle pour obtenir une référence à l’objet section. Cela empêche une application malveillante de supprimer l’objet section en fermant le handle. La référence d’objet doit être stockée dans l’extension de périphérique du pilote.

  • Une fois que le pilote n’utilise plus l’objet section, il doit appeler ObDereferenceObject pour libérer la référence d’objet.

Sur les systèmes qui exécutent Microsoft Windows Server 2003 avec Service Pack 1 (SP1) et versions ultérieures, seuls les pilotes en mode noyau peuvent ouvrir \Device\PhysicalMemory. Toutefois, les pilotes peuvent décider de donner un handle à une application utilisateur. Pour éviter les problèmes de sécurité, seules les applications utilisateur approuvées par le pilote doivent avoir accès à \Device\PhysicalMemory.