Définitions relatives à la qualité des rapports dans le cadre des programmes de primes aux bogues de Microsoft

Microsoft met tout en œuvre pour traiter les vulnérabilités signalées dans les meilleurs délais. L’un des facteurs qui influencent le délai de résolution d'une vulnérabilité repose sur le délai nécessaire à l’évaluation de la cause racine, de la gravité et de l’impact de la vulnérabilité. Dans la pratique, le délai nécessaire à Microsoft pour évaluer une vulnérabilité dépend beaucoup de la qualité des informations qui accompagnent un rapport de vulnérabilité.

Pour aider les chercheurs en sécurité à mieux comprendre les informations dont nous avons besoin pour accélérer l’évaluation d’une vulnérabilité, nous avons défini trois niveaux de qualité en matière de rapport de vulnérabilité : faible, moyen et élevé. Ces niveaux de qualité sont résumés dans le tableau ci-dessous. Nous encourageons tous les utilisateurs à fournir, si possible, des rapports de qualité supérieure, et nos programmes de primes les y incitent en offrant des récompenses plus élevées pour les rapports de qualité supérieure.

Bien que nous privilégiions les rapports de qualité supérieure, nous sommes toujours curieux d'en apprendre davantage sur les vulnérabilités qui affectent Microsoft. Dès lors, nous encourageons les chercheurs à signaler les vulnérabilités, même s’ils ne sont pas en mesure de fournir des rapports de qualité supérieure.

 

Qualité

Description

Informations requises

Faibles

Un rapport de vulnérabilité de qualité inférieure fournit suffisamment d’informations pour reproduire la vulnérabilité, mais n’inclut pas de preuve de concept fiable.

  • Type de vulnérabilité
  • Composant concerné (nom, version)
  • Environnement cible concerné (type, version)
  • Sortie de reproduction de la vulnérabilité (sortie du débogueur, capture d’écran, etc.)
  • Preuve de concept

Moyenne

Un rapport de vulnérabilité de qualité moyenne améliore un rapport de qualité inférieure en fournissant une preuve de concept fiable et réduite.

  • Toutes les informations requises par un rapport de qualité inférieure
  • Preuve de concept fiable et réduite

Élevées

Un rapport de vulnérabilité de qualité supérieure améliore un rapport de qualité moyenne en fournissant une analyse détaillée et précise de la vulnérabilité.

  • Toutes les informations requises par un rapport de qualité moyenne
  • Analyse détaillée er précise
Explanation of information required

Information

Explication

Type de vulnérabilité

Classification du type de vulnérabilité signalée, telle que l’utilisation de scripts intersites gratuits, etc. Pour des exemples de types de vulnérabilités, vous pouvez consulter https://nvd.nist.gov/vuln/categories.

Composant concerné

Composant ou service concerné par la vulnérabilité. Doit inclure le nom du composant, ainsi que les informations de version pertinentes.

Environnement cible concerné

Environnement cible concerné par la vulnérabilité, système d’exploitation ou application concerné(e), par exemple. Doit inclure une description de l’environnement cible, avec son nom et les informations de version pertinentes.

 

Pour les cibles Windows, cela doit inclure la chaîne BuildLabEx disponible ici :

 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\BuildLabEx

Sortie de reproduction de la vulnérabilité

Sortie d’une reproduction réussie de la vulnérabilité. Il peut s’agir de la sortie du débogueur, d’une capture d’écran, d’une vidéo ou d’un autre format illustrant une reproduction du problème. Des informations plus détaillées, telles que la sortie du débogueur sont préférables.

Preuve de concept

Description de la vulnérabilité sous forme de texte, de code ou autre selon la nature de la vulnérabilité. Cette description doit inclure toutes les étapes requises pour déclencher la vulnérabilité. Toutes les informations sur la façon dont la cible doit être configurée pour déclencher la vulnérabilité doivent aussi y figurer.

Preuve de concept fiable et réduite

