Uma prova de conceito de Spectre para uma web à prova de Spectre

Postado por Stephen Röttger e Artur Janc, engenheiros de segurança da informação

No entanto, essa classe de ataques ainda é uma preocupação e exige que os desenvolvedores da Web implantem atenuações no nível do aplicativo .

Nesta postagem, compartilharemos os resultados da pesquisa da equipe de segurança do Google sobre a capacidade de exploração do Spectre contra usuários da web e apresentaremos uma prova de conceito (PoC) rápida e versátil escrita em JavaScript que pode vazar informações da memória do navegador. Confirmamos que esta prova de conceito, ou suas variantes, funcionam em uma variedade de sistemas operacionais, arquiteturas de processador e gerações de hardware.

Ao compartilhar nossas descobertas com a comunidade de segurança, pretendemos dar aos proprietários de aplicativos da web uma melhor compreensão do impacto que as vulnerabilidades do Spectre podem ter na segurança dos dados de seus usuários. Finalmente, esta postagem descreve as proteções disponíveis para os autores da web e as práticas recomendadas para habilitá-las em aplicativos da web, com base em nossa experiência no Google.

Um pouco de fundo

A vulnerabilidade Spectre , divulgada ao público em janeiro de 2018, faz uso de uma classe de vulnerabilidades de design de processador (CPU) que permite a um invasor alterar o fluxo de controle do programa pretendido enquanto a CPU está executando especulativamente as instruções subsequentes. Por exemplo, a CPU pode especular que uma verificação de comprimento passa, enquanto na prática ela acessará a memória fora dos limites. Embora o estado da CPU seja revertido assim que a previsão incorreta for observada, esse comportamento deixa efeitos colaterais observáveis ​​que podem vazar dados para um invasor.

Em 2019, a equipe responsável pelo V8, o motor JavaScript do Chrome, publicou um post e whitepaper concluindo que tais ataques não pode ser confiavelmente mitigados no nível do software. Em vez disso, soluções robustas para esses problemas exigem que os limites de segurança em aplicativos como navegadores da web sejam alinhados com primitivos de baixo nível, por exemplo , isolamento baseado em processo . 

Paralelamente, fornecedores de navegadores e órgãos de padronização desenvolveram mecanismos de segurança para proteger os usuários da web dessas classes de ataques. Isso incluiu alterações arquitetônicas que oferecem proteções padrão habilitadas em algumas configurações de navegador (como isolamento de site , iframes fora do processo e bloqueio de leitura de origem cruzada ), bem como recursos de segurança opt-in amplamente aplicáveis ​​que os desenvolvedores da web podem implantar em suas aplicações: Cross-Origin Resource Policy , Cross-Origin Policy Opener , Cross-Origin Policy Embedder , e outros.

Esses mecanismos, embora de importância crucial, não evitam a exploração de Spectre; em vez disso, eles protegem os dados confidenciais de estarem presentes em partes da memória de onde podem ser lidos pelo invasor. Para avaliar a robustez dessas defesas, é importante desenvolver ferramentas de segurança que ajudem os engenheiros de segurança a entender as implicações práticas dos ataques de execução especulativa para seus aplicativos.

Demonstrando Spectre em um navegador da web

Hoje, estamos compartilhando um código de prova de conceito (PoC) que confirma a praticidade das explorações do Spectre contra os mecanismos JavaScript. Usamos o Google Chrome para demonstrar nosso ataque, mas esses problemas não são específicos do Chrome e esperamos que outros navegadores modernos sejam igualmente vulneráveis ​​a esse vetor de exploração. Desenvolvemos uma demonstração interativa do ataque disponível em https://leaky.page/ ; o código e uma redação mais detalhada são publicados no Github aqui.

O site de demonstração pode vazar dados a uma velocidade de 1kB / s quando executado no Chrome 88 em uma CPU Intel Skylake. Observe que o código provavelmente exigirá pequenas modificações para se aplicar a outras CPUs ou versões de navegador; no entanto, em nossos testes o ataque foi bem-sucedido em vários outros processadores, incluindo o CPU ARM Apple M1, sem grandes mudanças.

Enquanto experimentávamos, também desenvolvemos outros PoCs com propriedades diferentes. Alguns exemplos incluem:

• Um PoC que pode vazar 8kB / s de dados a um custo de estabilidade reduzida usando performance.now () como um temporizador com precisão de 5μs.
• Um PoC que vaza dados a 60B / s usando temporizadores com uma precisão de 1 ms ou pior.

Optamos por liberar o PoC atual, pois ele tem um tempo de configuração insignificante e funciona na ausência de temporizadores de alta precisão, como SharedArrayBuffer .

Os principais blocos de construção do PoC são:

1. Um gadget Spectre : código que dispara a execução transitória controlada pelo invasor.
2. Um canal lateral : uma forma de observar os efeitos colaterais da execução transitória.

1. O gadget

Para o PoC publicado, implementamos um gadget Variante 1 simples : uma matriz JavaScript é especulativamente acessada fora dos limites após treinar o preditor de ramificação para que a verificação de comprimento inserida pelo compilador seja bem-sucedida. Este gadget específico pode ser atenuado no nível do software; no entanto, a equipe V8 do Chrome concluiu que esse não é o caso de outros gadgets: “ descobrimos que a mitigação eficaz de algumas variantes do Spectre, particularmente a variante 4, é simplesmente inviável no software. ”

Convidamos a comunidade de segurança a estender nossa pesquisa e desenvolver código que faça uso de outros dispositivos Spectre.

