Lembram daquelas ocasiões em que falamos sobre Secure Boot? Bem, de algum modo Redmond deixou escapar certas “chaves douradas”, que na verdade simbolizam uma política especial equivalente a um “modo de desenvolvimento”, e que por sua vez desativa várias das funções principais do Secure Boot. A melhor parte? A Microsoft pensou que isso não era um problema no início, mas lançou dois patches em menos de um mês. O gênio escapou da lâmpada?
Privacidade, segurança, código proprietário, open source, jailbreaking, rooting… termos que vão, vêm, se chocam, compartilham um caminho similar ou se despedaçam entre si. O usuário médio fica preso em uma tempestade sem saber o que é mais conveniente, e os argumentos de todas as partes envolvidas se tornam ruído branco. A última novidade que acaba de se colocar acima desse ruído envolve o Secure Boot, velho conhecido aqui no NeoTeo, teórico protetor da integridade do computador e de seu sistema operacional (neste caso específico, várias versões do Windows), e inimigo mortal de muitos cavaleiros do Linux que quiseram fazer um “dual-boot” em seus novos dispositivos e não conseguiram. A Microsoft indicou (em mais de uma ocasião) que os sistemas certificados baseados em x86 devem permitir que o Secure Boot entre em um “modo personalizado” ou dar a opção de desativá-lo por completo, embora isso não se estende a dispositivos ARM, uma das razões pelas quais todos aqueles tablets com Windows RT são hoje pouco mais que tijolos. No entanto, o estado geral do Secure Boot pode mudar completamente dentro de alguns meses.
O que aconteceu exatamente?
Dois especialistas em segurança identificados pelos pseudônimos MY123 e Slipstream descobriram algo que batizaram de “chaves douradas”, que não são chaves digitais no sentido tradicional, mas uma política especial de Secure Boot que modifica as tarefas executadas pela UEFI na inicialização… entre as quais está a verificação de assinaturas. Ao que parece, essa política existe como um “modo de desenvolvimento” ou “modo debug”, se preferirem, que habilita os programadores a avaliar novos builds, detectar bugs e aplicar as correções necessárias sem precisar assinar tudo. Como chegou às mãos de MY123 e Slipstream? Basicamente, eles a encontraram no final de março “adormecida” em dispositivos que a Microsoft oferece à venda. Eles entraram em contato com a empresa em abril, e naquela época a Microsoft considerou que não era um risco de segurança (requer acesso físico “ou” privilégios de administrador), mas entre junho e julho decidiram pagar uma recompensa e lançar dois patches, MS16-094 e MS16-100, que embora consigam mitigar a situação, não apresentam uma solução definitiva.
O que isso significa?
Em que isso vai se transformar? A resposta é “depende”. A política poderia permitir a instalação de sistemas operacionais alternativos em dispositivos com Windows RT (sem os hotfixes mencionados) ou Windows Phone. Pessoalmente, gostaria de ver o que a comunidade pode fazer (não será nada fácil, embora existam gênios por aí que vivem procurando desafios desse tipo), mas a moeda tem dois lados. Não é lógico criar uma lista negra com cada “bootmgr” afetado porque isso quebraria a compatibilidade em mais de um caso (discos originais de instalação, partições de recuperação, backups, etc.), e se alguém aproveitar essa brecha para instalar um “pacote” malicioso, bem...
(N. da R.: Sim, a página oficial parece um cracktro dos anos 90)
