Apesar das objeções da Microsoft, o Google lança um jailbreak para o Windows 10 S

Ícone de tempo de leitura 3 minutos. ler


Os leitores ajudam a oferecer suporte ao MSpoweruser. Podemos receber uma comissão se você comprar através de nossos links. Ícone de dica de ferramenta

Leia nossa página de divulgação para descobrir como você pode ajudar o MSPoweruser a sustentar a equipe editorial Saiba mais

A equipe do Project Zero do Google fez isso novamente, lançando uma exploração de “Gravidade Média” para o Windows 10 S, o que significa que os usuários poderão executar código arbitrário no sistema operacional bloqueado da Microsoft, o Windows 10 S.

A falha se deve à forma como o Windows 10 S verifica a identidade de uma lista de componentes de alto privilégio, ou seja, muito mal.

Em detalhes, o Google o descreve assim:

A política de bloqueio WLDP COM Class contém uma lista codificada de 8 a 50 objetos COM que os mecanismos de script iluminados podem instanciar. Excluindo problemas relacionados à procura do CLSID correto (como abuso relatado anteriormente do caso TreatAs 40189). Isso não deve ser um problema importante, mesmo que você possa gravar no registro para registrar uma DLL existente em um dos CLSIDs COM permitidos, pois uma implementação COM bem comportada deve comparar o CLSID passado para DllGetObject com sua lista interna de objetos conhecidos.

Acontece que o .NET não é uma dessas implementações COM bem comportadas. Quando um objeto .NET COM é instanciado, o CLSID passado para o DllGetClassObject do mscoree é usado apenas para pesquisar as informações de registro no HKCR. Nesse ponto, pelo menos com base em testes, o CLSID é descartado e o objeto .NET é criado. Isso tem um impacto direto na política de classe, pois permite que um invasor adicione chaves de registro (inclusive para HKCU) que carregariam uma classe visível COM arbitrária em um dos CLSIDs permitidos. Como o .NET não se importa se o tipo .NET tem esse GUID específico, você pode usar isso para inicializar a execução de código arbitrário abusando de algo como DotNetToJScript.

O Windows 10 S é o principal sistema operacional afetado e, na ausência de um código remoto, a exploração significaria que os hackers precisariam de acesso físico ao PC para executar o código inicial. Dado que o Windows 10 S é frequentemente usado em situações em que o usuário não é confiável (como escolas), no entanto, isso pode significar que usuários inteligentes poderão invadir o sistema operacional e executar código arbitrário, o que pode ser um passo para desbloquear totalmente o sistema operacional.

A Microsoft foi notificada da falha em 19 de janeiro, mas planejava lançar a correção como parte do Redstone 4. No entanto, isso estava muito além da janela de divulgação de 90 dias do Google, e apesar do pedido repetido da Microsoft por uma extensão O Google divulgou agora informações detalhadas sobre o exploit.

Dado que o Windows 10 S não está amplamente implantado, suspeito que não venha muito dessa pequena disputa, mas é interessante que a Microsoft não tenha antecipado esse problema, o que sugere que a Microsoft precisa trabalhar mais na auditoria de seu software e métodos para problemas de implementação de segurança .

Através da Neowin

Mais sobre os tópicos: google, projeto zero do google, microsoft, segurança, Janelas 10 S

Deixe um comentário

O seu endereço de e-mail não será publicado. Os campos obrigatórios são marcados com *