- tachy0n é um caso de divulgação de um exploit de jailbreak 0day recente para iOS 13.0~13.5
- Esse bug é uma condição de corrida (race condition) na syscall
lio_listio, chamada de Lightspeed, explorando uma vulnerabilidade de LPE (elevação de privilégio) no kernel
- Há casos em que essa vulnerabilidade foi realmente usada em vários projetos de jailbreak, como Spice e unc0ver, e o texto explica o método de exploração da falha e técnicas de hacking relacionadas a problemas de gerenciamento de memória
- Depois que esse exploit foi divulgado, a Apple introduziu patches e testes de regressão, além de fortalecer bastante recursos como isolamento mais robusto de objetos do kernel (Zone, kheap etc.) e proteção de ponteiros
- A partir do iOS 14, o ambiente de jailbreak e de exploits de kernel mudou de forma fundamental, e já não existem mais exploits públicos de kernel
0. Introdução
- tachy0n é um exploit antigo que se aplica do iOS 13.0 ao 13.5
- Foi divulgado como 0day em 23 de maio de 2020 no unc0ver v5.0.0, e a Apple lançou um patch emergencial apenas 1 semana depois
- Essa vulnerabilidade já havia sido usada anteriormente como 1day, por isso é considerada um caso significativo do ponto de vista das técnicas de exploit
- Este texto explica em detalhes a origem da vulnerabilidade e como ela foi descoberta
1. Lightspeed
- A vulnerabilidade em questão é o bug Lightspeed (CVE-2020-9859 etc.) apresentado pela Synacktiv, em que ocorre um problema de condição de corrida durante a liberação de memória do contexto de I/O assíncrono da syscall
lio_listio
- Ajustando o timing das operações de I/O para criar uma condição de double free de memória, torna-se possível sobrepor vários objetos na mesma região de memória por meio de duas liberações do objeto
- A estrutura de alocação dinâmica de memória da zona
kalloc.16 do kernel é usada no exploit
- Em essência, é um método de repetir a corrida várias vezes para aumentar a probabilidade de sucesso
2. Spice
- Esse exploit foi usado no passado no jailbreak Spice, criado pela team Jake Blair
- Variantes diferentes do exploit foram implementadas no racoon e no app, e o objetivo principal era a falsificação de portas mach
- Na época do iOS 11.x, era fácil contornar o PAN (Protection Against Null dereference), e diversas técnicas de hacking foram tentadas em conjunto com infoleak de kernel e sandbox escape
- No caso do racoon, devido à limitação de acesso ao IOKit, foi usado o OSUnserializeXML para criar o objeto alvo de spray naquela zona do kernel
- Também são descritas diferenças detalhadas e avanços técnicos posteriores envolvendo sysctl_procargsx, vazamento de memória não inicializada do kernel, política de sandbox etc.
3. unc0ver
- Na época da adoção pelo unc0ver, a estrutura do exploit foi projetada para funcionar em uma ampla gama de SoCs, incluindo A8~A13
- O exploit rastreia a sobreposição e o overlap de objetos OSData, liberando/alocando o objeto desejado no momento adequado para controlar a região de memória
- Usando objetos de kernel como
IOMemoryDescriptor, ele expõe o endereço do buffer de dados controlado pelo usuário e implementa leitura/escrita direta no kernel
- Também aproveita adequadamente fragilidades das políticas do alocador de memória do kernel no iOS 13, como o bypass de zone_require
- A implementação detalhada de toda a estrutura do exploit pode ser vista no repositório público no GitHub (tachy0n)
4. Impacto posterior
- A divulgação de um exploit 0day gerou grande repercussão na comunidade de segurança e na Apple
- Apenas 4 horas após a divulgação do exploit real, Project Zero e Synacktiv já haviam feito análises detalhadas e tomado medidas de resposta
- Após o patch, a Apple passou a adicionar testes formais de regressão para essa vulnerabilidade no XNU, sinalizando uma mudança para uma estratégia de segurança mais fundamentalmente reforçada
- A partir do iOS 14, foram introduzidas grandes mudanças que aumentaram bastante a dificuldade de criar exploits, como separação de áreas de alocação, object secure guard, PAC (Pointer Authentication Code), estrutura kheap etc.
- Agora, a própria estratégia de exploit passou a ser mais importante, e a diferença entre informações públicas e pesquisa privada aumentou; para iOS 17~18, a situação é de não haver nenhum exploit público de kernel
5. Conclusão
- Este é um caso que mostra claramente como a área de segurança/jailbreak do iOS mudou dramaticamente em 5 anos
- Ele oferece uma visão de como mudaram a direção técnica da comunidade de jailbreak/exploits, dos pesquisadores e da Apple
- A época em que IL era compartilhado e desafios eram feitos em conjunto agora pertence ao passado, e desde o iOS 14 o compartilhamento de informações sobre exploits diminuiu de forma marcante
Referências e contato
- O código-fonte relacionado e informações detalhadas podem ser consultados no site pessoal de Siguza e no repositório público do GitHub
2 comentários
Embora o hardware da Apple seja excelente, o software é cheio de mecanismos feitos para manter o usuário na coleira.
Mesmo que você só queira fazer um app que você mesmo criou e compilou rodar apenas no seu próprio dispositivo, ainda precisa de uma assinatura de 100 dólares.
Se você é um desenvolvedor que usa apps open source pequenos ou médios e compila para uso próprio,
fazer jailbreak explorando vulnerabilidades e usar sideload nos dispositivos da Apple é menos prático do que simplesmente usar Android.
Comentários do Hacker News
Menciona que o SockPuppet já tinha sido usado antes em jailbreaks na época do iOS 12, e que, mesmo depois de Ned Williamson, do Project Zero, reportá-lo à Apple e ele ser corrigido no iOS 12.3, reapareceu no iOS 12.4
Provavelmente a Apple fez um fork do XNU em um branch separado e deixou esse patch de fora, e o grande problema de fundo foi a ausência total de testes de regressão para vulnerabilidades novas e antigas
Eu mesmo automatizei alguns testes de regressão para vulnerabilidades 1-day já conhecidas e, de cara, consegui encontrar vulnerabilidades com sucesso
Fico curioso se outros projetos de código aberto, como Linux, FreeBSD, OpenWRT e OpenSSH, também executam testes de regressão de vulnerabilidades antigas em novas versões
Se cada vulnerabilidade for transformada em algo automatizado e houver condições de investir recursos para rodar isso no CI, o ganho certamente seria grande
Compartilha a experiência de quando, na universidade há 20 anos, fazia trabalho voluntário de QA no Mozilla e havia centenas de casos de teste de regressão
Havia muitos bugs de renderização/layout e do motor de JS, e, ao criar casos de teste minimizados, a estrutura permitia adicioná-los diretamente ao pipeline de CI
Bugs em si são inevitáveis, mas o pior é quando um bug já corrigido reaparece, porque isso desperdiça tempo e dinheiro; na visão dele, organizações que se importam com qualidade necessariamente investem muito em testes de regressão
Infelizmente, também há muitas organizações que ignoram QA ou tentam resolver tudo apenas com terceirização, sem dar a devida atenção
É difícil entender como a Apple não tinha testes de regressão relacionados a jailbreak
Desde muito tempo atrás, no Mozilla e em outros lugares, já se construíam excelentes ambientes de QA e CI/CD com ferramentas como Tinderbox e Bugzilla; ele achava que isso era comum mesmo antes de o conceito de DevOps ganhar destaque, mas só depois percebeu que não era tão comum assim
Havia milhares de casos de teste, e ele acha que era o Sqlite
Acrescenta que, se um patch não for backportado, há grande chance de o teste correspondente também não ser backportado
No fim, a lei de Conway também se aplica exatamente à relação entre segurança e desenvolvimento de funcionalidades
Assim, mesmo em organizações com bons testes de regressão no processo de build/release, a própria estrutura interna aumenta a chance de questões de segurança ficarem de fora
expressa a opinião de que agências de inteligência (G10, Rússia, China, Coreia do Norte etc.) e muitos grupos privados certamente fazem testes de regressão de vulnerabilidades dessa forma
compara com a situação de estar conversando com um amigo em uma língua estrangeira e, no segundo seguinte, a conversa mudar para um tema altamente especializado como neurocirurgia ou física nuclear, deixando a mente em branco
Isso o fez lembrar de quando tentou interpretar uma conversa sobre reparos em uma siderúrgica
Lamenta o desaparecimento dos jailbreaks; embora não tenha conseguido usar seu iPad com jailbreak para nada particularmente útil, se divertia com isso por si só
Hoje, gostaria de instalar um app de tethering, UTM ou uma solução de JIT
O SideStore parece promissor e ele gostaria de usá-lo, mas sua conta Apple já foi uma conta paga de desenvolvedor no passado e ainda tem 10 app IDs não expirados, o que impõe restrições à instalação desses apps
Para isso, precisaria criar uma conta nova ou voltar a pagar
Sem jailbreak, não havia motivo algum para usar um iPhone como telefone principal, e no fim acabou migrando para Android
Foi numa época em que o Android já tinha alcançado bastante coisa em termos de funcionalidades básicas
Questiona se é preciso passar por um corretor intermediário, se existe um e-mail oficial ou canal apropriado, e se não há risco de isso simplesmente morrer no suporte de primeiro nível
Como mencionado no texto, comunidades privadas ainda mantêm posse dessas vulnerabilidades e a Apple continua corrigindo-as
Só diminuíram os jailbreaks divulgados publicamente