Memory Integrity Enforcement da Apple

• A Apple introduziu o Memory Integrity Enforcement (MIE), concluindo um sistema inovador de segurança de memória que combina hardware Apple Silicon com proteções avançadas do sistema operacional
• O MIE protege superfícies de ataque críticas com ativação permanente e é aplicado a todos os dispositivos iPhone 17 e iPhone Air sem perda de desempenho
• Ao combinar o Enhanced Memory Tagging Extension (EMTE), um alocador de memória seguro e uma política de confidencialidade de tags, aumenta de forma significativa a resistência contra ataques maliciosos
• Com verificação síncrona de tags e integração sofisticada entre sistema operacional e hardware, a prevenção de buffer overflows e vulnerabilidades de use-after-free é maximizada
• Por meio de anos de pesquisa agressiva e avaliações internas, a Apple conseguiu restringir a liberdade de ação dos atacantes e alcançar o mais forte nível atual de segurança de memória

---

Introdução

• O Memory Integrity Enforcement (MIE) da Apple é uma tecnologia de proteção de segurança de memória sempre ativa que integra hardware Apple Silicon e segurança avançada do sistema operacional
• Foi desenvolvido com o objetivo de oferecer o primeiro sistema amplo de segurança de memória do setor em diversos dispositivos Apple, sem degradação adicional de desempenho
• A Apple o considera um dos avanços mais importantes da história da segurança de memória em sistemas operacionais para consumidores

Contexto das ameaças de segurança e evolução da segurança de memória

• O motivo de o iPhone não ter casos conhecidos de sucesso em ataques massivos de malware é que, na prática, as únicas ameaças observadas são cadeias de ataque complexas centradas em mercenary spyware
• Esses ataques sofisticados, voltados a poucos alvos e custando milhões de dólares, exploram em comum vulnerabilidades de segurança de memória
• A Apple vem melhorando continuamente a segurança de memória com o desenvolvimento de linguagens seguras como Swift, a introdução de alocadores de memória seguros e grandes mitigadores em todo o sistema
• Ao introduzir o Pointer Authentication Code (PAC) pela primeira vez no mundo com o A12 Bionic, estabeleceu a segurança combinando hardware e software como tendência dominante

Tecnologia de tagging de memória baseada em hardware (MTE/EMTE) e superação de limitações

• O Memory Tagging Extension (MTE), proposto pela Arm, atribui uma tag secreta a cada alocação de memória e permite acesso apenas com a tag correta
• A Apple identificou limitações no design original do MTE, como operação assíncrona, e trabalhou com a Arm para aprimorá-lo no Enhanced Memory Tagging Extension (EMTE)
• O ponto central é que a verificação de tags foi projetada para operar de forma sempre síncrona, oferecendo proteção contínua

Estrutura em camadas do MIE e principais mecanismos de proteção

• O MIE é composto por três elementos: alocadores seguros com consciência de tipo, como kalloc_type, xzone malloc e libpas do WebKit, além de EMTE e a política de Tag Confidentiality Enforcement (proteção da confidencialidade das tags)
• Os alocadores oferecem proteção por página de memória entre diferentes tipos, enquanto o EMTE cobre até vulnerabilidades em pequenas alocações de memória dentro de buckets do mesmo tipo
• Contra ataques comuns de corrupção de memória, como buffer overflow e use-after-free, hardware e sistema operacional detectam e bloqueiam imediatamente o problema usando tagging e retagging

Estratégia de confidencialidade de tags e resposta a ataques de canal lateral

• Para impedir que atacantes visem o armazenamento do alocador e a exposição de tags, foram adotadas proteções fortes como o Secure Page Table Monitor
• Para enfrentar ataques de canal lateral que exploram speculative execution, o Apple Silicon foi projetado para bloquear na origem qualquer impacto da execução especulativa causado por informações de tags
• A vulnerabilidade Spectre V1 também é bloqueada de forma eficiente, interrompendo na maioria dos casos os vínculos práticos necessários para um ataque real

Resposta integrada de software e hardware e aplicação geral