Preuve de concept qui reproduit automatiquement la vulnérabilité (avec du code, par exemple), le cas échéant. Cette preuve de concept doit :

 

  • Fonctionner avec des modifications système minimales ou inexistantes
  • Être réduite (absence d'instructions redondantes ou non pertinentes)
  • Être reproductible de façon fiable dans un laps de temps raisonnable

Analyse détaillée et précise

Cette analyse doit décrire la manière dont chaque partie de la preuve de concept affecte la cible en termes de déclenchement de la vulnérabilité. En outre, l’analyse doit inclure des informations sur la façon dont la synchronisation, l’environnement ou d’autres contraintes affectent le déclenchement de la vulnérabilité. Dans la mesure du possible, cette analyse doit également décrire la cause racine de la vulnérabilité.

Exemple de rapport de qualité supérieure

Windows :
Contournement de l’atténuation de création de point d’analyse de montage dans un bac à sable
Plateforme :
Windows 10 (build 10240), les versions antérieures ne disposent pas de la fonctionnalité
Classe :
Contournement des fonctionnalités de sécurité
Programme de primes :
Programme de primes de contournement d'atténuation
Résumé :
Une atténuation ajoutée à Windows 10 pour empêcher la création de points d’analyse de montage NTFS à des niveaux d’intégrité inférieurs au niveau moyen peut être contournée.
Description :
Windows 10 a ajouté de nouvelles atténuations pour bloquer la création ou modifier le comportement de certains liens symboliques émis par un processus de faible intégrité/bac à sable. L’objectif présumé consiste à compliquer le recours à de telles astuces pour sortir d’un bac à sable.
 
Dans les versions précédentes de Windows 10, les points d’analyse de montage NTFS étaient bloqués directement à partir d’un processus de bac à sable. Toutefois, dans la build 10240 (censée être une version finale), le contrôle a été déplacé vers le noyau dans IopXXXControlFile et légèrement modifié pour permettre aux processus de bac à sable de créer des points de montage. La vérification ressemble à ce qui suit :
 
if (RtlIsSandboxedProcess()) { 
   if(ControlCode == FSCTL_SET_MOUNT_POINT) { 
       if (FsRtlValidateReparsePointBuffer(buffer) && buffer->ReparseTag == TAG_MOUNT_POINT) { 
         NTSTATUS status = ZwOpenFile(..., buffer->ReparseTarget, FILE_GENERIC_WRITE, ... , FILE_DIRECTORY_FILE); 
        if (!NT_SUCCESS(status)) { 
         return status; 
       } 
   } 
}
 
Ainsi, le noyau vérifie que la cible du point de montage correspond à un répertoire et que le processus actuel dispose d’un accès en écriture au répertoire. Cela suffit à limiter la capacité d’un processus de bac à sable à abuser de ce processus pour écrire des fichiers avec des privilèges plus élevés. Malheureusement, cette vérification peut présenter un problème inattendu, le processus de bac à sable peut rediriger l’appel ZwOpenFile de façon arbitraire vers un fichier qu’il peut ouvrir à des fins d'écriture, mais la valeur d’origine est définie en tant que point de montage. En effet, la vérification à l'ouverture du fichier intervient à l’intérieur du processus qui effectue l’appel, ce qui signifie qu’elle répond au mappage d’appareil de l’utilisateur.
 
Bien que le processus de bac à sable ne permette pas de modifier les mappages de lecteurs par utilisateur, il peut modifier le mappage d'appareils à l'aide de NtSetInformationProcess avec la classe d’informations ProcessDeviceMap. La création de répertoires d’objets et de liens symboliques arbitraires étant possible (présentant également une atténuation et empêchant dès lors un processus avec privilèges plus élevés, ce dont nous ne soucions pas), nous pouvons générer un mappage d'appareils fictif qui redirige l'ouverture vers un autre répertoire. \Device\NamedPipe\ (notez la barre oblique de fin) constitue une bonne cible en permettant une ouverture à partir de n’importe quel niveau de privilège (y compris les processus renderer Chrome) pour l’accès en écriture et en tant que répertoire. Aussi, si nous souhaitons définir un point de montage arbitraire sur \??\c:\emplacement, nous pouvons créer quelque chose qui ressemble à ce qui suit :
 
<UNNAMED>(DIR) -> C:(DIR) -> somewhere(LINK to \Device\NamedPipe\)
 
Si nous définissons le répertoire sans nom sur le mappage d'appareils de processus, nous pouvons ignorer la vérification et créer le point de montage.
 
Par exemple, dans une perspective de correction, vous pouvez interroger le chemin ouvert et l’utiliser pour écrire sur le point d’analyse NTFS plutôt que d’utiliser la valeur d’origine.
 
Preuve de concept :
J’ai fourni une preuve de concept afin de démontrer le contournement. Elle doit être exécutée à faible intégrité à l’aide de psexec ou en modifiant la liste de contrôle d’accès du fichier exécutable sur faible. Veillez à utiliser la version appropriée pour l’architecture sur Windows, car un bogue dans NtSetInformationProcess semble empêcher les applications WOW64 de définir le mappage d'appareils de processus. Vous pouvez comparer l’opération avec l’outil mklink de l’interface de commande qui ne peut créer le point de montage à faible intégrité. Procédez comme suit :
 
1) Extrayez la preuve de concept sur un disque dur local accessible en écriture par un utilisateur normal.
 
2) Exécutez le fichier exécutable poc avec faible intégrité en transmettant deux arguments, le chemin d’accès vers un répertoire où créer le point de montage (qui doit se trouver à un emplacement où un utilisateur à faible intégrité peut écrire, tel que AppData\Temp\Low) et le chemin d'accès du fichier arbitraire sur lequel définir le point de montage. Par exemple :

