- O kernel XNU dos sistemas operacionais da Apple tradicionalmente oferecia uma única zona de confiança
- Recentemente, a Apple vem tentando reduzir o impacto de vulnerabilidades de segurança por meio da separação da arquitetura do kernel e da microkernelização
- O Secure Page Table Monitor (SPTM), introduzido em 2023, levou à separação de funções centrais e à formação de uma nova estrutura de domínios de confiança
- Mecanismos de segurança mais recentes, como Exclaves e Trusted Execution Monitor (TXM), foram implementados com base no SPTM
- Essas melhorias estruturais evitam que um comprometimento do kernel reduza imediatamente a confiança em todo o sistema
Visão geral
O kernel XNU, núcleo dos sistemas operacionais da Apple, é chamado de kernel híbrido, mas na prática opera em uma estrutura semelhante à monolítica, com todas as funções do sistema concentradas em uma única zona privilegiada de confiança. Por isso, quando o kernel é comprometido, todo o sistema passa imediatamente a enfrentar uma ameaça grave. Recentemente, a Apple vem aprimorando o kernel para torná-lo mais segmentado e mais próximo de um design de microkernel, por exemplo movendo para fora da área do kernel funções críticas como manipulação de tabelas de páginas e operações relacionadas à criptografia.
Principais motivações da mudança e direção da pesquisa
- Crescente necessidade de melhorar a estrutura do kernel para reforçar a segurança
- Objetivo de minimizar o impacto sistêmico da exploração de vulnerabilidades do kernel
- Falta de pesquisas anteriores que analisem cientificamente como novos mecanismos como o SPTM foram de fato projetados e como funcionam
- Este artigo investiga de forma sistemática esses novos recursos não divulgados em detalhe e organiza as interações e os efeitos de todos os mecanismos de segurança atuais
Mecanismo central do SPTM (Secure Page Table Monitor)
- O SPTM é o componente de mais alto privilégio do sistema, operando no Guarded Level 2 (nível máximo de privilégio) em conjunto com o Guarded Execution Feature (GXF)
- O GXF adiciona níveis horizontais de proteção à estrutura tradicional de exception levels do AArch64, isolando atividades sensíveis do sistema do acesso direto pelo XNU
- O SPTM fornece um domínio de confiança com base em regras de retyping de frames e mapeamento de memória, separando áreas por função
- Exemplos representativos desses domínios de confiança incluem o TXM (responsável por assinatura de código e verificação de permissões) e os Exclaves (recurso moderno de segurança com separação de áreas)
Exclaves e mecanismos de comunicação
- Exclaves são ambientes de execução que operam em zonas independentes de confiança e dependem do sistema de proteção e controle de memória baseado no SPTM
- A comunicação entre Exclaves e o sistema é implementada de várias formas, como xnuproxy (manipulador de requisições seguras) e o framework de IPC Tightbeam
- O Tightbeam tem uma estrutura complexa de IPC, com criação de endpoints, buffers de mensagens e conexões cliente-servidor
- Como caso real de uso de Exclaves, a análise também inclui o controle de indicadores de privacidade, como os avisos de gravação e uso de áudio
Reforço de segurança e perspectivas futuras
- À medida que funções centrais do sistema são separadas do acesso direto pelo XNU, surge uma camada extra de proteção capaz de preservar o nível geral de confiança do sistema mesmo quando o kernel é comprometido
- A análise detalhada das interações entre SPTM, Exclaves e TXM mostra a formação de um sistema de proteção em camadas muito mais forte do que antes
- Na conclusão, o artigo apresenta brevemente o estado atual após a introdução do SPTM, as possibilidades futuras de reforço de segurança, limitações remanescentes e direções para pesquisas posteriores
Estrutura e guia de conteúdo aprofundado
Capítulo 1: motivação–objetivos–estrutura
- Contexto histórico do movimento de segmentação do kernel da Apple e necessidade da pesquisa
- Ênfase nas contribuições deste estudo
Capítulo 2: contexto e fundamentos
- Introdução aos exception levels da arquitetura AArch64, aos métodos de acesso à memória e às técnicas especiais de proteção dos chips da Apple (Fast Permission Restrictions, Page Protection Layer, Guarded Execution Feature, Shadow Permission Remap Register)
- Resumo das pesquisas de segurança anteriores e de suas limitações
Capítulo 3: ambiente de análise
- Explicação do hardware, firmware, ferramentas, símbolos e registradores proprietários da Apple usados como alvo
Capítulo 4: visão geral do projeto da arquitetura completa
- Visualização da estrutura total do sistema abrangendo EL (exception levels) e GL (níveis horizontais de proteção)
Capítulo 5: estrutura aprofundada do SPTM
- Explicação detalhada da configuração básica e inicialização do SPTM, modos de chamada (kernel, TXM e Secure Kernel) e tabelas de cabeçalho/dispatch
- Fluxo de tratamento de eventos internos do SPTM, GENTER e processamento de SVC/HVC (hypercalls de gerenciamento)
- Lógica de retyping de frames: descrição em etapas de chamada e validação, checagens de validade por tipo/domínio, atualização de SPRR (Permission Remapping) e finalização da chamada
- Processo de mapeamento de páginas e mecanismos de segurança
Capítulo 6: papel do Secure Kernel
- Fundamentos da operação segura, incluindo chamadas entre Secure Kernel e SPTM e tratamento de SVC
Capítulo 7: sistema Exclaves
- Principais componentes, como Exclaves, Exclavecore e ExclaveKit
- Gerenciamento de memória e recursos do Exclave, agrupamento por domínio, máquina de estados de conclaves (subáreas) e interação com o espaço de usuário
- Formas de comunicação, como criação e escalonamento de endpoints, portas Mach, IPC em estilo seL4, xnuproxy e Tightbeam, além de exemplos reais de uso (por exemplo, indicador de privacidade)
Capítulo 8: TXM (Trusted Execution Monitor)
- Forma de integração do TXM com o SPTM, estrutura operacional de dispatch, retyping e áreas protegidas
- Explicação das responsabilidades de segurança do TXM e de como ele trata chamadas
Capítulos 9~10: discussão geral e conclusão
- Implicações de segurança da introdução de SPTM e Exclaves, limitações atuais e direções futuras
- Encerramento do estudo e apêndice com materiais de referência e explicação de termos
Explicação dos principais termos
- XNU: kernel central dos sistemas operacionais da Apple, sigla para
X is Not Unix - SPTM: módulo central que concede domínios de confiança por meio de proteção e segmentação de memória
- TXM: supervisor de segurança responsável por tarefas sensíveis como verificação de assinatura de código
- Exclaves: ambiente seguro e confiável executado de forma isolada em áreas físicas e lógicas separadas
- Tightbeam IPC: framework que oferece comunicação segura entre Exclaves e o sistema
- GXF/GL: níveis de exceção de proteção no AArch64 e funcionalidade adicional de controle horizontal de zonas de confiança baseada em Guarded Level
Conclusão
A arquitetura de segurança do iOS moderno está evoluindo para maximizar a separação de confiança e a divisão de responsabilidades, com foco em SPTM, TXM e Exclaves. Esse sistema de proteção em camadas reduz de forma significativa o risco de comprometimento das camadas inferiores do kernel e fornece uma base técnica robusta para responder a futuras ameaças de segurança.
1 comentários
Opinião do Hacker News
Acho que a equipe do SEAR e da Apple está fazendo um trabalho realmente excelente em segurança no iOS, e queria deixar um grande elogio por isso
É admirável o esforço de incorporar recursos de segurança desde o nível de hardware até toda a pilha, além de analisar exploits ITW (ataques no mundo real) e continuar pesquisando formas de bloqueá-los
Por exemplo, eles introduzem recursos como o PPL, mas se concluem que não é perfeito, abandonam sem hesitar e partem para novas técnicas
A Apple tem uma estrutura de integração vertical, então esse tipo de coisa é muito mais fácil do que no Android. No Android, é preciso pedir colaboração aos fabricantes de hardware (QC, Mediatek) e passar por várias etapas, como o kernel Linux, o AOSP e o upstream do LLVM
Pointer Authentication Codes (PAC) também é um bom exemplo. A Apple adotou a postura de “vamos fazer isso”, manteve seu próprio branch do LLVM para implementar a tecnologia e, na prática, mitigou ataques baseados em ITW para resolver o problema
Eu compro produtos da Apple não apenas porque segurança e privacidade são excelentes, mas porque a Apple toca isso com paixão e sinceridade, mesmo não sendo algo que ela seja obrigada a fazer para ganhar dinheiro
Na prática, vai além de marketing: eles recrutaram para a equipe de segurança alguns dos melhores hackers da comunidade de jailbreak, e trouxeram inovações como Private Relay, e-mail privado, trusted compute e multi-party inference
Claro, também há problemas evidentes na postura hipócrita da Apple. Por exemplo, permitir VPNs (exceto para tráfego que vai para servidores da Apple), padrões de privacidade por padrão (exceto chamadas por Wi‑Fi ou “journaling suggestions”) deixam a desejar
Na prática, existe a condição de que não há segurança contra a própria Apple e alguns parceiros de telecomunicações, mas ainda assim o Google me passa muito mais a sensação de “seguro para todos, exceto para o Google e para os compradores de anúncios do Google”, então acho que a Apple está bem à frente
Mesmo após um enorme esforço de engenharia, o iMessage ainda mantém caminhos pelos quais código suspeito pode ser executado no kernel, e por isso os exploits 0-click continuam existindo
Outra vantagem desse esforço é que, se um caminho de código roda ao menos uma vez em um novo processador com segurança reforçada pela Apple, a segurança de todas as plataformas acaba melhorando naturalmente
Em teoria, problemas difíceis de detectar apenas com análise estática podem ser identificados com mais facilidade, e dá para obter insights mais profundos além de simples crashes
O Google, na verdade, já poderia ter adicionado MTE há alguns anos, mas não queria impor isso aos OEMs como parte da certificação do Android
É basicamente a mesma história que se repete com as atualizações do sistema operacional
Hoje, a Apple se preocupa com segurança não apenas para proteger os usuários
No fundo, o objetivo é dificultar que os usuários executem software não autorizado por conta própria ou façam jailbreak, para manter o monopólio da App Store
No fim, ela prioriza os interesses da empresa, não os dos usuários
Sempre que leio sobre a segurança do iOS, fico surpreso com a complexidade
Há muitas camadas: nível de hardware, nível de kernel, várias técnicas de sandboxing etc.
Fico me perguntando se essa estrutura é um “puxadinho” construído sobre um projeto que assumia confiança no passado
Se fosse redesenhado do zero, seria possível torná-lo mais simples, e se existe algum sistema operacional realmente projetado assim
Vulnerabilidades são inevitáveis quanto mais casos de uso uma plataforma precisa suportar
A forma de lidar com isso é justamente a defesa em profundidade (defence-in-depth)
O iOS é baseado no macOS, o macOS vem do NeXT, e a raiz disso é o Unix
Ele foi projetado desde o início tendo em mente baixa confiança no usuário
O grau de confiança no usuário mudou com o tempo, e mais recentemente tudo ficou ainda mais complexo com recursos de rede sempre conectados e novas ameaças após o Spectre
Sobre a pergunta se isso é um remendo sobre decisões históricas de design, eu diria que sim
É o resultado de esforços para compensar as limitações do modelo de segurança do Unix e da programação de sistemas em C
Se fosse possível redesenhar tudo do zero, talvez uma capability architecture pudesse reduzir a complexidade, mas por causa dos problemas de compatibilidade com POSIX, na prática isso existe mais no meio acadêmico ou como hobby
Se você adotar um modelo totalmente novo, acaba tendo de abandonar imediatamente a maior parte dos programas Unix existentes, então a adoção prática é extremamente difícil
O seL4 é uma arquitetura de microkernel rápida, muito segura e formalmente verificada
É excelente em controle de acesso de alto nível, suporte a máquinas virtuais e outros aspectos
Texto explicando a arquitetura do microkernel seL4
Mas como falta “todo o resto”, eu o vejo mais como algo voltado à pesquisa do que como um sistema operacional real
Acho que talvez dê para tentar os dois
Até a “segurança de hardware” tem seus próprios pressupostos de confiança, mas no fim continua sendo apenas software hardcoded, então quanto maior a complexidade, maior também a chance de bugs
Nesta keynote do Ivan Krstić na Hexacon, a Apple anunciou que vai reforçar o programa de bug bounty
Blog oficial relacionado
Fico curioso se o problema de conexões em texto puro (não criptografadas) durante atualizações regulares ou execução de apps já foi resolvido
Material de referência relacionado