• No projeto dos novos chips A19/A19 Pro, foram adicionados amplos recursos extras de hardware para armazenamento e verificação de tags
• O MIE usa primeiro alocadores seguros para proteger via software as áreas em que isso é possível, enquanto o EMTE é aplicado de forma precisa às regiões que não podem ser defendidas por software
• O plano de implantação também foi refinado para que modelos antigos de iPhone possam receber o máximo possível de melhorias de segurança de memória

Avaliação prática de segurança e análise de efetividade

• A equipe de pesquisa ofensiva da Apple construiu vários cenários de ataque desde o planejamento do MIE entre 2020 e 2025 e repetiu tentativas reais de intrusão até mesmo em protótipos de hardware
• Tanto em cadeias de exploit novas quanto antigas, foi confirmado que, com o MIE, a maior parte das etapas de ataque é bloqueada de forma fundamental
• Mesmo as poucas vulnerabilidades remanescentes não permitem ataques estáveis, reduzindo drasticamente a possibilidade de dano real

Conclusão

• A segurança de nível líder do setor no iPhone limita a própria exposição a ataques em nível de sistema para a grande maioria dos usuários
• O MIE neutraliza as estratégias de ataque mais complexas e caras usadas por mercenary spyware e mantém proteção permanente inclusive para mais de 70 processos importantes em espaço de usuário, além do kernel
• A avaliação mostrou que ele aumenta fortemente o custo e a dificuldade de exploração de vulnerabilidades de corrupção de memória, bloqueando com robustez a principal técnica de ataque dos últimos 25 anos
• O MIE se estabelece como a maior mudança na história da segurança de memória em sistemas operacionais para consumidores no iOS e nos dispositivos Apple

[GN⁺]

Comentários do Hacker News

• As duas abordagens chegaram à mesma conclusão. O Memory Integrity Enforcement (MIE) bloqueia fundamentalmente a maior parte das estratégias de exploit que atacantes poderiam usar. Bugs de corrupção de memória normalmente são intercambiáveis, mas o MIE bloqueou caminhos demais de exploit no nível mais básico, a ponto de não ser possível reconstruir a cadeia nem substituindo por bugs novos. Por mais que tentassem, não conseguiram remontar uma cadeia de bypass. Os poucos efeitos restantes também não eram confiáveis, insuficientes para um atacante explorar com sucesso. Isso é uma notícia muito boa e um ponto importante que pode passar despercebido à primeira vista. Parte da estrutura econômica do spyware mercenário depende de cadeias intercambiáveis, então uma defesa que mira diretamente essa propriedade é especialmente interessante
  • Fico curioso se a estratégia da Apple é um passo rumo à segurança de memória totalmente baseada em capabilities, como o CHERI (veja: Capability Hardware Enhanced RISC Instructions), ou se deve ser vista como um sinal de que a Apple concluiu que isso já é suficiente sem um sistema desse tipo
  • Também queria apresentar a abordagem do Google para segurança de memória em resposta ao caso da Apple. O Google leva segurança de memória a sério desde os primeiros dias de Chrome/Android e também liderou a adoção de ASAN, syzkaller e Hardware MTE. Como fui o responsável por liderar esse tipo de equipe, vivi diretamente vários prós e contras. O que o Google queria fazer era permitir ligar e desligar um nível de verificação como o do ASAN conforme a necessidade. Mantê-lo sempre ativado como mitigação de segurança traz vários problemas além do overhead de memória. Por exemplo, isso acaba causando muitos crashes visíveis para usuários de forma inconsistente entre os dispositivos. Do ponto de vista dos desenvolvedores, isso inevitavelmente gera insatisfação, porque eles acabam tendo de testar direito apenas em cerca de 1 milhão de dispositivos com suporte a MTE. O MTE detecta exploits de segurança, mas também encontra muitos bugs inofensivos. Ainda assim, não está claro se ele é sempre a melhor escolha para mitigação em runtime. O Google Security, o Project Zero e outros fazem muito esforço para lidar com CSVs, mas sinto que a empresa falhou em transformar o MTE em produto (link)
  • Talvez não seja uma boa notícia para a Vigilant Labs, mas não está claro se ela foi realmente muito impactada
