A Google publicou vários protótipos de exploits que demonstram a possibilidade de exploração de vulnerabilidades da classe Spectre ao executar código JavaScript no navegador, contornando os métodos de proteção adicionados anteriormente. Os exploits podem ser utilizados para obter acesso à memória do processo que está processando conteúdo 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 de funcionamento está disponível no GitHub.
O protótipo proposto foi projetado para realizar ataques em sistemas com processadores Intel Core i7-6500U em um ambiente com Linux e Chrome 88. Para usar o exploit em outros ambientes, são necessárias modificações. O método de exploração não é específico para processadores Intel — após a devida adaptação, a funcionalidade do exploit foi confirmada em sistemas com CPU de outros fabricantes, incluindo o Apple M1 baseado na arquitetura ARM. Após correções menores, o exploit também é funcional em outros sistemas operacionais e navegadores baseados no motor Chromium.
Em um ambiente baseado no Chrome padrão 88 e em processadores Intel Skylake, foi possível alcançar a vazamento de dados do processo responsável pelo processamento de conteúdo web na guia atual do Chrome (processo de renderização), com uma taxa de 1 kilobyte por segundo. Além disso, foram desenvolvidos protótipos alternativos, como um exploit que, ao custo de reduzir a estabilidade, aumenta a velocidade de vazamento para 8kB/s ao usar o timer performance.now() com precisão de 5 microssegundos (0.005 milissegundos). Também foi preparado um variante que opera com precisão do timer em nível de um milissegundo, que poderia ser utilizado para organizar acesso à memória de outro processo com uma taxa de cerca de 60 bytes por segundo.
O código de demonstração publicado é composto por três partes. A primeira parte calibra o timer para estimar o tempo de execução das operações necessárias para recuperar dados que permaneceram no cache do processador após a execução especulativa de instruções da CPU. A segunda parte determina a disposição da memória utilizada ao alocar um array JavaScript.
A terceira parte executa diretamente a exploração da vulnerabilidade Spectre para determinar o conteúdo da memória do processo atual ao criar condições para a execução especulativa de determinadas operações, cujos resultados são descartados pelo processador após determinar uma previsão malsucedida, mas os rastros da execução ficam armazenados no cache comum e podem ser recuperados por meio de métodos de detecção de conteúdo de cache através de canais laterais, analisando a alteração no tempo de acesso aos dados armazenados em cache e não armazenados em cache.
A técnica de exploração proposta permite a dispensar temporizadores de alta precisão disponíveis através da API performance.now(), e sem suporte ao tipo SharedArrayBuffer, que permite criar arrays em memória compartilhada. O exploit inclui um gadget Spectre, que provoca a execução especulativa controlada do código, e um analisador de vazamento por canais laterais, que identifica os dados que foram armazenados em cache durante a execução especulativa.
O gadget é implementado com um array JavaScript, na qual há uma tentativa de acesso a uma área fora dos limites do buffer, afetando o estado do bloco de predição de desvios devido à verificação de tamanho do buffer adicionada pelo compilador (o processador, prevendo, executa especulativamente a chamada, mas reverte o estado após a verificação). Para analisar o conteúdo do cache em condições de precisão insuficiente do timer, é proposto um método que engana a estratégia de substituição de dados do cache Tree-PLRU aplicada nos processadores, permitindo que, ao aumentar o número de ciclos, a diferença de tempo ao retornar um valor do cache e ao não haver valor no cache seja significativamente ampliada.
Ressalta-se que a empresa Google publicou um protótipo de exploit para demonstrar a realidade de ataques utilizando vulnerabilidades da classe Spectre e para incentivar os desenvolvedores web a aplicar técnicas que minimizem os riscos de tais ataques. Neste contexto, a Google acredita que, sem uma reestruturação substancial do protótipo proposto, não será possível criar exploits universais, prontos não apenas para demonstração, mas também para aplicação generalizada.
Para reduzir o risco, os proprietários de sites são recomendados a utilizar os cabeçalhos implementados recentemente, como Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame-Options, X-Content-Type-Options e SameSite Cookie. Esses mecanismos não protegem diretamente contra ataques, mas ajudam a isolar os dados do site de vazamentos em processos onde o código JavaScript do atacante pode ser executado (o vazamento ocorre a partir da memória do processo atual, que pode estar processando dados de outro site aberto na mesma aba, além do código do atacante). A ideia principal é separar em diferentes processos a execução do código do site do código de terceiros, obtido de fontes não confiáveis, por exemplo, incluídos via iframe.
Fonte: opennet.ru
