Google a révélé publiquement une autre faille de sécurité dans un produit Microsoft après que l’éditeur de Windows n’a pas réussi à la colmater dans le temps imparti (soit 90 jours).Cette fois, l’équipe du Project Zero a découvert une faille de sécurité dans Microsoft Edge. Selon le chercheur en sécurité de Google, Ivan Fratric, il est possible de contourner Arbitrary Code Guard pour compromettre un hôte Windows 10.
Pour rappel, Arbitrary Code Guard (ACG) a été implémenté par Microsoft dans Windows 10 version 1703 (Creators Update) et bloque les exploits JavaScript qui tentent de charger du code natif malveillant en mémoire.
À ce propos, Matt Miller, Principal Security Software Engineer chez Microsoft, a expliqué que « La plupart des exploits de navigateurs modernes tentent de transformer une vulnérabilité de sécurité de la mémoire en une méthode d'exécution de code natif arbitraire sur un périphérique cible. Cette technique est répandue, car elle fournit le chemin de moindre résistance pour les attaquants en leur permettant de mettre en scène de manière flexible et uniforme chaque phase de leur attaque. Pour les défenseurs, la prévention de l'exécution de code natif arbitraire est souhaitable, car elle peut limiter considérablement la plage de liberté d'un attaquant sans nécessiter une connaissance préalable d'une vulnérabilité. À cette fin, Microsoft Edge dans la Creators Update de Windows 10 exploite Code Integrity Guard (CIG) et Arbitrary Code Guard (ACG) pour aider à casser la primitive la plus universelle trouvée dans les exploits de navigateur Web modernes : le chargement de code malveillant en mémoire. »
Toutefois, selon Fratric, les attaquants sont en mesure de charger du code natif malveillant en mémoire avec des sites Web malveillants, donc techniquement les utilisateurs sont exposés une fois que leur navigateur est dirigé vers ces pages compromises.
Le problème vient des compilateurs Just-in-Time (JIT) utilisés dans les navigateurs Web modernes. Ces compilateurs JIT transforment le JavaScript en code natif, parfois non signé et l'exécutent dans un processus de contenu.
Fratric indique que « Si un processus de contenu est compromis et que le processus de contenu peut prédire sur quelle adresse le processus JIT appellera VirtualAllocEx () (remarque : il est assez prévisible), le processus de contenu peut :
- « Dissociez la mémoire partagée mappée ci-dessus en utilisant UnmapViewOfFile () ;
- « Allouer une région de mémoire inscriptible sur la même adresse, le serveur JIT va écrire une charge utile qui sera bientôt exécutable ;
- « Lorsque le processus JIT appelle VirtualAllocEx (), même si la mémoire est déjà allouée, l'appel va réussir et la protection de la mémoire sera définie sur PAGE_EXECUTE_READ. »
Aussi, pour s’assurer que les compilateurs JIT fonctionnent avec ACG activé, Microsoft a mis la compilation JIT d'Edge dans un processus séparé qui s'exécute dans sa propre sandbox isolée.
C’est d’ailleurs ce qu’explique Miller lorsqu’il déclare :
« Les navigateurs web modernes réalisent de grandes performances en transformant JavaScript et d'autres langages de haut niveau en code natif. Par conséquent, ils s'appuient intrinsèquement sur la possibilité de générer une certaine quantité de code natif non signé dans un processus de contenu. Permettre aux compilateurs JIT de fonctionner avec ACG activé est une tâche d'ingénierie non triviale, mais c'est un investissement que nous avons fait pour Microsoft Edge dans Windows 10 Creators Update. Pour soutenir cela, nous avons déplacé la fonctionnalité JIT de Chakra dans un processus séparé qui s'exécute dans son propre sandbox isolé. Le processus JIT est chargé de compiler JavaScript en code natif et de le mapper dans le processus de contenu demandeur. De cette manière, le processus de contenu lui-même n'est jamais autorisé à mapper ou modifier directement ses propres pages de code JIT. »
Fratric explique que Microsoft a été notifié en novembre. Microsoft, qui semblait vouloir résoudre le problème à cette échéance (c’est-à-dire lors du patch tuesday de février), s’est ravisé après avoir estimé que le problème est « plus complexe » : « La solution est plus complexe que prévu initialement, et il est très probable que nous ne serons pas en mesure de respecter la date limite de publication de février en raison de ces problèmes de gestion de la mémoire. L'équipe est convaincue que le correctif ne sera prêt à être livré que le 13 mars, mais cela va au-delà du SLA de 90 jours et de la période de grâce de 14 jours pour s'aligner sur Update Tuesdays », a affirmé Microsoft.
En clair, l’éditeur vise cette fois-ci le patch tuesday de mars pour diffuser un correctif.
Source : blogs Microsoft, blog Chromium