Flush & Reload cache side channel attack

Aug 30 2020

Estou tentando entender o ataque de canal lateral de cache Flush + Reload. Até onde eu sei, o ataque utiliza o fato de que dados sem privilégios podem ser carregados no cache (ao explorar previsão de ramificação, execução especulativa, etc.). Em seguida, o invasor usa um array de sondagem para acessar uma memória, memória que é carregada rapidamente e presume-se que esteja no cache (parte dos dados secretos).

Uma coisa que não está clara é como o invasor é capaz de iterar por meio da memória virtual, que é uma memória sem privilégios? Por exemplo - iterando na memória virtual do kernel ou na memória de outros processos.

Respostas

3 bdegnan Aug 30 2020 at 21:26

Em primeiro lugar, você deve dar uma olhada em minha descrição de por que as tabelas de pesquisa não são executadas em tempo constante , pois tenho fotos de como o cache e a marcação funcionam.

O cache fica entre o MMU e a CPU, e o MMU é o que cria a memória virtual; assim, os ataques de cache são, na verdade, uma função independente da memória virtual. Eles são uma função de forçar uma liberação de cache e, em seguida, selecionar e escolher como o cache será recarregado, pois você está procurando por informações temporais. A busca externa entre caches é o que vaza informações. (Uma observação, este é basicamente um problema x86, pois não permite o bloqueio de cache, ao contrário da maioria das CPUs desde 1990. Outra ressalva é que eu só fiz hardware para arquiteturas não-x86, então alguém me avise se eu estiver errado sobre o cache bloqueio de dados críticos).

Para fins de exemplo geral, temos um cache de 1k bytes e usaremos AES s-box como uma tabela de consulta, portanto, 256 entradas.

  • forçar uma limpeza do cache através de um processo diferente, lendo 2k de bytes da memória.
  • o processo AES começa a funcionar e coloca os dados da caixa de dados no cache por proxy de buscas
  • Em seguida, fazemos outro processo de leitura de 1023 bytes de dados diferentes da memória para substituir todas as entradas AES, exceto uma, e ver quando os dados ficam lentos devido a uma leitura do barramento

Agora, para a versão MMU, onde atacamos a memória virtual. Se você olhou a resposta que vinculei, verá que há tags de cache. Agora vamos supor um exemplo simples em que tenho dois processos com 20 bits (1 MiB de espaço de endereço). A MMU faz com que ambos os processos tenham a mesma tabela virtual de 0xYYY00000, onde YYY é o prefixo real na memória. Se eu souber como o MMU está mapeando os dados, posso criar um ataque estruturado com base nas informações de marcação que são criadas no cache devido à forma como a memória se sobrepõe.

Há mais detalhes sobre como você estrutura esses ataques no lado do software nos ataques de tempo de cache de Bernstein em AES .

2 andy Sep 07 2020 at 07:07
  1. Existem diferentes ataques de canal do lado do cache. Existem muitas variantes, mas parece que você está confundindo duas: Prime + Probe e Flush + Reload. Porque esta é uma pergunta sobre Flush + Reload, vou ficar com ela.

  2. Flush + Reload funciona abusando de código / dados compartilhados combinados com a forma como o clflush (instrução de liberação de cache) funciona, pelo menos no x86. Existem variantes para outras arquiteturas. A vítima e o invasor devem compartilhar pelo menos 1 página de dados fisicamente. Quando o invasor usa o comando clflush com um endereço apontando para esses dados compartilhados, eles são completamente eliminados da hierarquia do cache. Como os dados são compartilhados, o invasor pode acessar esses dados no cache. Portanto, o invasor libera repetidamente os dados compartilhados com a vítima, permite / espera a execução da vítima e recarrega os dados. Se o invasor perder o cache, a vítima não acessou os dados (não os trouxe de volta ao cache). Se acertou, a vítima acertou (pelo menos provavelmente). O invasor pode distinguir acertos de cache de erros porque o tempo de acesso à memória é muito diferente.

  3. Como o invasor e a vítima podem compartilhar dados se forem processos diferentes? Você precisa saber um pouco sobre o sistema operacional moderno. Normalmente, as bibliotecas compartilhadas são carregadas apenas uma vez fisicamente na memória. Como exemplo, a biblioteca c padrão é carregada apenas uma vez, mas aplicativos separados acessam os mesmos dados (fisicamente) porque suas tabelas de página apontam para o mesmo endereço físico, porque o sistema operacional o configura dessa forma.

  4. Alguns sistemas operacionais são mais agressivos e fazem a varredura da memória phyiscal para encontrar páginas que possuem exatamente os mesmos dados. Nesse caso, eles "mesclam" as páginas alterando as tabelas de páginas de modo que todos os processos que usam esses dados apontem para a nova página física única, em vez de ter duas cópias físicas. Infelizmente, isso permite que Flush + Reload aconteça mesmo entre bibliotecas não compartilhadas - se você conhece o código da vítima e deseja monitorá-lo, pode apenas carregá-lo em seu espaço de endereço (mmap) e o sistema operacional terá o prazer de desduplicar memória, dando-lhe acesso aos seus dados. Contanto que vocês dois apenas leiam os dados, tudo bem; se você tentar gravar os dados, o sistema operacional será forçado a desfazer a mesclagem das páginas. No entanto, isso é bom para FLUSH + RELOAD: você só está interessado em ler de qualquer maneira!