Redução da superfície de ataque de firmware (FASR)

Em outubro de 2019, a Microsoft trabalhou em estreita colaboração com os nossos parceiros OEM e Silicon para lançar PCs Secured-core. Esses dispositivos apresentam hardware, firmware e software profundamente integrados para ajudar a garantir segurança aprimorada para os dispositivos, identidade e dados. Um dos principais pilares de segurança dos PCs Secured-core é ajudar a oferecer proteção de firmware para dispositivos. Um recurso fundamental baseado em hardware necessário para satisfazer esse pilar é a Raiz Dinâmica de Confiança para Medição (D-RTM). No entanto, não há muitos dispositivos que oferecem D-RTM hoje devido à dependência do chipset subjacente para suportar essa capacidade, o que impede nosso compromisso de ajudar a elevar e manter uma barra de alta segurança para todos os dispositivos Windows.

Mais pode ser feito para melhorar o nível de segurança de todos os dispositivos Windows, incluindo aqueles sem D-RTM. A Microsoft está trabalhando com parceiros para superar os problemas de compatibilidade que impediam que as proteções de memória fossem aplicadas no firmware UEFI, desenvolvendo um conjunto de aprimoramentos de segurança SMM de código aberto para fornecer flexibilidade adicional para os OEMs usarem.

Para refletir esse compromisso com a segurança do firmware, identificamos uma nova abordagem para garantir que os dispositivos possam atender aos requisitos de proteção de firmware dos PCs Secured-core.

Visão geral do FASR

Para PCs Secured-core que não possuem recursos D-RTM baseados em hardware, devemos definir um pequeno conjunto de componentes de firmware que apresentem uma superfície de ataque reduzida e possam ser atestados no sistema operacional. Essa abordagem é chamada Redução de Superfície de Ataque de Firmware (FASR). Para que o firmware baseado em FASR fosse dimensionado entre PCs de diferentes fornecedores, uma nova abordagem para o processo de inicialização do firmware teve que ser definida.

O FASR suporta dois caminhos de inicialização:

1. Caminho de inicialização certificado:

   • Somente código confiável, assinado e integrado pela Microsoft tem permissão para ser executado.

   • A violação do caminho de inicialização é detetável pelo sistema operacional.

   A figura abaixo ilustra o fluxo de arranque FASR S-RTM no percurso de inicialização certificada. Esse caminho de inicialização ajuda a evitar a execução inesperada do código de firmware da plataforma. No entanto, ele faz uso de alguns dados específicos da plataforma fornecidos pelo caminho de inicialização personalizado. O diagrama a seguir mostra o fluxo de inicialização FASR no percurso de arranque certificado.

   

2. Caminho de inicialização personalizado: Todo o código de firmware da plataforma pode ser executado. As informações críticas de inicialização específicas de um determinado OEM/plataforma são convertidas em dados no caminho de inicialização personalizado e usadas pelo caminho de inicialização certificado para configurar o sistema corretamente nesse caminho de inicialização. O diagrama a seguir mostra o fluxo de inicialização FASR no caminho de inicialização personalizado.

   Fluxo de arranque F A S R no caminho de arranque personalizado

   Um dispositivo FASR habilitado para conformidade com o PC Secured-core assume como padrão o caminho de inicialização certificado, a menos que tenha ocorrido um evento que faça com que a inicialização alterne para o caminho de inicialização personalizado no início do processo de inicialização do firmware. Exemplos de tais eventos incluem uma atualização de firmware, o usuário solicitou uma interface do usuário de firmware ou o usuário optou por desativar o PC Secured-core, o que significa que eles sempre inicializarão no caminho de inicialização personalizado até que ele seja reativado.

   A inicialização personalizada pode ser usada para inicializar qualquer sistema operacional ou software de terceiros, conforme suportado pelo firmware da plataforma em um dispositivo compatível com FASR, mas o Windows não reconhecerá a inicialização no caminho de inicialização personalizado como compatível com PC Secured-core.

Para entender melhor as tecnologias de segurança por trás do FASR, gostaríamos de compartilhar uma rápida visão geral do processo de inicialização do Windows.

Processo de inicialização do Windows

Raiz da confiança

A execução inicial do firmware num PC moderno segue um processo de arranque em que um conjunto inicial de código carrega outro código e o nível de funcionalidade expande-se à medida que o arranque progride. Cada conjunto de código verifica o próximo conjunto de código formando uma cadeia de confiança. Quando o firmware UEFI ganha controle, ele segue o padrão de Inicialização Segura de verificação de assinaturas de software para continuar a cadeia de confiança até o sistema operacional. Em seguida, o carregador de arranque do Windows continua a cadeia de confiança com o Arranque Fidedigno, que verifica todos os outros componentes do sistema operativo no processo de arranque antes de serem carregados.

Em geral, os atacantes procuram obter o controlo o mais cedo possível no processo de arranque antes de as funcionalidades de segurança e os bloqueios que ajudam a proteger o sistema serem ativados. Quando o sistema é retirado da reinicialização, o conjunto inicial de código executado deve ser ancorado na base de confiança. A tecnologia de verificação de hardware que tem a função de executar essa verificação de código inicial é chamada raiz de confiança. Embora os detalhes exatos variem de acordo com o fornecedor do hardware, todas as raízes da confiança normalmente estão enraizadas em hardware imutável ou ROMs no SOC.

Arranque medido

O Secure Boot ancorado numa raiz de confiança ajuda a garantir que a assinatura digital de todo o firmware seja verificada; no entanto, também é desejável ter um registo de exatamente qual firmware foi executado. O Programa de Compatibilidade de Hardware do Windows requer que todos os PCs com Windows 10 e Windows 11 incluam um chip chamado TPM (Trusted Platform Module). O TPM contém locais de memória chamados PCRs (Registros de Configuração de Plataforma). Cada PCR contém o hash de um tipo de código e/ou dados carregados durante a inicialização, tais como o código de firmware no dispositivo de armazenamento não volátil (por exemplo, flash SPI), as ROMs de opção dos dispositivos PCI, ou o boot loader do sistema operativo. O tamanho de um valor que pode ser armazenado em uma PCR é determinado pelo tamanho do resumo do algoritmo de hash suportado. Por exemplo, um PCR SHA-1 pode armazenar 20 bytes enquanto um PCR SHA-2 pode armazenar 32 bytes. Vários PCRs associados ao mesmo algoritmo de hash são chamados de banco. A TCG PC Client TPM Profile Specification define a inclusão de pelo menos um banco de PCR com 24 registros.

Com um TPM presente, cada componente de firmware também pode atualizar ou estender o PCR apropriado à medida que novos códigos e dados são carregados no processo de inicialização. O processo de extensão atualiza o valor de PCR para ser a saída do algoritmo de hash usando o valor de PCR atual concatenado com o novo código ou argumento de dados como entrada. O resultado é que os PCRs podem ser inspecionados após o processo de inicialização para determinar o que foi executado. Isso permite que o software no sistema operacional entenda se o processo de inicialização foi diferente das inicializações anteriores. Em um ambiente sensível à segurança, o sistema operacional pode ser informado do conjunto exato de medições de código esperadas em determinados PCRs para detetar a execução de código de firmware inesperado. Como os primeiros 16 PCRs num banco só podem ser redefinidos ao redefinir o TPM inteiro, eles são confiáveis e o local preferido para armazenar medições importantes no TPM.

Raiz de confiança para medição

Agora que examinámos o papel de uma raiz de confiança e como o Arranque Medido é usado, vamos analisar duas abordagens comuns para estabelecer uma raiz de confiança para relatar uma cadeia de medição ao TPM: estática e dinâmica.

Uma Raiz Estática de Confiança para Medição (S-RTM) estabelece confiança na reinicialização do sistema, exigindo que essa confiança seja mantida durante todo o processo de arranque. Se a confiança for comprometida em qualquer ponto do processo de inicialização, ela será irrecuperável até a redefinição do sistema. O diagrama a seguir ilustra como o S-RTM é usado no caminho de inicialização certificado.

Em contraste, o Dynamic Root of Trust for Measurement (D-RTM) confia apenas em uma pequena parte do código inicial do firmware de inicialização do chipset e em um agente de hardware que é usado para restabelecer a confiança dinamicamente durante a inicialização. O sistema pode inicialmente inicializar em código de firmware não confiável, mas — logo após o lançamento — reverte para um estado confiável, assumindo o controle de todas as CPUs e forçando-as a seguir um caminho bem conhecido e medido. O diagrama a seguir fornece uma visão geral de um fluxo D-RTM tradicional.

Há uma compensação entre S-RTM e D-RTM. O S-RTM não requer recursos especiais de hardware, mas requer software para melhor contabilizar o código executado durante toda a inicialização. O D-RTM requer recursos especiais de hardware, mas permite que o software seja iniciado em um estado confiável dinamicamente durante a vida útil do sistema.

Os PCs Windows Secured-core utilizaram o D-RTM no arranque seguro para proporcionar flexibilidade ao vasto conjunto de fabricantes de sistemas, permitindo-lhes implementar características e experiências únicas no firmware. Ao mesmo tempo, ajudam a garantir que o sistema atinga um estado fiável e medido, adequado para alojar um ambiente seguro de sistema operativo. O evento de lançamento de D-RTM é utilizado para restabelecer a confiança a partir de um ambiente desconhecido, antes de carregar um kernel seguro. O diagrama a seguir mostra o evento de inicialização D-RTM para restabelecer um ambiente de sistema conhecido.

No passado, o S-RTM podia ser implementado em mais dispositivos devido à sua falta de dependência de recursos especiais de hardware para verificar o estado de segurança do sistema, mas o sistema operacional não tinha um método confiável para confirmar que poderia confiar nas medições relatadas em qualquer dispositivo Windows usando S-RTM.

Melhorias de segurança do firmware

Minimizar os componentes de firmware no caminho de inicialização do sistema operacional

Uma maneira de confiar nas medições S-RTM é reduzir os componentes de firmware que podem ser executados a um conjunto mínimo. Se todos os dispositivos que usam S-RTM usassem o mesmo conjunto de componentes de firmware, o sistema operacional só precisaria confiar em um único conjunto de valores de PCR esperados para esses componentes conhecidos e confiáveis. Com essa abordagem baseada em SRTM, pode-se considerar que um dispositivo atendeu ao requisito de proteção de firmware de PCs Secured-core quando o conjunto de firmware de inicialização é verificado para conter apenas software assinado pela Microsoft que pode ser atestado pelo Windows. Para entender melhor como esses componentes de firmware diferem daqueles em uma inicialização normal do PC, vamos examinar o processo de inicialização antes e depois.

Devido à flexibilidade e ao rico conjunto de recursos oferecidos pelo firmware moderno do PC, o código que é executado antes do sistema operacional resulta em uma superfície de ataque aumentada. O diagrama a seguir mostra um exemplo de um fluxo de inicialização S-RTM tradicional.

As principais responsabilidades do firmware durante a inicialização podem ser muito simplificadas para:

• Específico da plataforma: funcionalidade que se aplica apenas ao design de hardware específico da plataforma.

• Não específica da plataforma: funcionalidade que é padrão do setor e comum a outros hardwares.

Um subconjunto relativamente pequeno de firmware moderno é tipicamente específico da plataforma. Grande parte do código de infraestrutura de firmware que executa tarefas comuns, como alocação de memória, envio de drivers de firmware, manipulação de eventos e assim por diante, é o mesmo entre todos (ou a maioria) dos sistemas baseados em UEFI. Os drivers binários de firmware para essas tarefas podem ser reutilizados em PCs. Além disso, as especificações e interfaces de hardware padrão da indústria permitem que drivers de firmware comuns inicializem discos rígidos, controladores USB e outros periféricos. Os drivers binários de firmware para este hardware também podem ser reutilizados em PCs. Em resumo, os PCs podem ser inicializados com um conjunto mínimo de drivers de firmware comuns.

Reduzir o conjunto total de drivers de firmware carregados durante a inicialização pode levar a outras vantagens:

• Tempo de arranque melhorado

• Menor coordenação do fornecedor para atualizações

• Exposição reduzida a erros

• Superfície de ataque reduzida

Verificação do caminho de inicialização FASR e conformidade de núcleo seguro

Para que um sistema FASR atenda aos requisitos de proteção do firmware de PCs com núcleo seguro, deve ser iniciado no caminho de inicialização certificado. O firmware FASR facilita isso fornecendo ao sistema operacional um manifesto assinado pela Microsoft chamado manifesto FASR (medido no TPM) que contém os valores de PCR esperados para a sequência de inicialização do módulo na trajetória certificada. Isso pode ser comparado com a sequência de inicialização real que ocorreu no caminho certificado. Se essas medições corresponderem, considera-se que o sistema atendeu ao requisito de proteção de firmware do programa Secured-core PC. Qualquer desvio da sequência de caminho de arranque certificado esperado leva à realização de medições inesperadas nos Registros de Configuração da Plataforma (PCRs) do TPM, que o sistema operacional deteta.

Além disso, o Windows só liberará segredos protegidos por hipervisor após a validação bem-sucedida do manifesto FASR assinado em relação às medições registradas durante a inicialização atual. Se, num caminho de inicialização certificado ou durante uma atualização de cápsula, o manifesto FASR não estiver presente, a verificação de assinatura falhar ou ocorrer uma incompatibilidade de PCR, os segredos do VSM não serão deslacrados ou migrados.

Como o firmware FASR aborda proteções de memória e SMM

Agora que um único binário assinado pela Microsoft com um conjunto mínimo de funcionalidades foi definido, ele pode incluir as proteções de segurança de firmware fundamentais, mas ausentes, que a Microsoft está trabalhando com parceiros para trazer ao mercado. O caminho de inicialização certificado deve, no mínimo, atender aos seguintes requisitos:

1. O código não lê/grava em NULL/Page 0

2. As seções de código de imagem e dados são separadas

3. As seções de imagem são alinhadas em um limite de página (4 KB)

4. Os dados são alocados apenas em tipos de memória para dados, e o código é alocado apenas em tipos de memória para código.

5. As imagens de código não são carregadas a partir do código distribuído como binários UEFI (apenas os despachantes designados)

6. O código permanece dentro dos limites dos buffers de memória alocados, com páginas de proteção em torno das alocações de página.

7. Pode ser detetado um stack overflow

8. O código não é executado a partir da pilha

9. A característica /NXCOMPAT DLL é definida para habilitar proteções NX

ROMs de opção de terceiros, aplicativos UEFI e drivers UEFI muitas vezes não foram criados ou validados de acordo com esse conjunto de requisitos. Portanto, eles não seriam executados no caminho de inicialização certificado. O caminho de inicialização personalizado pode, opcionalmente, optar por reduzir o nível de proteções necessárias, mas esse caminho de inicialização não é considerado compatível com Secured-core PC pelo sistema operacional.

Modo de Gerenciamento do Sistema (SMM)

SMM é um modo de operação de processador especial na arquitetura x86. Ele apresenta um desafio único para a segurança do sistema, pois o código executado no ambiente SMM é opaco para o sistema operacional e normalmente é executado no nível de privilégio mais alto (às vezes referido como "Ring -2") de qualquer software no processador host. Após a entrada, o SMM configura o seu próprio ambiente ao configurar a tabela de páginas, a tabela de despacho de interrupção (IDT) e outras estruturas do sistema. O SMM representa uma superfície de ataque significativa que pode ser usada por códigos mal-intencionados para comprometer ou contornar as proteções do sistema operacional habilitadas por meio da segurança baseada em virtualização (VBS). Para ajudar a mitigar o perigo representado pelo SMM, a funcionalidade no SMM pode ser conceitualmente dividida na infraestrutura principal do SMM e nos drivers do SMM da seguinte maneira:

• SMM core: Código que é comum a todas as implementações SMM que executam responsabilidades de arquitetura e infraestrutura

• Drivers SMM: código escrito para realizar uma tarefa específica da plataforma no SMM

Alguns momentos-chave do ciclo de vida do SMM são os seguintes:

1. Quando a base (ou núcleo) do SMM é estabelecida – a Carga Inicial do Programa (IPL) do SMM

2. Quando os drivers SMM são carregados – evento de despacho de driver SMM

3. Quando ocorre a entrada no SMM – através de uma Interrupção de Gestão do Sistema (SMI)

A carga inicial do programa (IPL) do SMM

A CPU tem recursos especiais que concedem ao código SMM seu alto privilégio e ajudam a protegê-lo. Por exemplo, um mecanismo é definido para entrar no SMM por meio de eventos de software ou hardware, uma instrução de CPU é usada para retornar do SMM e vários registradores são definidos para controlar o acesso e bloquear a configuração do SMM. Muitos desses registros de controle são configurados pelo código SMM IPL para restringir o acesso à área da memória onde o código SMM e os dados são armazenados (chamado System Management RAM ou SMRAM).

