O Google publicou vários protótipos de exploração mostrando a possibilidade de explorar vulnerabilidades da classe Spectre ao executar código JavaScript no navegador, ignorando métodos de proteção adicionados anteriormente. Exploits podem ser usados para obter acesso à memória do processo que processa o conteúdo da web na guia atual. Para testar o funcionamento do exploit, foi lançado o site leaky.page e o código que descreve a lógica do trabalho foi postado no GitHub.
O protótipo proposto foi projetado para atacar sistemas com processadores Intel Core i7-6500U em ambiente com Linux e Chrome 88. Para utilizar o exploit para outros ambientes são necessárias modificações. O método de exploração não é específico dos processadores Intel – após a devida adaptação, o exploit foi confirmado para funcionar em sistemas com CPUs de outros fabricantes, incluindo o Apple M1 baseado na arquitetura ARM. Após pequenos ajustes, a exploração também é viável em outros sistemas operacionais e em outros navegadores baseados no mecanismo Chromium.
Em um ambiente baseado nos processadores padrão Chrome 88 e Intel Skylake, foi possível vazar dados do processo responsável pelo processamento do conteúdo da web na aba atual do Chrome (processo de renderização) a uma velocidade de 1 kilobyte por segundo. Adicionalmente, foram desenvolvidos protótipos alternativos, por exemplo, um exploit que permite, ao custo da redução da estabilidade, aumentar a taxa de fuga para 8kB/s ao utilizar o temporizador performance.now() com uma precisão de 5 microssegundos (0.005 milissegundos ). Também foi preparada uma versão que funcionava com precisão de temporizador de um milissegundo, que poderia ser usada para organizar o acesso à memória de outro processo a uma velocidade de cerca de 60 bytes por segundo.
O código de demonstração publicado consiste em três partes. A primeira parte calibra o temporizador para estimar o tempo de execução das operações necessárias para restaurar os dados restantes no cache do processador como resultado da execução especulativa de instruções da CPU. A segunda parte determina 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 malsucedida, mas traços do a execução é depositada no cache geral e pode ser restaurada usando métodos para determinar o conteúdo do cache por canais de terceiros que analisam mudanças no tempo de acesso aos dados armazenados em cache e não armazenados em cache.
A técnica de exploração proposta permite dispensar temporizadores de alta precisão disponíveis através da API performance.now() e sem suporte ao tipo SharedArrayBuffer, que permite a criação de arrays em memória compartilhada. A exploração inclui o gadget Spectre, que causa a execução especulativa controlada de código, e um analisador de vazamento de canal lateral, que detecta dados armazenados em cache obtidos durante a execução especulativa.
O gadget é implementado usando um array JavaScript no qual é feita uma tentativa de acessar uma área fora dos limites do buffer, afetando o estado do bloco de previsão de ramificação devido à presença de uma verificação de tamanho do buffer adicionada pelo compilador (o processador executa especulativamente o acesso antecipado, mas reverte o estado após a verificação). Para analisar o conteúdo do cache em condições de precisão insuficiente do temporizador, é proposto um método que engana a estratégia Tree-PLRU de despejo de dados utilizada nos processadores e permite, ao aumentar o número de ciclos, aumentar significativamente a diferença de tempo no retorno um valor do cache e quando não há valor no cache.
Observa-se que o Google publicou um protótipo da exploração para mostrar a viabilidade de ataques usando vulnerabilidades da classe Spectre e para incentivar os desenvolvedores web a usar técnicas que minimizem os riscos de tais ataques. Ao mesmo tempo, o Google acredita que sem uma reformulação significativa do protótipo proposto, é impossível criar exploits universais que estejam prontos não apenas para demonstração, mas também para uso generalizado.
Para reduzir o risco, os proprietários de sites são incentivados a usar os cabeçalhos recentemente implementados Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame- Opções, X -Content-Type-Options e SameSite Cookie. Esses mecanismos não protegem diretamente contra ataques, mas permitem isolar os dados do site contra vazamentos em processos nos quais o código JavaScript do invasor pode ser executado (o vazamento ocorre da memória do processo atual, que, além do código do invasor , também pode processar dados de outro site aberto na mesma aba). A ideia principal é separar a execução do código do site em diferentes processos do código de terceiros recebido de fontes não confiáveis, por exemplo, incluído por meio de um iframe.
Fonte: opennet.ru