Google revelado vários dias atrás vários protótipos de exploit que demonstram a possibilidade de explorar vulnerabilidades da classe Specter ao executar o código JavaScript em um navegador, sem passar pelos métodos de segurança adicionados acima.
Exploits podem ser usados para acessar a memória de um processo que está processando conteúdo da web na guia atual. Para testar a operação do exploit, o site da página vazada foi lançado e o código que descreve a lógica da operação foi postado no GitHub.
O protótipo proposto é projetado para sistemas de ataque com Processadores Intel Core i7-6500U em um ambiente Linux e Chrome 88, embora isso não exclua que mudanças possam ser feitas para usar o exploit em outros ambientes.
O método de operação não é específico para os processadores Intel: após a adaptação adequada, O exploit foi confirmado para funcionar em sistemas com CPUs de terceiros, incluindo o Apple M1 baseado na arquitetura ARM. Após pequenos ajustes, o exploit também funciona em outros sistemas operacionais e outros navegadores baseados no mecanismo Chromium.
Em um ambiente baseado nos processadores padrão Chrome 88 e Intel Skylake, conseguimos um vazamento de dados do processo responsável por renderizar o conteúdo da web na guia atual do Chrome (processo de renderização) a uma velocidade de 1 kilobyte por segundo. Além disso, foram desenvolvidos protótipos alternativos, por exemplo, um exploit que permite, ao custo de estabilidade reduzida, aumentar a taxa de vazamento para 8kB / s ao usar o temporizador performance.now () com uma precisão de 5 microssegundos (0.005 milissegundos ) Também foi preparada uma variante que operava com uma precisão de temporizador de um milissegundo, que poderia ser usada para organizar o acesso à memória de outro processo a uma taxa de cerca de 60 bytes por segundo.
O código de demonstração publicado consiste em três partes:
- A primeira parte calibre o cronômetro para estimar o tempo de execução das operações necessárias para recuperar os dados que permanecem no cache do processador como resultado da execução especulativa das instruções da CPU.
- Parte dois Define o layout de memória usado ao alocar o array JavaScript.
- A terceira parte explora diretamente a vulnerabilidade Spectre para determinar o conteúdo da memória do processo atual como resultado da criação de condições para a execução especulativa de certas operações, cujo resultado é descartado pelo processador após determinar uma previsão falhada, mas os rastros de execução são resolvidos no cache compartilhado e podem ser restaurados usando métodos para determinar o conteúdo do cache usando canais de terceiros que analisam a mudança no tempo de acesso aos dados armazenados e não armazenados em cache.
A técnica de exploração proposta elimina temporizadores de alta precisão disponível por meio da API performance.now () e sem suporte para o tipo SharedArrayBuffer, que permite criar arrays na memória compartilhada.
A exploração inclui o dispositivo Spectre, que causa a execução de código especulativo controlado, e um analisador de vazamento de canal lateral, que determina quais dados foram armazenados em cache durante a execução especulativa.
O gadget é implementado usando uma matriz JavaScript, na que é feita uma tentativa de acessar uma área fora dos limites do buffer, que afeta o estado do bloco de previsão de ramificação devido à presença de uma verificação de tamanho de buffer adicionada pelo compilador (o processador realiza especulativamente um acesso antes do tempo, mas reverte o estado após a verificação).
Para analisar o conteúdo do cache em condições de precisão do temporizador insuficiente, foi proposto um método que engana a estratégia de despejo de dados do cache Tree-PLRU usada nos processadores e permite, ao aumentar o número de ciclos, aumentar significativamente o tempo de diferença quando o valor é retornado do cache e na ausência de um valor no cache.
O Google publicou um protótipo do exploit para mostrar a viabilidade dos ataques usando vulnerabilidades da classe Specter e encorajar os desenvolvedores da web a usar técnicas que minimizem os riscos de tais ataques.
Ao mesmo tempo, o Google acredita que sem uma revisão significativa do protótipo proposto, é impossível criar exploits universais que estão prontos não apenas para demonstração, mas também para uso generalizado.
fonte: https://security.googleblog.com