poc.exe c:\users\user\appdata\local\low\abc c:\notreal.
 
Résultat attendu :
Il ne doit pas être possible de créer un point de montage pointant sur un emplacement non accessible en écriture par un utilisateur à faible intégrité
 
Résultat observé :
Le point de montage est correctement créé.
 
Remerciements spéciaux à James Forshaw pour la qualité et la cohérence de ses soumissions Centre de réponse aux problèmes de sécurité Microsoft (MSRC).
 
 

Exemple de rapport de qualité inférieure

 

# win32kfull!NtGdiHLSurfGetInformation+0x11f kernel info leak 

## root cause 
the local kernel stack var KernerStackStuctVar is uninitialized. 
and direcly copy to usermode after call _GreSfmGetDirtyRgn@40. 
```cpp 
.text:0008718A ; int __stdcall NtGdiHLSurfGetInformation(int, int, void *, int) 
.text:0008718A public _NtGdiHLSurfGetInformation@16 
.text:0008718A _NtGdiHLSurfGetInformation@16 proc near 
.text:0008718A 
.text:0008718A KernerStackStuctVar = dword ptr -58h 
``` 
```cpp 
.text:0008729E push edi ; size_t 
.text:0008729F lea ecx, [ebp+KernerStackStuctVar] 
.text:000872A2 push ecx ; void * 
.text:000872A3 push eax ; void * 
.text:000872A4 call _memcpy ; xxxx 
``` 
```cpp 
"t": "ob", 
"v": { 
"pid": { 
"t": "nb", 
"v": 1044 
}, 
"tid": { 
"t": "nb", 
"v": 1108 
}, 
"imageName": { 
"t": "st", 
"v": "dwm.exe" 
}, 
"count": { 
"t": "nb", 
"v": 2 
}, 
"from": { 
"t": "st", 
"v": "NtGdiHLSurfGetInformation" 
}, 
"eip": { 
"t": "st", 
"v": "nt!memcpy+0x33" 
}, 
"data": { 
"t": "ob", 
"v": { 
"value": { 
"t": "n4", 
"s": false, 
"v": "0xaaaaaaaa" 
}, 
"type": { 
"t": "nu" 
} 
} 
}, 
"address": { 
"t": "n4", 
"s": false, 
"v": "0x36ef25c" 
}, 
"stacks": { 
"t": "ar", 
"v": [ 
{ 
"t": "st", 
"v": "win32kfull!NtGdiHLSurfGetInformation+0x11f" 
}, 
{ 
"t": "st", 
"v": "nt!KiSystemServicePostCall" 
}, 
{ 
"t": "nu" 
}, 
{ 
"t": "nu" 
} 
```