Malgré les objections de Microsoft, Google lance un jailbreak pour Windows 10 S

Icône de temps de lecture 3 minute. lis


Les lecteurs aident à prendre en charge MSpoweruser. Nous pouvons recevoir une commission si vous achetez via nos liens. Icône d'info-bulle

Lisez notre page de divulgation pour savoir comment vous pouvez aider MSPoweruser à soutenir l'équipe éditoriale En savoir plus

L'équipe Project Zero de Google l'a encore fait, en publiant un exploit "Sévérité moyenne" pour Windows 10 S, ce qui signifie que les utilisateurs pourront exécuter du code arbitraire sur le système d'exploitation verrouillé de Microsoft, Windows 10 S.

La faille est due à la façon dont Windows 10 S vérifie l'identité d'une liste de composants à privilèges élevés, c'est-à-dire très mal.

En détail, Google le décrit ainsi :

La politique de verrouillage de la classe COM WLDP contient une liste codée en dur de 8 à 50 objets COM que les moteurs de script éclairés peuvent instancier. À l'exclusion des problèmes liés à la recherche du bon CLSID (tels que l'abus précédemment signalé du cas TreatAs 40189). Cela ne devrait pas être un problème majeur même si vous pouvez écrire dans le registre pour enregistrer une DLL existante sous l'un des CLSID COM autorisés, car une implémentation COM bien comportée doit comparer le CLSID transmis à DllGetObject avec sa liste interne d'objets connus.

Il s'avère que .NET n'est pas l'une de ces implémentations COM bien comportées. Lorsqu'un objet .NET COM est instancié, le CLSID transmis à DllGetClassObject de mscoree est uniquement utilisé pour rechercher les informations d'enregistrement dans HKCR. À ce stade, au moins sur la base des tests, le CLSID est jeté et l'objet .NET créé. Cela a un impact direct sur la politique de classe car cela permet à un attaquant d'ajouter des clés de registre (y compris à HKCU) qui chargeraient une classe visible COM arbitraire sous l'un des CLSID autorisés. Comme .NET ne se soucie pas de savoir si le type .NET a ce GUID spécifique, vous pouvez l'utiliser pour amorcer l'exécution de code arbitraire en abusant de quelque chose comme DotNetToJScript.

Windows 10 S est le principal système d'exploitation affecté, et en l'absence de code distant, l'exploit signifierait que les pirates auraient besoin d'un accès physique au PC pour exécuter le code initial. Étant donné que Windows 10 S est souvent utilisé dans des situations où l'utilisateur n'est pas digne de confiance (comme les écoles), cela pourrait signifier que les utilisateurs intelligents pourront pirater le système d'exploitation et exécuter du code arbitraire, ce qui pourrait être une étape pour déverrouiller complètement le système opérateur.

Microsoft a été informé de la faille le 19 janvier mais prévoyait de publier le correctif dans le cadre de Redstone 4. C'était cependant bien au-delà de la fenêtre de divulgation de 90 jours de Google, et malgré la demande répétée de Microsoft pour une extension. Google a maintenant publié des informations détaillées sur l'exploit.

Étant donné que Windows 10 S n'est actuellement pas largement déployé, je soupçonne que peu de choses proviendront de ce petit problème, mais il est intéressant que Microsoft n'ait pas anticipé ce problème, ce qui suggère que Microsoft doit travailler plus dur pour auditer ses logiciels et ses méthodes pour les problèmes de mise en œuvre de la sécurité. .

Via Neowin

En savoir plus sur les sujets : google, projet google zéro, microsoft, sécurité, Windows 10 S

Soyez sympa! Laissez un commentaire

Votre adresse email n'apparaitra pas. Les champs obligatoires sont marqués *