Google contre Microsoft ; l'équipe de recherche de Google rend publiques deux autres vulnérabilités de Windows 7/8

La guerre entre Google et Microsoft s’intensifie alors que Google révèle deux autres vulnérabilités de Windows 7 et Windows 8.

L’équipe de recherche de Google a rendu publiques deux autres vulnérabilités non corrigées de Windows jeudi après l’expiration de la période d’attente auto-imposée de 90 jours de Google Project Zero avant de divulguer les détails des bugs.

Microsoft, qui n’a pas pris ces divulgations publiques à la légère, a déclaré qu’il corrigerait l’une des deux vulnérabilités dans son prochain bulletin de sécurité de Patch Tuesday de février. La seconde faille, semble-t-il, n’est pas un problème de sécurité majeur.

Les lecteurs se souviendront que l’équipe de recherche de Google avait rendu publique une vulnérabilité d’escalade de privilèges dans Windows 7 après l’expiration de la période d’attente auto-imposée de 90 jours. La divulgation de Google le 29 décembre a ravivé les débats sur la divulgation entre les passionnés de sécurité et a suscité acrimonie et postures publiques de la part des deux entreprises.

Microsoft souhaite que Google suive un programme de divulgation coordonnée des vulnérabilités et a demandé à Google de retenir sa divulgation de la vulnérabilité jusqu’aux bulletins de sécurité de janvier, qui ont été publiés cette semaine. Google, d’autre part, s’appuie sur son moratoire auto-imposé de 90 jours, donc il a refusé et a poursuivi sa divulgation.

Chris Betz de Microsoft a déclaré que : « Bien que le suivi respecte le calendrier annoncé par Google pour la divulgation, la décision semble moins relever de principes et plus d’un ‘gotcha’, les clients étant ceux qui pourraient en souffrir. Ce qui est bon pour Google n’est pas toujours bon pour les clients. Nous exhortons Google à faire de la protection des clients notre objectif collectif principal. »

La guerre entre les géants de la technologie est loin d’être terminée alors que l’équipe de recherche de Google a rendu publiques deux autres vulnérabilités de Windows. Les deux vulnérabilités sont reproduites ci-dessous :

Problème n° 127 signalé à Microsoft le 17 octobre 2013 rendu public le 15 janvier 2014

Plateforme : Windows 7 32/64 bits, Windows 8+ non vulnérable
Classe : Contournement de sécurité L’appel système NtPowerInformation effectue une vérification que l’appelant est un administrateur avant d’exécuter certaines fonctions d’alimentation spécifiques. La vérification est effectuée dans la fonction PopUserIsAdmin. L’implémentation brute est : BOOLEAN PopUserIsAdmin() {
SECURITY_SUBJECT_CONTEXT ctx; SeCaptureSecurityContext(&ctx); return SeTokenIsAdmin(SeQuerySubjectContextToken(&ctx));
} Sur Windows 7, cette vérification peut être contournée car la fonction SeTokenIsAdmin ne prend pas en compte le niveau d’imitation du jeton et le reste du code ne le prend pas non plus en compte. Par conséquent, vous pouvez imiter un jeton d’administrateur en tant qu’utilisateur normal (via un jeton lié ou en kidnappant un jeton système) et appeler les fonctions protégées. Sur Windows 8+, la méthode SeTokenIsAdmin a été modifiée pour vérifier le niveau d’imitation, donc elle n’est pas vulnérable. Il n’est pas clair si cela a un impact sérieux sur la sécurité ou non, donc cela est divulgué tel quel. Certaines fonctions sont également vérifiées par un contrôle de privilèges, cependant le contexte du sujet est capturé séparément, donc il existe une fenêtre TOCTOU entre les vérifications qui pourrait être exploitée. Pour les besoins de la PoC, j’ai choisi d’utiliser la fonction 45 « PopRequestPowerListInfo » (qui ne nécessite aucun truc spécial). De plus, cette fonction présente une vulnérabilité théorique de débordement d’entier en fonction de la taille que vous pouvez pousser pour PopPowerRequestObjectCount. Ci-joint un simple PoC qui démontre le problème pour exécution sur Windows 7. Pour reproduire, suivez les étapes. 1) Assurez-vous de fonctionner en tant qu’administrateur de jeton fractionné, c’est parce que le PoC utilise le jeton lié pour obtenir un jeton d’administrateur. Pour un utilisateur normal, vous pourriez simplement capturer un jeton d’un service.

2. Exécutez le PoC, il devrait effectuer des appels, un sans imitation et un avec. Résultat attendu :
   Les deux appels devraient retourner STATUS_ACCESS_DENIED (0xC0000022) Résultat observé :
   La première vérification échoue avec STATUS_ACCESS_DENIED tandis que la seconde réussit avec STATUS_SUCCESS. PoC à télécharger => 1 2

Problème n° 128 signalé à Microsoft le 17 octobre 2013 rendu public le 15 janvier 2014

Plateforme : Windows 7, 8.1 Update 32/64 bits
Classe : Contournement de sécurité/Divulgation d’informations La fonction CryptProtectMemory permet à une application de chiffrer la mémoire pour l’un des trois scénarios, processus, session de connexion et ordinateur. Lors de l’utilisation de l’option de session de connexion (drapeau CRYPTPROTECTMEMORY_SAME_LOGON), la clé de chiffrement est générée en fonction de l’identifiant de session de connexion, cela est destiné à partager la mémoire entre les processus s’exécutant dans la même connexion. Comme cela pourrait également être utilisé pour envoyer des données d’un processus à un autre, il prend en charge l’extraction de l’identifiant de session de connexion à partir du jeton d’imitation. Le problème est que l’implémentation dans CNG.sys ne vérifie pas le niveau d’imitation du jeton lors de la capture de l’identifiant de session de connexion (en utilisant SeQueryAuthenticationIdToken) donc un utilisateur normal peut imiter au niveau d’identification et déchiffrer ou chiffrer des données pour cette session de connexion. Cela pourrait être un problème s’il y a un service qui est vulnérable à une attaque de plantation de tuyau nommé ou qui stocke des données chiffrées dans une section de mémoire partagée lisible par le monde. Ce comportement est bien sûr peut-être un design, cependant n’ayant pas été partie prenante du design, il est difficile de le dire. La documentation indique que l’utilisateur doit imiter le client, ce que je comprends comme signifiant qu’il devrait être capable d’agir au nom du client plutôt que de s’identifier comme le client. Ci-joint un simple PoC qui démontre le problème. Pour reproduire, suivez les étapes. 1) Exécutez Poc_CNGLogonSessionImpersonation.exe depuis la ligne de commande

2. Le programme devrait imprimer « Le chiffrement ne correspond pas » pour indiquer que les deux chiffrages des mêmes données n’étaient pas identiques, impliquant que la clé était différente entre eux. Résultat attendu :
   Les deux appels devraient retourner les mêmes données chiffrées, ou le second appel devrait échouer Résultat observé :
   Les deux appels réussissent et retournent des données chiffrées différentes PoC à télécharger => Fichier Zip

Microsoft ne corrigera qu’une des vulnérabilités dans son Patch Tuesday de février, déclarant que l’autre vulnérabilité n’est pas un risque de sécurité. Les deux Microsoft et Google ont déclaré qu’ils n’ont aucune preuve que l’une des trois vulnérabilités rendues publiques ait été exploitée dans la nature.