Integridade do sistema operacional
O software dos sistemas operacionais da Apple é projetado tendo a segurança como fator fundamental. Esse design inclui uma raiz de confiança de hardware — usada para permitir uma inicialização segura — e um processo de atualização de software que é rápido e seguro. Os sistemas operacionais da Apple também fazem uso das capacidades de hardware propositadamente construídas com base no silício para ajudar a impedir a exploração enquanto o sistema é executado. Esses recursos do tempo de execução protegem a integridade do código confiável enquanto ele é executado. Resumindo, o software dos sistemas operacionais da Apple ajuda a mitigar técnicas de ataque e exploração, sejam essas oriundas de um app malicioso, da web ou de qualquer outro canal. As proteções na lista a seguir estão disponíveis em dispositivos com SoCs compatíveis projetados pela Apple, incluindo o iOS, iPadOS, tvOS, watchOS e, agora, o macOS em um Mac com Apple Silicon.
Recurso | A10 | A11, S3 | A12, A13, A14 S4–S9 | A15, A16, A17 | M1, M2, M3 |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
Veja a Nota 1 abaixo. | |
|
|
|
Veja a Nota 2 abaixo. |
|
Nota 1: a Camada de Proteção de Página (PPL) requer que a plataforma execute apenas o código assinado e confiado; esse é um modelo de segurança que não se aplica ao macOS.
Nota 2: o Monitor de Tabela de Página Segura (SPTM) é compatível com A15, A16 e A17 e substitui a Camada de Proteção de Página nas plataformas compatíveis.
Proteção da Integridade do Kernel
Depois que o kernel do sistema operacional completa a inicialização, a Proteção da Integridade do Kernel (KIP) é ativada para ajudar a impedir modificações do código do kernel e de drivers. O controlador de memória fornece uma região protegida de memória física que é usada pelo iBoot para carregar o kernel e as extensões do kernel. Após a conclusão da inicialização, o controlador de memória recusa gravações na região da memória física protegida. A Unidade de Gerenciamento de Memória (MMU) do Processador de Aplicativos é configurada para ajudar a impedir o mapeamento de código privilegiado a partir da memória física fora da região de memória protegida e para impedir mapeamentos graváveis da memória física dentro da região de memória do kernel.
Para impedir a reconfiguração, o hardware usado para ativar a KIP é bloqueado após a conclusão do processo de inicialização.
Restrições de Permissões Rápidas
A partir do Apple A11 Bionic e SoCs S3, uma nova primitiva de hardware foi apresentada. Essa primitiva, Restrições de Permissões Rápidas, inclui um registro de CPU que restringe rapidamente as permissões por thread. Com as Restrições de Permissões Rápidas (também chamadas de registros APRR), sistemas operacionais compatíveis podem remover permissões de execução da memória — sem o custo de uma chamada de sistema e uma consulta ou descarte da tabela de páginas. Esses registros fornecem mais um nível de mitigação de ataques da web, particularmente para o código compilado no tempo de execução (compilação dinâmica), já que a memória não pode ser executada eficientemente ao mesmo tempo que está sendo lida ou gravada.
Proteção da Integridade do Coprocessador do Sistema
O firmware do coprocessador lida com muitas tarefas críticas do sistema — por exemplo, com o Secure Enclave, o processador do sensor de imagens e o coprocessador de movimento. Sendo assim, sua segurança é parte essencial da segurança do sistema como um todo. Para impedir modificações ao firmware do coprocessador, a Apple usa um mecanismo chamado Proteção da Integridade do Coprocessador do Sistema (SCIP).
A SCIP funciona de maneira bem semelhante à Proteção da Integridade do Kernel (KIP): no momento da inicialização, o iBoot carrega o firmware de cada coprocessador em uma região de memória protegida, reservada e separada da região da KIP. O iBoot configura a unidade de memória de cada coprocessador para ajudar a impedir:
Mapeamentos executáveis fora da sua parte da região de memória protegida
Mapeamentos graváveis dentro da sua parte da região de memória protegida
Também no momento da inicialização, o sistema operacional do Secure Enclave é usado para configurar a SCIP para o Secure Enclave. Depois que o processo de inicialização é concluído, o hardware usado para ativar a SCIP é bloqueado. Isso é projetado para impedir a reconfiguração.
Códigos de Autenticação de Ponteiros
Códigos de Autenticação de Ponteiros (PACs) são usados para proteger contra a exploração de erros de corrupção de memória. O software do sistema e os apps integrados usam PACs para ajudar a impedir a modificação dos ponteiros de função e endereços de retorno (ponteiros de código). O PAC usa cinco valores secretos de 128 bits para assinar instruções e dados do kernel, e cada processo do espaço do usuário possui suas próprias chaves B. Os itens usam sal e assinaturas conforme indicado a seguir.
Item | Chave | Sal |
|---|---|---|
Endereço de retorno de função | IB | Endereço de armazenamento |
Ponteiros de função | IA | 0 |
Função de chamada de bloco | IA | Endereço de armazenamento |
Cache de métodos de Objective-C | IB | Endereço de armazenamento + Classe + Seletor |
Entradas em tabelas virtuais de C++ | IA | Endereço de armazenamento + hash (nome do método truncado) |
Etiqueta GoTo calculada | IA | Hash (nome da função) |
Estado de threads do kernel | GA | • |
Registradores de estado de threads do usuário | IA | Endereço de armazenamento |
Ponteiros de tabelas virtuais de C++ | DA | 0 |
O valor da assinatura é armazenado nos bits de preenchimento não utilizados no início do ponteiro de 64 bits. A assinatura é verificada antes do uso e o preenchimento é restaurado para ajudar a garantir que o endereço do ponteiro possa ser usado. A falha na verificação resulta em aborto. Essa verificação aumenta a dificuldade de vários ataques, como o de programação orientada a retorno (ROP), o qual procura enganar o dispositivo para que execute um código existente de maneira maliciosa ao manipular endereços de retorno de função armazenados na pilha.
Camada de Proteção de Página
A Camada de Proteção de Página (PPL) no iOS, iPadOS e watchOS é projetada para impedir que o código no espaço do usuário seja modificado após a verificação da assinatura do código ser concluída. Aproveitando a Proteção da Integridade do Kernel e as Restrições de Permissões Rápidas, a PPL gerencia as substituições de permissões da tabela de páginas para garantir que apenas a PPL possa alterar as páginas protegidas que contêm o código do usuário e as tabelas de páginas. O sistema fornece uma enorme redução da superfície de ataque ao oferecer suporte à exigência da integridade do código em todo o sistema, mesmo no caso de um kernel comprometido. Essa proteção não é oferecida no macOS porque a PPL é aplicável apenas a sistemas onde todo o código executado deve ser assinado.
Monitor de Tabela de Página Segura e Monitor de Execução de Confiança
O Monitor de Tabela de Página Segura (SPTM) e o Monitor de Execução de Confiança (TXM) são projetados para trabalhar em conjunto para proteger tabelas de páginas em processos do usuário e do kernel contra modificação, mesmo quando invasores tiverem capacidades de gravação no kernel e puderam contornar as proteções de fluxo de controle. Para fazer isso, o SPTM usa um nível de privilégio mais alto que o kernel e um TXM de menor privilégio para aplicar efetivamente as políticas que regem a execução do código. Esse sistema é projetado para que um comprometimento no TXM não se traduza automaticamente no contorno do SPTM devido a essa separação de privilégios e a relação de confiança entre eles. Em SOCs A15, A16 e A17, o SPTM (juntamente com TXM) substitui a PPL, deixando uma superfície de ataque menor e que não depende da confiança do kernel, mesmo durante a inicialização precoce. O SPTM também depende de novas primitivas de silício que são uma evolução das Restrições de Permissões Rápidas usadas pela PPL.