• Acho que a afirmação da Apple de que “proteções de segurança de memória precisam estar sempre ativas, de forma síncrona, por padrão e continuamente” veio mais da experiência do que de purismo. Isso foi diferente das proteções iniciais do kernel. O Kernel Patch Protection (KPP), introduzido no iOS 9 em 2015, verificava de forma assíncrona se o kernel havia sido modificado a cada alguns minutos, quando o dispositivo estava ocioso. Essa abordagem não era tão confiável do ponto de vista de segurança e tinha falhas de design, a ponto de já terem sido publicados hacks que a contornavam completamente. O KPP não impedia patches no kernel desde a origem; ele apenas provocava panic quando detectava algo. Em outras palavras, se o atacante concluísse o trabalho rápido o bastante e revertesse tudo, a estrutura permitia que o KPP não detectasse nada (veja o writeup)
  • Com base em informações internas, o KPP foi feito às pressas por volta da introdução do KTRR no A11, <para deliberadamente igualar parte do nível de segurança nos SoCs A11. Foi implementado da melhor forma possível dentro desse cronograma curto e depois esse método não foi repetido
  • Em vez de ter sido algo preparado por princípio desde o início, parece que chegaram a essa conclusão no planejamento inicial para adoção do MTE. O nível de segurança da Apple vem melhorando de forma consistente, e por trás disso há muito aprendizado forçado por jailbreaks e afins
  • Concordo que é difícil implementar esse tipo de sistema perfeitamente logo de primeira
• A Apple disse que “não houve ataques de malware bem-sucedidos e em larga escala contra o iPhone”, mas acho que spyware já existente poderia ser usado imediatamente em um ataque em larga escala com apenas pequenas modificações. Na prática, essa distinção não é tão clara
  • Nem a Apple nem o Google conseguem ter uma visão perfeita da escala real dos ataques. Segundo materiais vazados divulgados pelo GrapheneOS, desenvolvedores de exploits são mais capazes de atacar dispositivos e reagir a updates do que as pessoas imaginam. Há materiais adicionais que não foram divulgados, e parte só é compartilhada para evitar expor a origem do vazamento, a menos que seja verificada por várias fontes independentes. Essas ferramentas de exploit estão amplamente disponíveis, e nem sequer é fácil distinguir extração de dados rotineira de exploração remota. Na prática, exploits raramente são detectados, e na maioria dos casos podem ser usados em grande escala sem detecção, então até uma única cadeia mantém valor por muito tempo. Órgãos de segurança pública do mundo todo já usam ferramentas como o Cellebrite Premium em fronteiras, locais de protesto etc., contra muitas pessoas. Isso já conta como uso em grande escala. No caso de exploits remotos, mesmo que o uso seja amplo, nem é necessário fazer distribuição ampla
  • XcodeGhost é um exemplo representativo de ataque de malware em larga escala no iPhone. Na época, WeChat e outros foram infectados. Material de referência: XcodeGhost na Wikipédia
  • Não está claro se isso realmente poderia ter sido usado em ataques em larga escala, mas se a exposição fosse tão grande quanto no Windows, haveria muitos casos
  • Essa frase talvez tenha sido pensada principalmente para destacar as vantagens do modelo de controle próprio da empresa em comparação com o Android
  • É uma linguagem meio jurídica, mas é positivo para todos nós que a Apple tenha divulgado material muito detalhado e uma mensagem confiante sobre novas tecnologias como este MIE
• Esse sistema é certamente impressionante. Ainda assim, talvez a defesa não seja suficiente se o atacante puder tentar várias vezes. Por exemplo, se for possível acessar além de objetos não adjacentes, ou se depois de muitas manipulações de alocação de memória a tag coincidir por acaso, pode haver bypass. A chance de a tag coincidir é 1/16. No entanto, como o texto principal não entra em detalhes, não tenho certeza se minha previsão está correta. Se isso for aplicado com sucesso, os exploits restantes terão de depender de bugs lógicos, o que tornará as coisas muito mais difíceis para os atacantes
  • No Android MTE também era possível um ataque probabilístico com várias tentativas mirando o problema do tamanho pequeno da tag. Mas a diferença importante aqui é que o ponto central é o enforcement síncrono e consistente. Ou seja, o trap ocorre imediatamente a cada manipulação de escrita em memória, e não na troca de contexto
  • Fora a chance de 1/16, as outras 15/16 tentativas causam crash. Bugs tão instáveis assim tendem a ficar visíveis para o usuário ou para sistemas de diagnóstico, e se for necessário encadear várias etapas com sucesso, a exploração real se torna quase impossível do ponto de vista probabilístico
  • Para ataques estatais de longa duração, como ataques à cadeia de suprimentos, esse tipo de defesa pode não se aplicar