2. O canal lateral

Uma maneira comum de vazar dados secretos por meio de execução especulativa é usar um canal lateral de cache . Observando se determinado local da memória está ou não presente no cache, podemos inferir se ele foi acessado durante a execução especulativa. O desafio em JavaScript é encontrar um cronômetro de alta resolução que permita distinguir o cache de acessos à memória, já que os navegadores modernos reduziram a granularidade do cronômetro da API performance.now () e desabilitaram SharedArrayBuffers em contextos sem isolamento de origem cruzada para evitar ataques de cronometragem.

Já em 2018, a equipe do V8 compartilhou sua observação de que a granularidade reduzida do cronômetro não é suficiente para mitigar o Spectre, uma vez que os invasores podem amplificar arbitrariamente as diferenças de cronômetro. A técnica de amplificação apresentada foi baseada na leitura de dados secretos várias vezes, o que pode, no entanto, reduzir a eficácia do ataque se o vazamento de informações for probabilístico.

Em nosso PoC, desenvolvemos uma nova técnica que supera essa limitação. Abusando do comportamento da estratégia de despejo de cache Tree-PLRU comumente encontrada em CPUs modernas, fomos capazes de amplificar significativamente o tempo de cache com uma única leitura de dados secretos. Isso nos permitiu vazar dados de forma eficiente, mesmo com temporizadores de baixa precisão. Para obter detalhes técnicos, consulte a demonstração em https://leaky.page/plru.html .

Embora não acreditemos que este PoC específico possa ser reutilizado para propósitos nefastos sem modificações significativas, ele serve como uma demonstração convincente dos riscos do Spectre. Em particular, esperamos que ele forneça um sinal claro para os desenvolvedores de aplicativos da web de que eles precisam considerar esse risco em suas avaliações de segurança e tomar medidas ativas para proteger seus sites.

Implantando defesas da web contra Spectre

A natureza de baixo nível das vulnerabilidades de execução especulativa torna difícil corrigi- las de forma abrangente, pois um patch adequado pode exigir alterações no firmware ou hardware do dispositivo do usuário. Embora os desenvolvedores de sistema operacional e navegador da web tenham implementado proteções integradas importantes sempre que possível (incluindo isolamento de site com iframes fora do processo e bloqueio de leitura de origem cruzada no Google Chrome ou Fissão de projeto no Firefox), o design de APIs da web existentes ainda possibilita que os dados fluam inadvertidamente para o processo de um invasor.

Com isso em mente, os desenvolvedores da Web devem considerar o isolamento mais robusto de seus sites usando novos mecanismos de segurança que negam ativamente aos invasores o acesso a recursos de origem cruzada. Essas proteções atenuam os ataques de hardware do tipo Espectro e vazamentos comuns entre sites em nível da web , mas exigem que os desenvolvedores avaliem a ameaça que essas vulnerabilidades representam para seus aplicativos e entendam como implantá-los. Para ajudar nessa avaliação, a equipe de segurança da plataforma da web do Chrome publicou Post-Specter Web Development e Mitigating Side-Channel Attacks com conselhos concretos para desenvolvedores; Recomendamos fortemente seguir suas orientações e habilitar as seguintes proteções:

• Cross-Origin Resource Policy (CORP) e Fetch Metadata Request Headers permitem que os desenvolvedores controlem quais sites podem incorporar seus recursos, como imagens ou scripts, evitando que os dados sejam entregues a um processo de renderização de navegador controlado por um invasor . Consulte resourcepolicy.fyi e web.dev/fetch-metadata .

• A Cross-Origin Opener Policy (COOP) permite que os desenvolvedores garantam que a janela do aplicativo não receba interações inesperadas de outros sites, permitindo que o navegador o isole em seu próprio processo. Isso adiciona uma proteção importante no nível do processo, especialmente em navegadores que não permitem o isolamento total de sites; consulte web.dev/coop-coep .

• A Cross-Origin Embedder Policy (COEP) garante que todos os recursos autenticados solicitados pelo aplicativo tenham optado explicitamente por serem carregados. Hoje, para garantir o isolamento no nível do processo para aplicativos altamente sensíveis no Chrome ou Firefox, os aplicativos devem habilitar COEP e COOP; consulte web.dev/coop-coep .

Além de habilitar esses mecanismos de isolamento, certifique-se de que seu aplicativo também habilite proteções padrão, como os cabeçalhos X-Frame-Options e X-Content-Type-Options , e use cookies SameSite . Muitos aplicativos do Google já foram implantados ou estão em processo de implantação desses mecanismos, fornecendo uma defesa contra bugs de execução especulativos em situações em que as proteções padrão do navegador são insuficientes. 

É importante observar que, embora todos os mecanismos descritos neste artigo sejam primitivos de segurança importantes e poderosos, eles não garantem proteção completa contra Spectre; eles exigem uma abordagem de implantação considerada que leva em consideração comportamentos específicos para o aplicativo em questão. Encorajamos engenheiros e pesquisadores de segurança a usar e contribuir com nossa prova de conceito Spectre para revisar e melhorar a postura de segurança de seus sites.

Dica : para ajudá-lo a proteger seu site do Spectre, a equipe de segurança do Google criou o Spectroscope , um protótipo de extensão do Chrome que verifica seu aplicativo e encontra recursos que podem exigir a ativação de defesas adicionais. Considere usá-lo para ajudar nas suas implantações de recursos de isolamento da web.

Fonte: https://security.googleblog.com/