iLeakage: ataque de execução especulativa sem temporizador, baseado no navegador, contra dispositivos Apple
(ileakage.com)- Embora as mitigações para o Spectre venham sendo aplicadas há cerca de 6 anos, o iLeakage mostra que side channels de execução especulativa ainda podem ser explorados no Safari em Mac, iPad e iPhone
- O atacante pode induzir o usuário a visitar e clicar em uma página maliciosa e, com JavaScript e WebAssembly, fazer o Safari renderizar páginas web arbitrárias para recuperar informações sensíveis
- A demonstração inclui a recuperação de títulos de mensagens recentes do Gmail, credenciais preenchidas automaticamente do Instagram, histórico de visualização do YouTube, além da senha do Facebook e do token SMS de 2FA em um MacBook Pro com Apple M3
- O impacto atinge dispositivos macOS e iOS com CPUs Apple A-series e M-series, e foi mitigado no iOS 17.2 e macOS 14.2, que incluem o Safari 17.2
- Também é possível se proteger com o Lockdown Mode ou desativando o JavaScript, mas há limitações de funcionalidade, e a detecção é muito difícil porque o ataque roda dentro do Safari e não deixa rastros nos logs do sistema
O risco do Spectre reaparece em dispositivos Apple
- iLeakage é um ataque de side channel de execução especulativa voltado ao navegador Safari
- O alvo são dispositivos macOS e iOS que usam CPUs A-series ou M-series da Apple
- Inclui iPhones e iPads recentes
- Também inclui notebooks e desktops da Apple desde 2020
- Em princípio, o código de uma aba do navegador não deveria conseguir inferir o conteúdo de outra aba, mas o iLeakage consegue ler o conteúdo da página-alvo quando o usuário visita e clica em uma página controlada pelo atacante
- Entre as informações recuperáveis podem estar dados pessoais, senhas e informações de cartão de crédito
- Os pesquisadores divulgaram os resultados à Apple em 12 de setembro de 2022, 408 dias antes da publicação pública
Dados sensíveis efetivamente recuperados
- Os pesquisadores demonstraram casos de recuperação de informações de alto valor em serviços populares
-
Credenciais do Instagram
- No Safari do macOS, foi usado o cenário em que o usuário faz login no Instagram com o LastPass como gerenciador de credenciais com preenchimento automático
-
Caixa de entrada do Gmail
- No Safari do iOS, assumindo que o usuário já estivesse autenticado no Google, foram recuperados os títulos das mensagens recentes de uma conta Gmail em um iPad
-
Histórico de visualização do YouTube
- O histórico de visualização do YouTube foi recuperado no Chrome para iOS
- O Chrome para iOS funciona como uma camada sobre o mecanismo de navegação do Safari por causa das políticas da Apple App Store
-
Senha do Facebook e token 2FA
- Em um MacBook Pro com chip Apple M3, macOS 14.1.1 e Safari 17.1, a senha do Facebook foi recuperada primeiro
- Em seguida, o token SMS de 2FA enviado para um telefone Android foi recuperado via Google Messages
Como funcionam o Spectre e os side channels
- A maioria das CPUs modernas usa execução especulativa: quando o resultado de um desvio não está disponível imediatamente, a CPU prevê o caminho de execução e processa primeiro as instruções desse caminho
- Se a previsão estiver errada, a CPU reverte as mudanças de estado, mas vestígios podem permanecer no estado microarquitetural, como no cache
- O Spectre é uma vulnerabilidade de hardware que explora esses vestígios para ler dados que, pela semântica normal do programa, não deveriam ser acessíveis
- Side channels podem explorar características da implementação do sistema mesmo quando o programa executa algoritmos seguros
- Exemplos incluem som, radiação eletromagnética, thermal throttling e compartilhamento de recursos microarquiteturais da CPU
- Quando atacante e alvo executam na mesma CPU, eles compartilham recursos como núcleo, cache e buffers internos, e essa contenção pode ser medida indiretamente por variáveis como tempo ou consumo de energia
Estrutura do ataque sem temporizador que contorna as defesas do Safari
- Desde o Spectre, os fabricantes de navegadores vêm reforçando as defesas contra ataques de execução especulativa e execução transitória
- As defesas do Safari incluem 35-bit addressing, value poisoning, política de isolamento por processo por aba e temporizadores de baixa resolução
- O iLeakage é a primeira demonstração de um ataque de execução especulativa contra CPUs Apple Silicon e o Safari
- O ataque começa com a reconstrução empírica da configuração de cache não documentada das CPUs Apple
- Depois disso, é criado um gadget baseado em especulação capaz de distinguir cache hit de cache miss usando apenas temporizadores de baixa resolução
- Também foi demonstrada uma variante que explora race condition sem usar temporizador
- Esse gadget é usado tanto em testes de criação de eviction set quanto em um covert channel
- Ao portar a técnica para o Safari, os pesquisadores fazem o navegador executar, durante a execução especulativa da CPU, código destinado a um tipo de dado específico sobre um objeto de tipo incorreto criado pelo atacante
- No fim, torna-se possível realizar out-of-bounds read em qualquer ponto do espaço de endereçamento do processo de renderização do Safari
- Em combinação com um novo método de unificar sites de domínios diferentes no mesmo espaço de endereçamento, isso permite um ataque de confusão de tipos especulativa para vazar informações sensíveis
Mitigações, dificuldade de detecção e impacto por navegador
- O iLeakage foi mitigado no Safari 17.2, incluído no iOS 17.2 e no macOS 14.2
- A medida recomendada é atualizar os dispositivos Apple para a versão mais recente do sistema operacional
- O Lockdown Mode mitiga o iLeakage ao desativar a compilação JIT do Safari
- A compilação JIT é um recurso de desempenho usado pelo iLeakage para criar o primitivo de ataque
- O Lockdown Mode pode alterar o funcionamento do dispositivo, por exemplo bloqueando alguns anexos de mensagens e chamadas FaceTime de desconhecidos
- A lista completa está na documentação do Lockdown Mode da Apple
- Desativar o JavaScript também bloqueia o iLeakage, mas pode fazer o Safari renderizar alguns sites de forma incorreta ou incompleta, e recursos web avançados, como pagamentos online, podem deixar de funcionar
- O iLeakage roda dentro do Safari e não deixa rastros nos arquivos de log do sistema, o que torna a detecção muito difícil
- Ainda assim, vestígios da visita à página do atacante podem permanecer no cache do navegador referente às páginas visitadas recentemente
- Não há evidências de exploração no mundo real
- Montar um ataque ponta a ponta é muito difícil e exige conhecimento avançado de ataques de side channel baseados em navegador e da implementação do Safari
- Continua sendo recomendável usar gerenciadores de credenciais
- O iLeakage pode recuperar credenciais preenchidas automaticamente em páginas web
- Muitas plataformas exigem interação do usuário para que o preenchimento automático ocorra
- Chrome, Firefox e Microsoft Edge no macOS usam motores JavaScript diferentes, então o iLeakage, que explora características específicas do motor JavaScript do Safari, não funciona neles
- No iOS, por causa das políticas da Apple App Store e de sandboxing, outros apps de navegador também usam o motor JavaScript do Safari
- Chrome, Firefox e Edge para iOS são wrappers sobre o Safari que oferecem recursos auxiliares, como sincronização de favoritos e configurações
- Quase todos os aplicativos de navegador da App Store são vulneráveis ao iLeakage
- O artigo acadêmico está disponível como iLeakage paper e foi publicado na 2023 ACM Conference on Computer and Communications Security
1 comentários
Opiniões no Hacker News
Parece que falta algo neste FAQ: queria saber se isto é uma vulnerabilidade do WebKit ou uma vulnerabilidade do Safari, se ativar o Lockdown Mode mitiga o problema no Safari móvel, já que ele não tem essa configuração de desenvolvedor, e quando isso foi divulgado à Apple
Depois, a página foi atualizada e passou a responder à última pergunta: os pesquisadores divulgaram os resultados à Apple em 12 de setembro de 2022, 408 dias antes do lançamento público
Como é irrealista remover todos os possíveis gadgets de Spectre do WebKit, os navegadores precisam aproveitar as mitigações de Spectre do sistema operacional isolando sites diferentes em processos diferentes
Como o FAQ diz que “no fim, alcança uma leitura fora dos limites em qualquer lugar do espaço de endereçamento do processo de renderização do Safari”, pessoalmente vejo isso como uma vulnerabilidade em uma implementação incorreta do isolamento de sites do Safari
Em quais ambientes ela pode ser explorada depende dos detalhes da implementação dos gadgets baseados em JavaScript que provocam e medem esse canal lateral, e isso pode estar no artigo, que ainda não li
O Lockdown Mode desativa a compilação JIT no Safari, portanto serve como mitigação, e bloqueia recursos de desempenho que o iLeakage usa para criar suas primitivas de ataque
Sobre “é perigoso usar um gerenciador de credenciais?”, a maioria responde que não, mas, se algo está vazando da memória, me parece que isso deveria afetar toda a memória dentro do espaço do processo do Safari
Não estou familiarizado com essa área, então não entendo bem por que usar ou não um gerenciador de credenciais seria uma condição de exceção
Parece que eles querem evitar fazer as pessoas voltarem a coisas como “newpassword2”; se você desativar o preenchimento automático e preencher por atalho ou outra interação do usuário, fica mais seguro
Dá para ler como se você fosse imune caso não usasse um gerenciador de senhas, não salvasse no navegador e digitasse tudo manualmente toda vez, mas isso é um contra-argumento ruim por vários motivos
Gerenciadores de senhas são úteis por muitos outros motivos, e, mesmo que uma senha seja roubada, no mínimo só um site fica comprometido
Esta técnica provavelmente também consegue roubar tokens de sessão, o que, embora não seja tão ruim quanto roubo de senha, ainda é ruim
Configurar o gerenciador de senhas para só preencher ao clicar também pode impedir este ataque
Uma senha preenchida automaticamente em uma página pode ser recuperada como uma senha digitada manualmente, mas isso não significa que seja possível ler diretamente todas as senhas armazenadas dentro do gerenciador de senhas
window.openSenhas armazenadas em um app separado de gerenciador de senhas não ficam acessíveis a menos que esse app as preencha automaticamente em uma janela ou processo do Safari comprometido
Este ataque encontrou uma forma de fazer duas origens diferentes compartilharem o mesmo espaço de endereçamento, e acredito que não se aplique a extensões
O artigo diz: “mostramos uma nova técnica que explora a política de isolamento de sites do Safari, fazendo com que uma página do atacante compartilhe o espaço de endereçamento simplesmente ao abrir uma página-vítima arbitrária com a API JavaScript
window.open”Fico confuso se enquadrar isso como algo exclusivo do WebKit é realmente correto. O abuso de cache em si parece genérico, e a citação também diz que houve precisão quase perfeita em Safari, Firefox e Tor
Também queria saber se o ataque via
window.open()é realmente exclusivo do WebKit, ou se este estudo só analisou o WebKit em profundidadewindow.open()implica um contexto compartilhado em que a janela chamadora recebe uma referência para a nova janela, e a nova janela tem uma referência de volta porwindow.opener; fico na dúvida se outros motores de navegador conseguem obter isolamento completoEm navegadores móveis, o isolamento de sites do Chromium é limitado, e o Firefox ainda não terminou a implementação
https://www.chromium.org/Home/chromium-security/site-isolati...
Confuso. Isso parece um problema de alta gravidade, mas a correção está atrás de um menu de depuração. Não sei por que foi divulgado antes de ser distribuído corretamente em todos os lugares
Também mostra que mitigações de canais laterais são, na prática, inúteis e que não se deve fingir que ataques assim foram corrigidos
Em CPUs modernas, se um host roda vários aplicativos, executar código não confiável não é seguro, por mais sandboxing que haja
Acho muito melhor informar os usuários da Apple sobre o risco do que deixá-los mais um ano sem saber do perigo
Sou a favor de dar tempo às empresas para corrigirem bugs, mas, a partir de certo ponto, não avisar as pessoas afetadas se torna mais irresponsável
O artigo explica que a fuga especulativa do sandbox de JavaScript ainda é possível, mas que o atacante fica limitado ao próprio espaço de endereços e à leitura dos próprios dados
Ele diz que, no momento da escrita, um patch da Apple estava público e implementado no Safari Technology Preview 173 ou posterior, e [57] é https://github.com/WebKit/WebKit/pull/10169
Abaixo disso, um engenheiro continua linkando patches de reforço adicionais sobre
window.open()e isolamento de processosSwap Processes on Cross-Site Window Openjá estava ativado e marcado como StableComo não fui eu que ativei, pensei que talvez a Apple já tivesse habilitado e a descrição estivesse desatualizada, mas depois vi que eu estava olhando para
Swap Processes on Cross-Site Navigation, de nome parecido, e parece que ele não vem ativado por padrão atualmenteA culpa deveria ser da Apple, que ficou tanto tempo de braços cruzados, e não dos pesquisadores por divulgarem antes da distribuição da correção
Nem todos os ataques de canal lateral foram corrigidos, mas dizer que mitigações de canais laterais são inúteis é inadequado
Assim como pessoas morrem em acidentes de carro mesmo usando cinto de segurança, mas isso não torna o cinto inútil; mitigações aumentam muito a dificuldade de exploração
“Os pesquisadores divulgaram os resultados à Apple em 12 de setembro de 2022”, então fico realmente curioso para saber por que a Apple praticamente deixou isso de lado por mais de um ano
A Apple é uma das autoridades de CVE e pode se recusar a emitir CVEs para seus próprios produtos; com esse poder, pode se mover tão devagar quanto quiser
Achei que tinha visto no site do iLeakage uma frase sobre correção, mas ela sumiu. Pensei que eu tivesse me enganado, mas o site realmente estava mudando na última hora
Havia uma frase dizendo “A Apple acabou de lançar iOS 17.1, iPadOS 17.1 e macOS Sonoma 14.1, então atualize seus dispositivos”, e agora ela foi revertida
https://github.com/ileakage-authors/ileakage-authors.github....
Quando apontei que o site não tinha um cronograma de divulgação, uma seção curta foi adicionada ao FAQ, e aqui parece que os pesquisadores também ficaram confusos pela situação pouco clara sobre a distribuição da correção
Swap Processes on Cross-Site Navigation, ativado por padrãoFico me perguntando se é diferente de
Swap Processes on Cross-Site Window Openno macOSA frase “o iLeakage é um ataque bastante difícil de executar até o fim e exige conhecimento avançado de ataques de canal lateral baseados em navegador e da implementação do Safari” talvez seja o motivo de a Apple não se importar muito
Dar a isso mais um apelido assustador e até um nome de domínio não parece profissional nem confiável
Se isso afeta dispositivos macOS ou iOS com CPUs Apple série A ou série M, ou seja, iPhones/iPads recentes e notebooks/desktops Apple desde 2020, então, como um raro usuário de Intel Mac, acho que não sou afetado
A hierarquia de cache é apenas um pouco diferente, e a prova de conceito exigiria algumas pequenas alterações
No iOS, é preciso usar o Lockdown Mode, e essa é a única forma de usar um iPhone com segurança
Benchmarks feitos sem Lockdown Mode devem ser considerados tão inúteis quanto rodar benchmarks de CPU com
mitigations=offMais um bom motivo para permitir outros motores de navegador em dispositivos iOS
Se ocorrer um erro ao executar o comando abaixo, conceda Full Disk Access ao Terminal e tente novamente
defaults write com.apple.SafariTechnologyPreview IncludeInternalDebugMenu 1