2e round : expiration de l’échéance fixée par Google sur deux vulnérabilités Microsoft

Deux nouvelles vulnérabilités Windows non corrigées sont entrées dans le domaine public à l’échéance de la période de 90 jours avant publication définie par Google Project Zero.

Microsoft va offrir une solution pour une des ces vulnérabilités dans les correctifs qui seront publiés le premier mardi de février. Quand à la deuxième, les deux parties s’accordent pour dire qu’elle ne constitue pas un problème de sécurité.

Cet accord est bien la seule concession entre les deux géants technologiques d’aujourd’hui. Lorsque Google a publié le 29 décembre les informations sur la vulnérabilité d’augmentation des privilèges, elle a non seulement engendré un débat sur le sujet par les experts en sécurité amateurs, mais elle a également provoqué des échanges vifs entre les deux sociétés.

Microsoft publia un communiqué sur sa philosophie en matière de divulgation concertée des vulnérabilités et indiqua en passant qu’elle avait demandé à Google d’attendre les mises à jour de janvier, diffusées cette semaine, avant de dévoiler la vulnérabilité. Google refusa et publia ses données.

"Bien que Google a respecté les délais annoncés, la décision prise repose non pas tant sur des principes que sur la volonté de mettre nos lacunes en évidence, ce qui aurait pu nuire à nos clients. Ce qui est bon pour Google ne l’est pas toujours pour les clients. Nous invitons Google à faire de la protection des clients notre principale tâche collective" a déclaré Chris Betz de Microsoft.

Le jeudi est une autre échéance de divulgation pour Project Zero ; le bogue le plus récent de Windows se situe au niveau de la vérification de l’emprunt d’identité à l’aide de la fonction CryptProtectMemory. Google a indiqué que sa mise en œuvre dans CNG.sys ne vérifie pas le niveau d’emprunt d’identité du token lors de l’interception de l’ID du login de la session.

"L’utilisateur lambda peut imiter un autre au niveau de l’identification et chiffrer ou déchiffrer les données pour cette session" a expliqué James Forshaw, pour Google, dans son blog. Il poursuit en indiquant que cela peut "poser un problème s’il existe un service vulnérable à une attaque d’implantation de canal nommé ou conservant les données chiffrées dans une section de mémoire commune lisible par tous"

La description contient également un code d’exploitation de preuve de concept qui utilise cette vulnérabilité. Google a signalé la vulnérabilité à Microsoft le 17 octobre. D’après les remarques associées au communiqué, Microsoft a confirmé lundi qu’elle avait réussi à reproduire le problème et contourner le système de sécurité. Une autre remarque, du mardi, indique que Microsoft avait l’intention de diffuser le correctif pour cette vulnérabilité au cours de cette semaine, mais que des problèmes de compatibilité avaient entraîné un report jusqu’au mois de février. Jeudi était la date butoir établie par Google.

Un représentant de Microsoft a déclaré à Threatpost : "Nous ne sommes au courant d’aucune cyberattaque qui aurait utilisé ces deux vulnérabilités. Nous travaillons actuellement sur la résolution du premier problème, à savoir le contournement de CryptProtectMemory. Les clients doivent comprendre que pour réussir à exploiter cette vulnérabilité, un individu malintentionné potentiel doit utiliser une autre vulnérabilité".

Le deuxième problème porte sur le contournement de la vérification des autorisations d’administration dans l’appel système NtPowerInformation. La vérification a lieu avant l’exécution de fonctions spécifiques en rapport avec l’économie d’énergie.

Comme l’a écrit James Forshaw : "Il est possible de déjouer cette vérification dans Windows 7 car la fonction SeTokenIsAdmin ne prend pas en compte le niveau d’emprunt d’identité du token et le reste du code ne vérifie pas non plus le compte utilisateur. Vous pouvez donc ainsi imiter le token d’administrateur tout en étant un utilisateur normal (via un token lié ou via l’interception d’un token système) et appeler des fonctions protégées. Dans Windows 8+, la méthode SeTokenIsAdmin a été modifiée de façon à vérifier le niveau d’emprunt d’identité et elle n’est plus vulnérable."

Google a indiqué que Microsoft avait informé ses chercheurs sur le fait que le problème avait été reproduit sous Windows 7 et qu’il n’avait pas atteint le seuil requis pour lui attribuer le niveau "intervention requise" ; le bogue permet seulement d’obtenir des informations restreintes sur la configuration de l’alimentation. Google a reconnu qu’il ne s’agissait pas d’un problème de sécurité critique et a publié les détails ainsi qu’une confirmation du concept.

Source :        Threatpost

Posts similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *