Inicialização segura na era do omarthrosis de segurança t2 duo

Hoje, continuamos nossa série sobre a nova plataforma T2 da Apple e examinamos o papel que ela desempenha na visão de inicialização segura da Apple. O T2 foi introduzido pela primeira vez com o lançamento do imac pro e agora encontrou seu caminho em todos os novos 2018 macbook pro. Este artigo aborda as propriedades de segurança e detalhes técnicos de implementação do que torna essa plataforma única.

Acreditamos que a plataforma T2 é um passo à frente na segurança da plataforma no ecossistema da Apple, e ela começa a trazer excelentes propriedades de segurança, como recursos de inicialização segura para o mercado de massa. A inicialização segura em novas plataformas da Apple aumenta significativamente o nível de ataque dos invasores. Dito isso, identificamos áreas em que acreditamos que a comunidade e a Apple devem continuar a pesquisar e melhorar.

Devido ao privilégio do T2 e aos casos de uso estendidos além da inicialização segura, temos preocupações sobre o possível aumento da superfície de ataque que isso expõe e acreditamos que mais pesquisas são necessárias para determinar se esses recursos de segurança podem ou não ser prejudicados por essa superfície maior.

Uma das extensões espi mais novas, o flash anexado ao escravo (SAF), substitui o tradicional chip flash SPI contendo firmware por uma interface integrada que o controlador embarcado pode implementar para fornecer o firmware dinamicamente. Normalmente, o SAF é encontrado apenas no servidor skus, mas as linhas imac pro e 2018 macbook pro contêm essa funcionalidade. Isso permite que o T2 realize a validação adicional do firmware em um ambiente de execução confiável antes de fornecê-lo ao chipset para execução.

Como pesquisadores de segurança, ver a Apple alavancar essa funcionalidade levanta várias questões. Primeiro, utilizar o SAF de um EC realmente melhora a segurança da plataforma e torna os bootkits mais difíceis de implantar? Inequivocamente, sim. Mesmo que um invasor tenha conseguido ignorar os mecanismos de proteção contra gravação de firmware oferecidos pela plataforma X86, sem um meio de armazenamento durável, como um chip flash SPI tradicional para o malware, os bootkits não conseguiriam sobreviver a uma reinicialização completa.

Finalmente, o T2 apresenta risco adicional à integridade da plataforma? Pode apostar. O T2 está em uma classe junto com outros processadores habilitados para DMA conectados ao pcie. Embora o código do espaço do usuário no T2 não seja intrinsecamente ou arquitetonicamente capaz de alterar o comportamento do SMM, o mecanismo de gerenciamento de intel (UE), em virtude de ser o código responsável por inicializá-los, o kernel no T2 é intrinsecamente mais poderoso que o SMM / ME / UEFI. Embora seja baseado em uma imensa, mas madura base de código e anos de testes contraditórios, o T2 expõe novas interfaces ao sistema operacional host que tradicionalmente estão fora do alcance dos invasores. A mais proeminente dessas interfaces é a instalação remotexpc exposta por uma interface de rede conectada por USB. Embora o acesso direto à interface seja controlado por direitos, os serviços anunciados podem ser comunicados diretamente sem permissões de root ou direitos binários. O firmware do imac pro sugeriu ao T2, eventualmente, suportar a instalação de aplicativos, mas parece ser um artefato simples do processo de portabilidade da plataforma. As consequências da execução de código privilegiado persistente no T2 são sérias e, além disso, são provavelmente forensicamente impossíveis de detectar. Isso faz do T2 um alvo extremamente atraente para um atacante motivado.

Quando macefiutil -i é invocado por launchd, é feito sem o caminho da imagem opcional, invocando o importado macefihostinterface :: efihostinterface :: init_espi_firmware (char const *) com um argumento nulo. MacEFIHostInterface (apêndice 1) é uma biblioteca compartilhada originalmente localizada em /usr/lib/libmacefihostinterface.Dylib, mas no tempo de execução, ela é incluída no cache do carregador dinâmico (/system/library/caches/com.Apple.Dyld)

O init_espi_firmware consulta a árvore de dispositivos (iodevicetree: / arm-io / espi, com capacidade para segurança) para suporte a flash escravo e, se encontrado, carrega o pacote de firmware UEFI (macefi.Img4) e um arquivo hash sha2-384 (macefi .Hash) do diretório / usr / standalone / firmware / macefi para buffers de memória e invoca macefimanageruserclientlib :: initespi. Essa chamada initespiece no initespi do macefimanageruserclient (apêndice 2), que organiza os dados em um contexto de kernel e chama macefimanager :: loadandverifypayload.

Como parte da rotina de inicialização do macefimanager :: start, a extensão do kernel de atualização do firmware da Apple (AFU.Kext) é inicializada e um retorno de chamada pós-validação é registrado para as seções ‘mefi’. LoadAndVerifyPayload passa um memorydescriptor contendo o conteúdo de macefi.Img4 para applefirmwareupdate :: loadfirmware. Depois de executar a validação de assinatura usando as mesmas rotinas que validam atualizações de firmware, o retorno de chamada pós-validação, macefimanager :: verifypayloadcallback, é executado.

