Google Project zero: Révélation d'une vulnérabilité dans Windows 8.1 non patchée par Microsoft

Google a divulgué de nouveaux détails au sujet d'une faille de sécurité dans Windows 8.1 cela fait suite à la non "réeusite" par Microsoft a patcher cette vulnérabilité. Cette fois, la divulgation en question par Google est remarquable car la vulnérabilité permet d'attaquer le sandbox de Google Chrome, d'Adobe Reader et d'autres produits.

Le sandbox de Chrome sert de couche de sécurité supplémentaire en cas ou des vulnérabilités sont découvertes dans le navigateur. Actuellement Le sandbox de Chrome dépend du système d'exploitation sous-jacent. "Alors que vous pouvez essayer d'utiliser toutes les fonctionnalités de sécurité disponibles, parfois le développeur du système d'exploitation finit par subvertir à vos efforts", tel était le thème de la présentation faite par James Forshaw chercheur pour le projet Google Zéro au Shmoocon et au Nullcon (Documents ci- dessous)

The Windows Sandbox Paradox

Lire plus de publications sur Calaméo

Forsaw remarque que pour s'extraire d'un sandbox exige d'habitude plusieurs fragilités qui pour lui ne pourraient pas sembler sérieuses, mais si combiner permettre d'attaquer un système. Aussi dans ce cas plusieurs failles combinés créer l'agitation .

Le navigateur Google Chrome utilise une fonction appelée “job object” qui augmente la sécurité du sandbox. car les tâches dans “job object” peuvent être groupé et la quantité et le type de ressources utilisables par les processus sont limité. Dans plusieurs cas ceci peut aussi être utilisé pour limiter ce qu'un processus peut effectuer.

Microsoft a intégré dans Windows 8.1 un «pilote pour la console" qui peut être utilisé pour contourner ses limitations. La publication elle-même ne permet pas de sortir du sandbox de Google Chrome, mais en la combinant avec d'autres bugs trouvés, celui-ci peut être abusé pour sens extraire.

Google a signalé le problème le 9 Décembre 2014 et depuis lors, Microsoft avait 90 jours pour le résoudre. Cependant, Microsoft a déjà signalé à Google qu'il ne corrigerai pas le bug. Forsaw comprend la décision de Microsoft, écrit-il dans l'analyse de la vulnérabilité,

"je peux comprendre pourquoi Microsoft ne veut pas combler cette faille, cela serait compliqué pour des raisons de compatibilité ascendante et changeante."

Néanmoins une solution est possible selon le chercheur de Google en attendant que Google Chrome emploie une méthode différente pour protéger le bac à sable ce qui semble être inévitable.

Voici une traduction de la publication sur le blog Projet Zéro

Windows Job Objects:

Voici la description sur ce qu'est réellement un job Object est comment Chrome l'utilise. Strictement parlant, un job Object n'est pas une caractéristique de sécurité, à la place, son action est de regrouper les processus connexes pour restreindre le type et la quantité de ressources communes que les processus sont autorisés à utiliser. Si vous utiliser Unix, il est semblable à ulimit, mais à bien des égards plus puissant. Dans certaines circonstances, vous pouvez l'utiliser pour limiter ce que peut faire un processus; par exemple, le moteur de rendu de Chrome utilise les job Objects suivant:

Ce job Object restreint l'accès aux diverses fonctionnalités d'interface utilisateur, tels que le presse-papiers, mais il limite aussi le nombre de processus actif à 1 seul. Cela signifie que même s'il le voulait, le moteur de rendu serait bloqué dans la création de nouveaux processus, et cette restriction est appliquée dans le noyau.

Ceci est seulement une barrière lors de l'exécution avec un jeton restrictif (ex ici). Sinon, lors de l'exécution en tant qu'utilisateur normal, vous pouvez utiliser les services du système tels que WMI ou le Planificateur de tâches pour y échapper.

Il y a quelques vulnérabilités qui bénéficient de la possibilité de créer de nouveaux processus (par exemple) Alors que casser le job Object n'est pas une fuite immédiate du sandbox, cela serait utile en tant que partie d'une chaîne d'exploits. Alors maintenant, nous allons passer à la vulnérabilité qui vous permet de sortir de job Object.

Vulnérabilité du pilote de console:

Dans les premières versions de Windows (c'est-à-dire XP et systèmes antérieur) la fenêtre de console était en réalité traitée par le sous-système d'exécution de client/serveur, plus connus sous le nom CSRSS.

Ce sous-système met en œuvre les composants de mode utilisateur du système de Windows Win32. Mais ceci avait des inconvénients, aucuns thèmes ne pouvaient être appliquer sur cette fenêtre correctement, c'est pourquoi la fenêtre de console était activable sur XP qu'avec une commande via le menu exécuter.

Ainsi dans les versions postérieures de Windows un nouveau processus, conhost.exe, a été présenté, celui-ci serait engendré sur le bureau de l'utilisateur pour traiter la fenêtre de console. Cependant, CSRSS est toujours impliqué dans création du processus de conhost.

Tout a changé dans Windows 8.1. Au lieu que CSRSS soit responsable, un nouveau pilote du noyau, condrv.sys a été introduit. Le pilote expose l'objet de périphérique \Device\ConDrv, qui est accessible à n'importe qu'elle utilisateur, même avec le sérieux le moteur de rendu de Chrome qui est verrouillé. En fait il n'y a aucun moyen connu de suppression de l'accès au pilote.

Les commandes sont transmises au pilote en utilisant des codes de contrôle périphérique IO. La commande d'intérêt est CdpLaunchServerProcess qui est responsable de la création de l'exécutable de conhost. Appeler ceci directement est un peu compliqué, en particulier sur les versions 64 bits de Windows, si au lieu de cela nous pouvons simplement appeler l'API Windows AllocConsole , il le fera pour nous.

Regardons le code que CdpLaunchServerProcess appel pour créer un nouveau processus de conhost.exe.

Il y a deux choses très importantes à noter dans ce bout de code qui est directement liée à la vulnérabilité. Tout d'abord, il appelle Zw un formulaire d'appel du système NtCreateUserProcess. Ce préfixe indique que l'appel système sera expédié comme si c'était un appel système venant du mode noyau par opposition au mode utilisateur.

Ceci est important car cela signifie que les contrôles de sécurité sont ignorés dans le processus de création. Si le pilote avait appelé la forme Nt normale, il n'aurai pas été possible d'échapper à quelque chose comme le moteur de rendu de Chrome, car sans le fichier conhost.exe il ne peut être ouvert sans (l'ouverture l'entraînerait un accès refusé) faire échouer cette fonction.

La deuxième chose importante est le passage du drapeau de PROCESS_BREAKAWAY_JOB pour les drapeaux de processus. Alors que la fonction n'est pas documentée, mais par la retro-ingénierie du code du noyau, vous trouverez que le drapeau indique que le nouveau processus ne devrait pas être dans le même travail que le parent.

Cela signifie qu'un job Object restrictif peut être échappé. Pendant le traitement de cet indicateur dans le noyau une vérification est effectuée dans SeTcbPrivilege; cependant, comme la vérification est en cours d'exécution comme venant du mode noyau (nouveau en raison de l'appel de fonction Zw) cette vérification est contournée indépendamment de l'appelant.

Le résultat final est le suivant:

Les contrôles de sécurité des fichiers sont contournés menant au processus de conhost en cours de création.

Le Job restrictif est contourner en raison de l'adoption du drapeau de PROCESS_BREAKAWAY_JOB.

Pour certains utilisateurs de job Object restrictif, telles que les processus de GPU Chrome ou Adobe Reader, tout ce que vous devez faire est d'appeler AllocConsole. Mais comme nous le verrons, cela n'est pas si simple avec le moteur de rendu de Chrome.

Exploiter la question dans un moteur de rendu Chrome

Nous voulons essayer d'exploiter cela à partir moteur de rendu de Chrome, qui sont les processus les plus bas du sandbox verrouillés utilisés dans Chrome. Le premier défi est d'obtenir l'exécution de code à l'intérieur du cadre de la fonction de rendu pour tester l'exploit.

Test Code personnalisé dans un moteur de rendu

La pensée évidente est d'utiliser un injecteur de DLL , malheureusement, cela est plus facile à dire qu'à faire. Le jeton primaire pour un processus de rendu est si restrictif qu'il est presque impossible de l'obtenir pour ouvrir un fichier sur le disque ainsi, tandis que vous pouvez injecter un nouveau fil pour charger la DDL, le fichier échouera à l'ouverture.

Maintenant, vous pouvez simplement recompiler Chrome avec quelques modifications sur la politique du sandbox pour permettre l'accès à un emplacement arbitraire sur le disque, mais à partir de M37 il y a un moyen pour tricher et il suffit d'utiliser une version release build . M37 ajoute le support DirectWrite pour le rendu des polices, ceci afin de faciliter la règle de politique de sandbox qui a été ajouté afin de permettre l'accès en lecture au dossier de polices par Windows.

Par conséquent, si nous écrivons la DLL dans % windir%\Fonts nous pouvons obtenir le chargement. Un peu hacky sûr, mais cela fonctionne. Bien sûr, pour ce faire, vous devez déjà avoir le code exécuté en tant qu'administrateur sur le système il est donc pas une menace pour la sécurité de Chrome. Nous devrons aussi modifier quelques paramètres de construction de la DLL, en supposant que vous utilisez Visual Studio:

Retrait du manifeste car avec le sandbox restrictif cela ne fonctionne pas
    
Une liaison statique avec le DLL car vous ne pourrez pas facilement être en mesure d'ouvrir d'autres DLL fois initialisé

Test de l'Exploit

Avec un fichier DLL qui peut être ouvert par le moteur de rendu de Chrome nous pouvons injecter un fil, appelez LoadLibrary et obtenir le code exécuté dans le processus. Comme un premier test nous allons essayer et appellé AllocConsole et voir ce qui se passe. Si nous y jetons un œil en utilisant Process Monitor nous voyons le processus de conhost en cours de création, mais il ne s'exécute jamais, en fait, il quitte presque immédiatement avec un statut négatif de sortie.

Si nous convertissons l'état de sortie d'un entier non signé, nous obtenons 0xC0000022 qui correspond à STATUS_ACCESS_DENIED. Clairement, quelque chose est pas heureux et tue le processus. Pour comprendre ce qui va mal, regardons le code après la création du processus.

Le code ne fait que créer le processus, puis il crée un nouveau handle pour l'objet de l'appareil actuel sur la console, de sorte qu'il peut passer sur la ligne de commande pour le processus de conhost. De la même façon qu'avec ZwTerminateProcess car c'est la seule façon dont le processus pourrait être arrêté.

Nous allons observé le flux de contrôle pour voir si ObOpenObjectByPointer retourne STATUS_ACCESS_DENIED en essayant de créer un nouveau handle. Mais comment cela peut-il être, nous avons ouvert le fichier de périphérique d'origine, il devrait être possible de le rouvrir avec les mêmes droits d'accès? Eh bien non, parce que le FILE_OBJECT a un descripteur de sécurité associé et la DACL ne donne pas facilement l'accès au jeton très réstrictif GENERIC_ALL.

Comme nous pouvons le voir dans la capture d'écran ci-dessous il nous manque une entrée pour le jeton du moteur de rendu restreint SID (S-1-0-0) qui aurait permis au jeton de vérification restreint de réussir.

Ne vous laissez pas berner par l'entrée de groupe restreinte. Cela est juste une convention pour l'utilisation de jetons restrictifs, sauf si le jeton est créé avec ce groupe en tant que SID restreint, il ne fait rien. Donc, cela signifie que nous ne pourrons jamais exploiter ce bug dans Chrome? Bien sûr que non, nous avons juste besoin de comprendre comment DACL du FILE_OBJECT arrive pour être fixé.

Contrairement aux fichiers et clés de registre qui héritent généralement leur DACL du conteneur parent, les objets du noyau à la place obtiennent leur DACL par défaut d'un domaine particulier dans le jeton d'accès actuel.

Nous pouvons modifier le jeton DACL par défaut actuel en passant une structure appropriée à SetTokenInformation avec TokenDefaultDacl pour classer de l'information. Nous pouvons faire cela sans avoir besoin de privilèges spéciaux. Mais est-ce réglé pour ce DACL? Si nous regardons les jeton d'accès de groupes activés nous avons seulement le SID d'utilisateur actuel et le SID d'ouverture de session.

Cependant, comme le jeton est également un jeton restreint, nous devons donner accès à un SID restreint (S-1-0-0, NULL SID) sinon le contrôle d'accès échouera toujours. Donc, nous allons changer le DACL par défaut pour spécifier le plein accès au SID d'ouverture de session NULL SID.

Maintenant, après avoir réglé le DACL actuelle, nous pouvons essayer de nouveau, mais AllocConsole n'y parvient toujours pas. Cependant en regardant le code d'erreur que nous avons au moins obtenu après le problème initial. Process Monitor montre le code de sortie du processus comme STATUS_DLL_NOT_FOUND, qui nous indique ce qui se produit.

Lors du premier fil du processus, il ne démarre pas directement au point d'entrée de processus. Au lieu de cela il lance une pièce spéciale de code à l'intérieur NTDLL pour initialiser le processus actuel, LdrInitializeThunk. Cette fonction est responsable de la numérisation des DLL importées du processus, de les charger dans la mémoire et appeler leurs fonctions d'initialisation. Dans ce cas, le jeton de processus est si restrictif que nous ne pouvons même pas ouvrir les fichiers DLL typiques.

Heureusement, il existe une fenêtre de temps entre le processus en cours de création et le fil initial, celui-ci étant repris avec ZwResumeProcess. Si nous pouvons saisir le processus au sein de cette fenêtre, nous pouvons simplement initialiser le processus comme une coquille vide. Mais comment pouvons-nous faire cela?

Capturer un nouveau Processus

Le moyen le plus évident pour l'exploite,r serait d'ouvrir le nouveau processus pendant la fenêtre de temps puis appelez NtSuspendProcess sur l'handle. Cela fonctionnerai car suspend/resume références les opérations de comptage. Le processus commence avec un nombre de suspension de 1, comme le pilote du noyau créé le handle initial avec le drapeau CREATE_SUSPENDED, donc si nous pouvons appeler NtSuspendProcess rapidement nous pouvons incrémenter en 2.

Le pilote décrémente alors le comte en appelant ZwResumeProcess, cependant le nombre tombera à 1 et le noyau laissera le fil suspendu. Nous pouvons alors manipuler le nouveau processus pour supprimer le code d'initialisation et le faire fonctionner à l'extérieur du job Objet.

Mais il ya un gros problème avec ce plan. Normalement, lorsque vous créez un nouveau processus un handle pour celui-ci est retourné, mais ce n'est pas le cas ici car le pilote du noyau ferme seule l'handle reservé au noyau avant de le retourner vers l'appelant. Par conséquent, nous devons ouvrir le processus par son PID, mais cela pourrait être délicat.

Les versions modernes de Windows n'incrémenter pas simplement un PID, à la place est réutilisés de vieux PID après une certaine période. Nous pouvons simplement continuer à deviner, mais chaque mauvaise conjecture est du temps perdu. Vous verrez qu'une approche en force brute est à peu près irréalisable.

Ainsi sommes-nous coincés? Bien sûr que non, nous avons juste besoin d'utiliser des fonctionnalités non documentées. Le noyau expose un appel système, NtGetNextProcess qui, comme son nom l'indique obtient le processus suivant. Mais à côté de quoi? Si vous avez fait des Windows Internals, vous aurez su que les objets de processus sont enchaînés dans une grande liste liée dans le noyau. Cet appel système prend l'handle pour un objet processus et trouve le processus suivant dans la chaîne qui peut être ouverte par l'utilisateur courant.

Actif par défaut il n'y a pas d'autres processus que celui actuel qui puisse ouvrir la liste, même elle-même ne le peux pas cela et due à cette embêtante DACL par défaut. Cela signifie normalement que NtGetNextProcess échoue toujours. Mais lorsque le nouveau processus de conhost créé hérite de la nouvelle DACL par défaut modifiée que nous pouvons accéder, cela signifie que nous pouvons nous placer que dans une très petite boucle en appelant NtGetNextProcess jusqu'à ce qu'il réussisse.

L'handle qui est renvoyé est certainement conhost afin que nous puissions rapidement suspendre le processus, et maintenant on peut prendre autant de temps que nous le voulons. Nous devons faire ceci dans un fil car AllocConsole bloquera, mais ce n'est pas un problème. Ainsi, par exemple:

Donc, avec un handle pour le processus de conhost nous pouvons modifier LdrInitializeThunk pour l'empêcher d'échouer et injecter un peu de shellcode. Vous aurez seulement les services de NTDLL car aucun autre DLL ne peut dresser la carte interne. Encore l'objectif a été atteint, vous pouvez maintenant échapper à un Job Objet restrictif, même avec un tel processus verrouillé. Ce que vous faites avec maintenant, ce pouvoir est à vous.

Conclusions

Alors à quoi ça sert? Eh bien a pas grand chose, au moins à s'extraire d'un sandbox. Cela affaiblit juste un peu les défenses et ouvre un champ d'attaque pour exploiter d'autres questions. Je peux comprendre pourquoi Microsoft ne veux pas patcher, il agit de cette manière pour des raisons de compatibilité, cela serait pour eu difficile. Cela dit, je crois que cela pourrait être fait car travailler dans le contexte de sécurité du processus actuel d'appel D'API alors que peux d'applications utilisent ces jetons restrictifs comme les sandbox pour application.

Aussi Chrome travaille à faire des efforts supplémentaires pour atténuer les problèmes de sécurité. Par exemple, alors la cassure d'emploi élimine les restrictions d'emploi UI imposées Chrome utilise maintenant lockdown win32k sur toutes les plateformes concernées, qui, autant que je puisses dire ne peut pas être désactivé même dans les childs process. les réductions de sécurité continuent d'évoluer, mais profitant des nouvelles fonctionnalités d'une plate-forme, les régressions de sécurité sont inévitables. Un sandbox bien développé ne devraient pas compter sur la fonction d'une plate-forme pour être sûr, car cette fonctionnalité pourrait se casser à tout moment.

Source:GoogleProjetZéro

et Mice.com