- Engenheiros da Calif criaram um exploit de corrupção de memória do kernel do macOS que roda no Apple M5 e entregaram à Apple um relatório de pesquisa sobre a vulnerabilidade
- A cadeia de exploit tem como alvo hardware M5 bare-metal com MIE ativado, e todos os detalhes técnicos completos serão divulgados depois que a Apple corrigir o problema
- O alvo é o macOS 26.4.1 (25E253), e um usuário local sem privilégios chega a um shell root usando apenas chamadas de sistema comuns
- A implementação usou duas vulnerabilidades e várias técnicas, e a Calif entende que este é o primeiro exploit público de kernel do macOS em hardware com MIE
- O Mythos Preview ajudou na identificação dos bugs e no desenvolvimento do exploit, mas contornar novas mitigações como o MIE ainda exige especialistas humanos
Exploit de kernel do macOS que passou pelo MIE do M5
- Engenheiros da Calif, junto com o Mythos Preview, criaram um exploit de corrupção de memória do kernel do macOS que roda em silício Apple M5 e entregaram pessoalmente à Apple, no Apple Park, um relatório de pesquisa sobre a vulnerabilidade
- Essa cadeia tem como alvo hardware M5 bare-metal com MIE(Memory Integrity Enforcement) ativado
- O alvo é o macOS 26.4.1 (25E253), e trata-se de uma cadeia de escalonamento local de privilégios no kernel, apenas de dados, que começa com um usuário local sem privilégios, usa somente chamadas de sistema comuns e termina em um shell root
- A implementação inclui duas vulnerabilidades e várias técnicas, e o relatório de 55 páginas e todos os detalhes técnicos completos serão divulgados depois que a Apple corrigir as vulnerabilidades e o caminho de ataque
- O cronograma avançou rapidamente
- Bruce Dang encontrou o bug em 25 de abril
- Dion Blazakis entrou na Calif em 27 de abril
- Josh Maine criou as ferramentas, e em 1º de maio o exploit funcional foi concluído
O significado do MIE e do Mythos Preview
- Corrupção de memória continua sendo o tipo de vulnerabilidade mais comum, inclusive em iOS e macOS, e, se não for possível bloqueá-la totalmente, são necessárias mitigações que aumentem o custo do ataque
- A Apple colocou muitos recursos de defesa no hardware, considerando desempenho e segurança ao mesmo tempo, e elevou a dificuldade de bypass ao controlar toda a stack
- O MIE é um sistema de segurança de memória com suporte de hardware baseado no MTE (Memory Tagging Extension) da ARM, e foi introduzido como um recurso central de segurança do Apple M5 e do A19
- Segundo a pesquisa da Apple, o MIE interrompe todas as cadeias de exploit públicas contra o iOS moderno, incluindo os kits de exploit Coruna e Darksword vazados recentemente
- A Calif vem explorando como a IA pode contribuir para a construção de exploits que funcionem também em ambientes com MTE, e, com o MIE da Apple focado em iOS também sendo aplicado ao M5 dos MacBooks mais recentes, caminhos de ataque ao macOS se tornaram possíveis
- O Mythos Preview ajudou em toda a identificação de bugs e no desenvolvimento do exploit, e, para tipos de problemas já aprendidos, consegue generalizar até para problemas quase do mesmo tipo
- O motivo de o Mythos ter encontrado rapidamente os bugs é que eles pertenciam a tipos já conhecidos; contornar de forma autônoma uma mitigação nova e de ponta como o MIE ainda continua sendo área de especialistas humanos
- A Calif testou o alcance possível quando modelos de ponta e especialistas são combinados, e essa combinação conseguiu concluir em uma semana um exploit de corrupção de memória do kernel contra proteções de nível máximo
- O MIE não é um mecanismo feito para bloquear hackers completamente, e pode ser evitado se houver vulnerabilidades adequadas
- A série MAD Bugs argumenta que sistemas de IA estão encontrando cada vez mais vulnerabilidades, e que alguns deles podem se tornar fortes o bastante para superar mitigações avançadas como o MIE
- Quando a Apple criou o MIE, não existia um ambiente como o Mythos Preview, e este trabalho é um resultado inicial que mostra a pressão que a descoberta de bugs baseada em IA exerce sobre tecnologias avançadas de mitigação
1 comentários
Comentários do Hacker News
Pelo que dá para ver na demonstração, na plataforma de bug bounty da Apple isso parece uma vulnerabilidade de 100 mil dólares, mas, se for bem empacotada, pode até virar uma vulnerabilidade de 1,5 milhão de dólares
Basta reproduzir na versão beta do macOS, classificar como acesso não autorizado e, se possível, mostrar também no modo bloqueio
Parece que o mundo não está nem um pouco preparado para o impacto dos LLMs em questões de segurança
Se for verdade, é motivo para parabenizar a equipe da Calif, e os detalhes são técnicos demais para eu entender tudo, mas estou esperando um relatório de 55 páginas
Tenho ouvido histórias de desenvolvedores por todo lado empurrando para produção mudanças de código geradas por LLM sem entender direito nem o que estão implantando
À medida que essas mudanças se acumulam, a compreensão da base de código cai e o comportamento fica mais arriscado
O pior é que esse tipo de comportamento está sendo incentivado pela liderança, direta ou indiretamente. Metas de velocidade irreais, promoções baseadas em iniciativas vagas de "uso de IA", sobrecarga nos desenvolvedores que ficaram após demissões e colocar desenvolvedores inexperientes em funções sênior, esse tipo de coisa
Parece que uma parte grande da indústria enlouqueceu e quer reaprender, do jeito difícil, o básico de segurança
Os LLMs vão criar uma enorme quantidade de vulnerabilidades estilo Rube Goldberg nos próximos anos
Isso já começou e, embora este caso não seja disso, está acontecendo de verdade
Como dizer que não existe célula imune a qualquer vírus
Talvez até agora tenhamos sobrevivido com uma espécie de segurança por obscuridade, e essa obscuridade talvez signifique apenas que ninguém tinha tempo nem concentração para realmente analisar o código
Infelizmente faltam alguns detalhes
Estou muito curioso sobre como o bug passou pelo MTE
A Arm publicou, em 2019, a especificação do Memory Tagging Extension (MTE) como uma ferramenta para ajudar o hardware a encontrar bugs de corrupção de memória
O MTE é um sistema de marcação e verificação de memória que atribui um valor secreto como tag a cada alocação de memória
Depois disso, o hardware só permite o acesso quando a requisição de acesso à memória inclui o valor secreto correto
Se o valor secreto não bater, o app trava e o evento é registrado, permitindo que os desenvolvedores identifiquem o bug de corrupção de memória assim que ele acontece
https://support.apple.com/guide/security/operating-system-in...
(https://www.usenix.org/publications/loginonline/data-only-at...)
Como o programa em si não muda de fato, ele não força um comportamento em que o MTE precise intervir, então o MTE não é acionado
Minha outra dúvida é por que a Apple não usou verificação de fbounds aqui
Porque em outros lugares ela tem aplicado isso de forma bem agressiva
Usar MTE junto com verificação abrangente de fbounds poderia tornar o sistema operacional extremamente robusto
Como foi dito "data-only", comandos de GPU talvez se encaixem aqui
No ano passado houve algo parecido no Google Pixel
https://github.blog/security/vulnerability-research/bypassin...
Surpreende que a Apple ainda não use de verdade, internamente, a linguagem supostamente segura Swift
Dá até a impressão de que o Swift 6 foi quase todo marketing
Um dos motivos para o Embedded Swift existir é justamente substituir o firmware do iBoot, atualmente escrito em um dialeto de C com uma ideia parecida com Fil-C, por algo melhor
Ainda assim, não é diferente do kernel Linux
O fato de Rust ter sido permitido não significa que o mundo inteiro foi reescrito, e ninguém em sã consciência tentaria reescrever o kernel com Claude
Recentemente ele foi adicionado ao parser de CSS do Safari, e também roda de forma embarcada em partes do Secure Enclave
Pelo que sei, desde a época da Strangeloop havia discussões sobre colocá-lo no kernel, mas não faço ideia de quanto isso avançou
Separadamente, a Apple vem defendendo fortemente a verificação de fbounds no clang, e isso pode alcançar uma parte pequena, mas importante, do que linguagens memory-safe oferecem
Também gostaria de ver mais adoção de Swift ou de linguagens alternativas, e mais concorrência no espaço de linguagens seguras é sempre bem-vinda
https://docs.swift.org/compiler/documentation/diagnostics/st...
Comprei um M5 de propósito por causa do MIE, e agora estou me sentindo meio idiota
O MTE bloqueia uma grande classe de vulnerabilidades e torna técnicas como ROP e JOP muito difíceis ou praticamente impossíveis agora
O texto foi editado? Quase não há explicação sobre a visita presencial
Isso parece mais um marketing exagerado para o Mythos
O relatório sobre curl foi bem mais comedido
https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...