• O modelo da Apple/ARM certamente é muito mais sofisticado, mas isso me lembra a arquitetura de memory tagging dos Burroughs large systems (referência)
• Na explicação “o atacante não deve conseguir prever o valor da tag que o sistema escolhe. Para isso, novas tags são geradas com reseed frequente do PRNG”, o problema fundamental é a baixa entropia da tag (apenas 4 bits). Se o atacante acertar no chute aleatório, a chance de sucesso é 1/16, e o reseed do PRNG não muda essa probabilidade. Parece que faltou explicação adicional
  • O atacante só tem uma única chance de adivinhar. Se errar, o processo é encerrado ou o kernel entra em panic. Na próxima tentativa, a tag será nova, então ele precisará adivinhar de novo, o que impede tentativas consecutivas
  • Com 4 bits, o número de combinações possíveis é pequeno demais. Alocações de memória acontecem aos milhões por segundo, e mesmo com reseed frequente a possibilidade de colisão sobe muito rápido
• O maior ponto forte desta série de dispositivos é justamente esse novo recurso
• Se políticas como o chat control da UE forem implementadas, o Estado poderá acessar tudo o que quiser no meu dispositivo, e se o Google impuser o WEI, a web inteira pode ser bloqueada. Com secure boot e MIE, pode ficar difícil para os usuários reconquistarem as liberdades que tinham antes
  • Em outras palavras, para preservar essa liberdade, talvez seja necessário separar mais os sistemas e serviços, em uma espécie de balkanização
  • Fico curioso se a crítica aqui inclui a ideia de que o fortalecimento do MIE restringe a liberdade do usuário, como no caso de jailbreaks
  • Fico me perguntando o que é WEI
• O fato de o Google ter oferecido MTE como opt-in no ano passado foi um bom primeiro passo, mas faltou integração completa, então isso é diferente do MIE baseado em EMTE que a Apple está destacando. É impressionante ver o iPhone 17 e o Air da Apple trazendo o primeiro sistema abrangente de segurança de memória sempre ativa do setor. Embora seja uma pena que os esforços pioneiros do GrapheneOS (exemplo de release, conscientização) não tenham recebido o devido destaque, espero que a iniciativa séria da Apple se espalhe rapidamente para o Google, o Pixel OS e vários sistemas operacionais focados em segurança. Isso confirma mais uma vez que o GrapheneOS é um líder em sistemas que se defendem até contra ameaças desconhecidas
  • A Apple vem se preparando para isso há muito tempo. Isso não começou a partir do momento em que foi ativado no GrapheneOS
• Há a frase “em 2018, o chip A12 Bionic foi o primeiro do setor a aplicar Pointer Authentication Codes (PAC) para proteger a integridade do fluxo de código”, mas mesmo depois da introdução do PAC houve vários casos de ataques full-chain. O PAC não foi uma medida significativa de dissuasão de ataques. Os atacantes continuam encontrando formas de contorná-lo. Isso precisa ser levado em conta ao avaliar a efetividade real do MIE
  • Na verdade, a Apple não disse que o PAC era uma medida de dissuasão de ataques, e sim que o resultado foi “aumento da complexidade do exploit”. A frase em si é um pouco ambígua, mas, do jeito que leio, parece um reconhecimento de que só o PAC não basta e de que é necessária uma abordagem combinando software e hardware. O PAC em si também é um recurso de hardware que exige mudanças de software, mas o EMTE é uma tecnologia bem mais ampla e que exige muito mais coordenação
  • Não é que o PAC não tenha significado, e sim que ele funciona como um catalisador que obriga os atacantes a necessariamente encontrar um bypass para o PAC. Bypasses de PAC não existem em quantidade infinita
  • O fato de o PAC ter sido contornado várias vezes não significa que seja inútil; isso mostra justamente que ele está funcionando com eficácia