A rotina handlesmcnotification está procurando principalmente dois tipos de eventos específicos provenientes do SMC. KSMCNotifyBootStatus (0xb) é entregue durante a transição para e de estados de energia inferiores, como executar, dormir, dormir profundamente e hibernar. KSMCNotifyPltRstLChange (0x2) é entregue quando o pino virtual PLTRST # é declarado. PLTRST # é uma reinicialização de plataforma baixa ativa semelhante ao botão de redefinição na sua torre de PC. Chegando a S0

Neste ponto, o sistema está quase pronto para iniciar a inicialização. De volta ao userland macefiutil após a chamada init_espi_firmware, allowx86toboot é invocado. Isso eventualmente leva ao macefimanager :: allowx86toboot que localiza a extensão do kernel do gerenciador de estado do sistema (applessm) do apple e define a propriedade “allowcsocboot” como true através da interface applessm :: setproperties.

O gerenciador de estado do sistema é responsável por monitorar os eventos internos de ativação e suspensão e instruir o SMC a colocar o sistema no respectivo estado de energia. A definição allowcsocboot leva a uma chamada para applessm :: smcnotifybootromready e, por sua vez, uma chamada para applessm: sendsystemstatenotifcationtosmc com um argumento de bootromready (0x82). Isso chama uma função de plataforma no serviço applesmc para “system-state-notify” e finalmente terminamos na função applesmc :: callplatform, que transforma esse argumento de notificação bootromready em uma gravação SMC de 0x00008270 na chave “NSEN”.

Quando o botão liga / desliga físico é pressionado pelo usuário, a rotina sleepwakehandler do serviço applessm é chamada devido ao registro para notificação por meio de uma chamada para registersleepwakeinterest ou um retorno de chamada de notificação SMC é recebido. Ambos esses caminhos de código levam a outra chamada para sendsystemstatenotifcationtosmc com um argumento de dos0 (0x89). Isso leva a uma gravação SMC de 0x00008970 na mesma chave “NESN” que desativa a plataforma X86 e permite que o sistema inicialize a imagem UEFI preparada pelo gerenciador e encaminhada pelo mecanismo DMA sobre o espi. A partir deste ponto, o bootloader UEFI e o macos regular são executados como sempre.

Até muito recentemente, a apple tem sido de boca fechada sobre os detalhes da implementação e, dada a falta de instrumentação, os detalhes acima são baseados principalmente na análise estática dos pacotes de atualização do bridgeos. Alguns dos detalhes do fluxo de controle dinâmico podem estar incompletos ou incorretos, mas é o melhor que pode ser feito no momento. Tendo isso em conta, agora que vimos como o T2 inicializa o lado X86 da plataforma, vamos discutir as implicações. Devido à falta de validação de integridade no transporte de espinha físico subjacente, os ataques físicos ainda são possíveis, embora mais desafiadores do que os clássicos ataques de empregada maligna que refletem um único chip flash SPI.

Provavelmente devido ao modo como as regiões de configuração e NVRAM são utilizadas, a imagem do firmware não é recarregada a partir de uma fonte boa conhecida a cada uso e é corrigida automaticamente na primeira inicialização. Isso significa que a imagem do firmware UEFI carregado é persistente nas reinicializações do X86 e é mutável. O que, por sua vez, significa que se um invasor conseguir executar o código do modo kernel no T2, ele poderá modificar o código X86 mais antigo (fase SEC) a ser executado antes de ativar qualquer um dos recursos de integridade da plataforma, assumindo efetivamente o controle do processo de inicialização.

Isso soa como um “se” bem grande, mas aí está o ponto crucial do T2: ele faz demais. O T2 é uma plataforma completa e volumosa. Ele compartilha muitos componentes e drivers comuns das plataformas ios e macos que, francamente, simplesmente não deveriam estar lá. A abordagem de executar a validação de integridade do firmware em repouso é algo óbvio, seguro e algo que nos deixa entusiasmados. Idealmente, as operações de inicialização segura teriam sido isoladas para um sistema-em-um-chip muito mais simples e com um escopo mais definido. Enquanto as atualizações T2 são agrupadas junto com as atualizações do sistema macos, houve problemas no passado em que as atualizações agrupadas foram aplicadas apenas parcialmente, deixando a pilha de software segura, mas o firmware vulnerável.

Com tudo isso em mente, acredita-se que há uma boa chance de que uma vulnerabilidade em um dos dispositivos derivados do XNU, como o iPhone ou o Apple TV, possa afetar todo o ecossistema que agora inclui bridgeos em execução no T2. Embora não seja diretamente acessível no T2, o CVE-2018-4407 destacou recentemente esse impacto potencial, uma vez que afetou vários produtos e arquiteturas diferentes. Isso não quer dizer que não haja benefícios para uma base de código unificada. A cadeia de confiança baseada em mascaramento ROM da Apple, por meio dos esforços dos engenheiros e pesquisadores de segurança da Apple em todo o mundo, amadureceu em um dos alvos mais duros da história. A Apple deve ser elogiada por tentar trazer suas linhas de laptop e desktop para a mesma postura defensiva de suas ofertas móveis.