Como a área SMRAM está na memória principal (DRAM), ela não pode ser estabelecida até que a DRAM esteja habilitada durante a inicialização. Os procedimentos de ativação de DRAM variam de acordo com o fornecedor de silício, mas alguns megabytes de código podem ser executados diretamente do cache da CPU LLC (incluindo o código que inicializa o DRAM) antes que a memória principal esteja disponível.

O firmware FASR traz o ponto SMM IPL mais cedo na inicialização do que a maioria dos outros sistemas. Isso reduz a oportunidade que um invasor tem de minar esse processo e assumir o controle do sistema antes que o SMM seja configurado. Para entender melhor esta e outras melhorias feitas no SMM no firmware FASR, precisamos aprender mais sobre o processo de inicialização do firmware.

Inicializações de Plataforma (PI) no firmware UEFI

O firmware moderno do PC é construído em torno de muitas especificações. A especificação UEFI define a interface entre um sistema operacional compatível com UEFI como o Windows e o firmware no dispositivo. Outra especificação chamada Especificação de Inicialização de Plataforma (PI) define a maneira como os drivers de firmware são construídos e detalha o processo de inicialização em si. Em um alto nível, a Especificação UEFI pode ser pensada como uma das padronizações que permite que uma única imagem do Windows funcione com tantos dispositivos diferentes, e a Especificação PI pode ser pensada como uma das padronizações que permite que tantas imagens de firmware de diferentes fornecedores de hardware trabalhem juntas. Ambas as especificações são mantidas pelo Fórum UEFI.

A PI Specification define as fases de inicialização e quais drivers são gravados nas fases de inicialização. Durante a inicialização do firmware, cada fase passa para a próxima e, na maioria dos casos, os drivers da transferência de fase não são mais usados e apenas dados importantes são passados para a próxima fase para que possa continuar o processo de inicialização. As fases de inicialização podem ser resumidas da seguinte forma:

1. SEC – Obtenha controle no vetor de redefinição da CPU e faça a transição da montagem para o código C para carregar o PEI

2. PEI – Inicializar o estado do sistema para carregar DXE e inicializar DRAM

3. DXE – Execute a inicialização restante do sistema, o que inclui fornecer o suporte que o BDS precisa para carregar um sistema operacional

4. BDS – Descubra a opção de inicialização para a inicialização atual (por exemplo, o carregador de inicialização do sistema operacional) e tente inicializar essa opção

5. OS – O kernel do sistema operacional

Protegendo a carga inicial do programa (IPL) do SMM

O firmware tradicional compatível com a especificação UEFI PI carrega o SMM IPL na fase de inicialização DXE. O firmware FASR carrega o SMM IPL na fase de inicialização do PEI. A Base de Computação Confiável (TCB) de um sistema é o conjunto total de mecanismos de proteção que o protegem, incluindo hardware, firmware e software. Ao mover o SMM IPL do DXE para o PEI, toda a fase DXE (que é um ambiente maior e mais rico do que o PEI) é removida do TCB. O diagrama a seguir mostra o IPL do SMM movido para um estágio anterior no processo de inicialização UEFI.

O código PEI e DXE é executado no anel 0 e não persiste (com poucas exceções) no sistema operacional. O código SMM é executado com um privilégio maior do que o anel 0 (e o hipervisor) e persiste no sistema operacional, portanto, não permitir que uma vulnerabilidade DXE afete o estabelecimento do SMM reduz a superfície geral de ataque do sistema. Além disso, como o SMM é iniciado mais cedo no processo de inicialização, os bits de bloqueio definidos para ajudar a proteger o SMM podem ser ativados mais cedo na inicialização, minimizando ainda mais a janela de um invasor para comprometer o SMM.

Protegendo o processo de despacho do driver SMM

Dentro da especificação PI, dois modos SMM são definidos: MM tradicional e MM autônomo. O MM tradicional é equivalente ao modelo de software SMM historicamente usado no firmware compatível com PI, que constitui a maioria dos firmware UEFI na indústria. O MM autônomo é um modo relativamente novo que revisa o modelo histórico para melhorar a segurança do ambiente SMM e evitar erros comuns cometidos em implementações tradicionais de MM que levaram a inúmeros desafios de portabilidade e segurança ao longo dos anos.

O firmware FASR opera exclusivamente no modo MM autônomo. Isso permite que o firmware FASR siga uma abordagem disciplinada para a execução de software no SMM. Tantas vulnerabilidades baseadas em SMM atualmente são devidas a más práticas permitidas no código SMM no MM tradicional, que podem ser simplesmente removidas no MM autónomo. De forma geral, isso acontece porque — no modelo MM tradicional — um driver SMM é despachado duas vezes, uma pelo gestor DXE no ring 0 e outra pelo gestor SMM no SMM. Isso oferece ampla oportunidade para o código do driver executado no ambiente DXE armazenar em cache ponteiros para recursos fora da SMRAM que eles não devem acessar após o retorno do ponto de entrada. Os ataques que dependem do código SMM para chamar código externo ao SMM são frequentemente denominados "ataques de chamada SMM".

Protegendo a entrada no SMM (Sistema de Modo Seguro)

Os dados são passados para um manipulador SMI por meio de uma estrutura chamada "buffer de comunicação". O manipulador SMI é responsável por validar se os dados atendem a determinados requisitos em seu ponto de entrada. A WSMT (Tabela de Mitigação de Segurança do SMM do Windows) é um mecanismo usado para ajudar a mitigar a ameaça que manipuladores SMI não verificados representam para a Segurança baseada em virtualização no sistema operacional. A Microsoft contribuiu com código para o projeto TianoCore para melhorar a validação do buffer de comunicação. Além de aplicar essas duas técnicas, o código FASR também implementa proteções rígidas de acesso à memória, permitindo que o código SMM acesse apenas intervalos de memória explicitamente permitidos.

Supervisor de Modo de Gestão (Supervisor MM)

O código principal do SMM é comum e compartilhado com pouca ou nenhuma alteração entre os sistemas. A superfície de ataque imposta pelo SMM pode ser grandemente reduzida introduzindo a separação de privilégios no ambiente SMM. Por essa razão, o firmware FASR inclui um Supervisor SMM que é executado em MM Standalone. Isso resulta em um ambiente SMM bem definido com um TCB mínimo que tem níveis de privilégio impostos desde a criação. O MM Supervisor coloca restrições em acessos a portas de E/S, acessos a Registro Específico de Modelo (MSR), acesso a MMIO, acesso ao estado de salvamento da CPU e instruções permitidas no ambiente SMM. Uma Política de Supervisor SMM é usada para configurar os detalhes exatos de quais recursos de hardware devem ser restringidos, e esses detalhes exatos estão sujeitos a alterações por geração de silício.

A política passou recentemente para uma abordagem de negação por padrão que reduz significativamente os recursos de hardware disponíveis para código fora do Supervisor SMM. Este supervisor opera sem depender de quaisquer características de hardware que não são comuns em PCs modernos.

O MM Supervisor é usado no FASR é open-source e está disponível no Project Mu MM Supervisor Repository.

Conformidade do sistema FASR com os requisitos de núcleo seguro do PC

A tabela a seguir indica os amplos pilares ou objetivos de segurança dos PCs Secured-core e como os sistemas FASR inicializados no caminho certificado podem atingir os requisitos dos PCs Secured-core:

Se o sistema não tiver recursos avançados de segurança para suportar D-RTM, os requisitos de proteção de firmware podem ser atendidos usando uma combinação de S-RTM e MM autônomo com MM Supervisor, ambos oferecidos pelo firmware FASR.

Resumo

Estes são alguns dos investimentos que a Microsoft fez para lidar com o número crescente de ataques de firmware que prevalecem em toda a indústria atualmente. Ao usar código de código aberto para essas alterações, estamos capacitando nossos parceiros a usar alguns desses benefícios de segurança que, por sua vez, beneficiarão o ecossistema mais amplo e a indústria em geral.

O principal objetivo da iniciativa Secured-core PC é ajudar a garantir que os clientes tenham acesso a alguns dos recursos de segurança mais avançados disponíveis para PCs Windows. Com algumas dessas alterações de firmware, estamos um passo mais perto de alcançar esse objetivo e atualizamos os requisitos de proteção de firmware dos PCs Secured-core para refletir essa inclusão. Saiba mais sobre PCs Secured-core aqui.